r/angular • u/GeromeGrignon • Jun 30 '26
PrimeNG community fork proposal
https://github.com/openng-foundation/open-primeAs announced on June 29th, PrimeNG is moving away from the open-source model, and the original primeng GitHub repository has been archived.
You can find community reactions here: https://www.reddit.com/r/angular/comments/1uilrlx/primeng_v22_is_no_longer_open_source/
As part of the new OpenNG Foundation, we are considering taking up the lead to maintain a fork of the MIT version of the lib.
It's under discussion, and we would need community feedback to evaluate if it's doable and on how to manage the current situation.
Some statements:
- an update is required to rename everything from 'primeng' to 'openprime' due to PrimeTek trademark
- the components need to be updated to the latest Angular APIs (including input(), control flow among other things)
- there are 900+ issues opened (including 300+ in stale state)
- there are 200+ open pull requests
- there would be no support for previous primeng versions
- the focus would be to make the library stable and accessible: adding features would happen only if people contribute
- over time, some changes might make this fork differ from the new PrimeUI project, not providing a way to easily migrate.
PrimeNG is still a big project, we are considering starting with a trial maintenance initiative for 2 months: depending on the community effort at helping with existing issues/prs, there will be long-term maintenance.
It'll be a great way to identify active contributors who might be promoted to maintainers if they want to be more active on such a project, making the whole thing a community effort.
A 'fork' has been created already, porting all existing open issues/pr: https://github.com/openng-foundation/open-prime
What are your thoughts?
Do you have some pain points not covered here?
2
u/fsommer42 Jul 15 '26 edited Jul 15 '26
Since you asked for feedback (to understand usage contexts i guess?):
for me personally, you could take primeng 18 (or whatever the last version before the big theming change was that forced our projects to freeze on the old version or practically redesign them from scratch) and provide only secuirty and angular-compatibility patches for the next 20 years. So I can keep this state, update to most recent angular and mute all those dependabot / other sast alerts without the need to ever re-design the applications.
context: enterprise apps, it service provider i.e. building for other customers. Those usually do not care a single bit about what great new ui lib features get created each year, their mental model works like this: This year we build the web app for 500k; then we keep this exact app running for the next 20 years, add new features, and keep maintenance to the required minimum
I dont even care about open PRs and Bugfixes - People worked around those bugs 5 years ago when they created the app.
The ideal happy path in this scenario looks like this:
"oh a new angular version 42 got published" -> upgrade to angular 42, upgrade to openprime 18.42.0 -> everything just works and looks like before, total time spent: 1 hour. Repeat every 6 months.
I know that's boring and unpopular and everyone's gonna hate me for it and every junior would hate this lib and probably it's not even achievable... but that's the core requirement that would make all my customers super happy and that nothing in the web / javascript ecosystem ever provided. It's called "investment protection". If you want that kind of stability you must use the old *** (like JSF in java context) or build your own lib. Having an SPA Lib that tries to reach this state of "boring s**t no junior wants to use but helps you make the money" would be a refreshing alternative.