PrimeNG archived its repo, and Angular teams now own a procurement decision

PrimeNG changed its licensing model, and in the words of a dev.to writeup from IPT the repository was archived overnight while bugfixes moved behind a community licence teams have to apply for ^{[1] [2]}. That turns a free dependency into a budget line: the author's framing is that medium to large teams must now choose between paying to stay and switching away ^[3].

The first path is to pay. The team the author spoke to that took it did so because there is no migration overhead and existing in-house knowledge of the library keeps velocity intact ^{[4] [5]}. PrimeTek has also said additional components are in active development and will ship as they become production-ready: DataGrid, Gantt, Diagram and a PDF Viewer ^[6]. The author's caveat is the obvious one: nobody outside the vendor knows what those components will look like or whether they will fit a given use case ^[7].

The second path is a manual rewrite, component by component. It gives full control over the result and a chance to fix accumulated inconsistencies with your design system, and it is the slowest option, plausibly several weeks depending on how many PrimeNG components you use and how deeply they are wired into the codebase ^{[8] [9]}.

The third is to hand that rewrite to an agent. The author has not tried this and is sceptical, expecting a usable first draft followed by several more days of manual fine-tuning, on the grounds that agents are not yet good at pixel-perfect components or at respecting an existing design system ^{[10] [11]}. The cost grows when you change libraries rather than versions, because inputs, Tailwind support and passthrough do not map cleanly between them, and styling that leans on PrimeNG component inputs can degrade into hand-written CSS in something like Material ^[12]. The author labels this a hypothesis worth testing rather than a conclusion ^[13].

The fourth path is the fork. The openng collective has forked PrimeNG as Optimus UI, migrated all open issues across, released a first version and shipped a migration schematic ^{[14] [15]}. The author's reasoning for trying it is worth repeating because it is the only argument here that does not depend on trusting a roadmap: the project has to migrate away eventually, so moving to a maintained open-source library costs it nothing it was not already going to spend ^[16].

The numbers from that run are the most useful thing in the post. After `ng update primeng@21`, `npm install @openng/optimus-ui` and `ng generate @openng/optimus-ui:migrate-from-primeng`, the tool reported 10 references in 4 files that could not be migrated automatically ^{[17] [18]}. The leftovers were configuration and naming glue rather than markup: a CSP configuration TODO in `app.config.ts`, translation constants and a `setTranslation` call, an `inject(Optimus)` line, and a severity type map in a form field message component ^[19]. Five of the ten sat in that one message component ^[1], and all four files were TypeScript, with no templates flagged ^[2].

Two things to watch. Whether the four announced components actually ship, since that is the whole case for paying ^[6], and whether openng sustains issue throughput after the initial migration of the backlog ^[14]. Anyone taking the fork route should also budget for the residue: the tool moves the imports, and a human still reconciles the config, the i18n wiring and every local type alias with PrimeNG in its name ^[19].