[Feature]: Track and evaluate angular-split for project intake

[GitAttila]

Checklist

• I have searched the existing issues and have not found a duplicate
• I have read the README and documentation
• I agree to follow the OpenNG Foundation Code of Conduct

Problem

angular-split is still widely used, but it is no longer keeping up with Angular majors.

• npm: https://www.npmjs.com/package/angular-split
• GitHub: https://github.com/angular-split/angular-split
• Docs: https://angular-split.github.io
• License: Apache-2.0

Latest published version is 20.0.0 (21 July 2025), targeting Angular 20. Current Angular is 22.1.x. Weekly downloads for 23–29 Aug 2026 were 134,406; about 542k in the last 30 days and about 5.8M in the last 12 months.

There is an open PR from about two weeks ago to update the library to Angular 22, with no maintainer response: https://github.com/angular-split/angular-split/pulls

Listed maintainers (README, as of 2024): Jeffrey Bosch (@Jefiozie), Sander Elias, Harpush. There were small commits in early 2026, so the git log is not empty. What has stalled for more than a year is the work that keeps the package usable: Angular major upgrades, PR review, and npm releases.

This is a project-intake suggestion per:

• https://www.openng.org/community/project-intake
• https://www.openng.org/about/contact (Suggest a project)

I am filing an issue because the Contact page’s GitHub discussion flow is not usable.

Proposed solution

Please evaluate angular-split against the Project Intake criteria. I know Optimus UI already ships a Splitter (https://optimus.openng.org/splitter), so this is not “Angular has no split pane at all.” It is a different question: whether the existing Optimus/PrimeNG-style Splitter is a maintained replacement for the angular-split user base.

In apps I have used, Optimus/PrimeNG Splitter is weaker on touch/mobile than angular-split (gutter dragging and panel resizing are awkward on small screens). It also has no useful default animation when panels collapse, expand, or snap; angular-split’s interaction model and docs are built around that kind of layout behavior. Those gaps could be fixed inside Optimus Splitter, and that path is worth considering.

I still think angular-split should be evaluated as its own library, not only as a feature request on Optimus UI:

• It is a focused layout primitive with its own API, docs site (https://angular-split.github.io), and a large installed base (~134k weekly downloads, ~5.8M in 12 months, ~932 GitHub stars). Replacing that with a different component is a migration, not a drop-in.
• Intake already allows schematics or guides when a revival needs a migration. Folding everyone into Optimus Splitter would force that migration on teams that never adopted PrimeNG/Optimus.
• Improving Optimus Splitter and stewarding angular-split are not mutually exclusive. Optimus can keep a kit-native Splitter; angular-split can stay the dedicated, documented tool for teams that already depend on it.

Suggested sequence, matching OpenNG’s own rules:

1. Contact the listed angular-split maintainers (Jeffrey Bosch / @Jefiozie, Sander Elias, Harpush) about help, co-maintenance, or a hand-off. Also contact Samuel Mbabhazi (@samuelmbabhazi, https://github.com/samuelmbabhazi), who opened the Angular 20 → 22 upgrade PR on angular-split (https://github.com/angular-split/angular-split/pulls). That work is already sitting unreviewed. I am not speaking for him; I am asking OpenNG to include him in the same outreach as the listed maintainers, as the person who already did the version bump.
2. Add angular-split to the tracked-libraries list on https://www.openng.org/projects while that conversation happens.
3. Decide in the open whether to (a) steward angular-split under OpenNG, (b) invest in Optimus Splitter mobile/animation behavior and document a migration, or (c) do a limited amount of both.
4. If stewardship goes ahead: keep the original package name if the npm token can be transferred; otherwise publish @openng/angular-split with a migration note and original credits intact.

First increment if (a) is chosen: land or rebase the existing Angular 22 PR, cut 21/22-compatible releases, keep the public API stable. Surface area is much smaller than Optimus UI.

I can help test the Angular 22 PR and compare touch behavior against Optimus Splitter if that helps the decision.

Proposed API or usage

No new API is proposed. The point of intake is to keep the existing angular-split API working on Angular 21/22.

Current angular-split usage (stable public API teams already have in production):


import { SplitComponent, SplitAreaComponent } from 'angular-split';

@Component({
  imports: [SplitComponent, SplitAreaComponent],
  template: `
    <as-split direction="horizontal" unit="percent" [gutterSize]="11" [useTransition]="true">
      <as-split-area [size]="30" [minSize]="15">
        Sidebar
      </as-split-area>
      <as-split-area [size]="70">
        Main
      </as-split-area>
    </as-split>
  `,
})
export class AppShell {}

Alternatives considered

Enhance only Optimus UI Splitter and leave angular-split unmaintained: possible, but it abandons a separate popular API and docs site and pushes a migration onto ~134k weekly downloads.

A personal fork of angular-split: does not give the ecosystem a trusted @OpenNg home.

Open a discussion via the Contact page: that flow appears broken, which is why this issue exists.

How important is this feature to you?

Important

Contribution

• I am willing to open a pull request for this feature

Additional context

Highlights:

• 20.0.0 (Jul 2025) vs Angular 22; ~134k weekly downloads
• Open Angular 22 PR by @samuelmbabhazi, unreviewed
• Optimus Splitter exists but is a different API (weaker on mobile in my use)
• Contact: @Jefiozie, Sander Elias, Harpush, @samuelmbabhazi
• I can help test the upgrade PR; this is not a website PR

[Jefiozie]

I already talked to @geromegrignon if we could do this. Happy to discuss this