PrimeNG shifts its licensing structure, while A2UI introduces model-driven Angular UI development — these lead the news cycle this week.
Short updates cover OpenNG’s community-maintained fork, the router’s transactional handling of resources, and today’s Native Federation versus Module Federation choices for Angular projects.
Future of PrimeNG
PrimeNG, a widely adopted UI component collection, has revealed that upcoming major releases will no longer be open source. Instead, they will be accessible only via a free Community license, which is available to individuals, students, nonprofits, non-commercial open-source projects, and small firms.
This shift affects not only its Angular variant but also the React and Vue offerings. The rationale is that the project has expanded considerably over the years—maintaining it as open source demands significantly more effort, and eventually, the revenue generated from selling complementary products no longer covered the expenses.
The new licensing is branded as PrimeUI. The launch price stands at USD 599 per developer. That cost is perpetual, meaning it applies for life to the covered versions, and it bundles one year of software updates. The package also includes PrimeUI PRO, which brings components for charts, a rich text editor, a scheduler, a task board, and other extras. However, those Pro components are excluded from the Community license.
PrimeUI
PrimeUI delivers a full UI suite: high-end component libraries, sophisticated pro-level components, a UI kit, and design assets for crafting contemporary web apps.
primeui.dev
The OpenNG organization, known for stepping in to support orphaned projects, confirmed that PrimeNG has shifted to a closed-source model. Its GitHub repository was archived on June 28th, 2026, and OpenNG then created a duplicate of the codebase, along with freshly regenerated open issues and pull requests. Their immediate objective is to ship a beta build compatible with Angular 22. Essentially, this is a fork. Right now, it goes by the temporary name open-prime, but OpenNG notes that this label is too reminiscent of PrimeNG, given PrimeTek's intent to secure trademarks on it.
OpenNG Update: Funding, Versioning, PrimeNG and ngneat projects | OpenNG posted on the topic | LinkedIn
Given the uncertainty surrounding initiatives like Spectator or PrimeNG, this is where we stand right now with our efforts.
OpenNG
The initiative has been renamed from OpenNG Foundation to simply OpenNG, aiming to steer clear of confusion and to comply with the OpenJS Foundation trademark guidelines.
Funding
A funding strategy is in the works to sustain project maintenance and reward contributors. The initiative has been submitted to Open Collective, and we have also reached out to HeroDevs to explore a partnership.
Versioning Policy
Every package will see a fresh start with v1.0.0. Each project will get a compatibility matrix outlining the supported major Angular versions, including the prior package. Since some packages had already diverged from Angular's versioning approach, this shift lets us introduce major versions for breaking changes whenever necessary.
PrimeNG
As of June 28th, 2026, PrimeNG has transitioned to closed-source, and its GitHub repository has been archived. The full announcement is available here.
We have forked the project and reopened the existing issues and pull requests. Of the 968 issues left open, 58 are already resolved, while 23 have been triaged as still relevant and open to contributions. This triage effort was possible solely due to community involvement.
Our immediate target is to roll out a beta that supports Angular 22, given that many teams have postponed their upgrades.
This release is set to include:
- a batch of unpublished changes from the original repository, focusing on modernizing current components and introducing some fresh ones
- ng add support for bootstrapping new projects
- ng update support, as those unreleased changes carry several breaking adjustments, like removing camelcase selectors and deprecated APIs
The main hurdle right now is settling on a project name. The candidate "open-prime" is too similar to PrimeNG, especially since PrimeTek is moving to trademark that name. We've put a call out for community ideas here.
Proposals are being assessed, with the key constraint being that the name must not clash with any existing project, as a range of UI frameworks already match many of the suggestions.
ngneat projects
From the full set of 34 original repositories, we've selected these to focus on:
- cashew
- query
- elf
- spectator
A volunteer is currently on cashew, prepping its initial release.
Within the ngneat ecosystem, spectator takes the top priority, with a release planned for this week. Additionally, there's a contribution to make the jasmine package available as a standalone, similar to the jest and vitest options, which is slated for 1.1.0.
The remaining repositories still need to be triaged to decide their fate. Out of them, 13 may be dropped due to low engagement or because more suitable alternatives now exist.
GitHub: https://lnkd.in/eE7QuzZR
A2UI
Devin Chasanoff, a member of the Angular team, has shared a guide covering the integration of A2UI with Angular, offering a way to drive dynamic interfaces through an AI model.
It all starts when the user voices a goal in the UI layer and the application forwards that request, together with the relevant background details, to a model. Optionally, the frontend can also submit a catalog of renderable components. In response, the model determines whether any interface elements are required, selects the most suitable ones, and hands back a structured set of UI directives for the app to parse.
Essentially, A2UI acts as a communication standard for these agent-driven interface scenarios. Depending on the setup, A2UI messages may flow over HTTP, WebSocket, or Server-Sent Events.
Demystifying A2UI: How to Make AI Agents “Speak UI” in Your App | by Devin Chasanoff | Jun, 2026 | Angular Blog
A good chunk of my time has gone into exploring A2UI—a protocol for crafting agentic user interfaces. My motivation is straightforward: I believe…
routerResource
Elsewhere, initial efforts to connect resource behavior with the router appear to have kicked off. An internal-focused PR surfaced, introducing a snapshot-style router resource behavior to tie navigation-specific data into the picture.
That snapshot freezes a resource's current state—like its value—at the moment a navigation kicks off. If the navigation succeeds, the actual value becomes visible; if it’s aborted, the frozen value stays intact during rollback recovery.
Consider this scenario. A resource takes a router parameter as its own input, such as a product ID that loads the matching product. If the user remains on the same component but switches to a different product ID, the resource would instantly shift its state, causing the UI to change mid-navigation. This could produce flicker, especially when a guard cancels the navigation and the product ID reverts to the original one.
With the new router resource behavior, that outcome is avoided. The PR’s notes clearly state this isn’t exposed for public use yet, but it’s quite possibly the first step toward merging resources with the router.
Angular PR #69490: Create transactional router resource
Micro-Frontends
Meanwhile, adopting micro-frontends is an architectural pattern we encounter frequently in large enterprises. While it’s not a built-in Angular framework capability, two widely used community approaches exist: Native Federation and Module Federation.
The key difference in Angular lies in their build tooling—Native Federation relies on esbuild, the current Angular builder, whereas Module Federation traditionally pairs with the older webpack builder or alternatives like Rspack.
Native Federation is maintained by Angular Architects, while Module Federation support within Nx has long been standard for Angular workspaces. In the Nx 23 release notes, Nx now recommends @angular-architects/native-federation for Angular projects and marks the older Nx-specific Module Federation generators and executors as deprecated.
Nx 23: 4x Faster Nx Agents, Agentic Nx Migrate, improved targetDefaults, .Net GA | Nx Blog
The Nx 23 release introduces a more intelligent multi-major nx migrate, faster performance in both the local engine and Nx Cloud agents, default enabling of native Node.js TypeScript stripping and V8 compile cache, refined targetDefaults handling, and a substantial removal of deprecated generators, executors, and APIs.
nx.dev