Optimus UI, a PrimeNG v21 fork that stays on MIT

One command is both the setup path and a deliberate refusal

The single command in the quick start is the setup path, and in one specific situation it is a refusal. Run `ng add @openng/optimus-ui` and the schematic asks which theme preset you want, adds the packages, wires `provideOptimus` into your root providers, and installs everything. That is for new projects only. When it finds a `primeng` dependency already in the workspace it leaves your code untouched and fails with an error pointing at the migration documentation, rather than reporting a partial success and walking away. Both outcomes come out of the same entry point, which is the first thing to check if you expected the command to carry an existing application across. Components are imported per subpath and used with a prefixed selector:

import { Button } from '@openng/optimus-ui/button';

<p-button label="Check" />

That prefix, and the `pi pi-*` icon classes the documentation examples use, are PrimeNG conventions that survived the fork rather than a naming scheme Optimus UI chose.

Migration is versioned against a different major than the repository

Migration lives in a separate schematic, and it is pinned to a different major than the workspace. The documented procedure is to install the package at major version 1 so the Angular CLI can resolve the schematic, then run the schematic itself:

npm install @openng/optimus-ui@1
ng generate @openng/optimus-ui@1:migrate-from-primeng

It swaps packages, rewrites imports, and produces a report of anything it could not handle automatically, with file and line numbers. The guide that accompanies it is hosted on a separate v1 subdomain of the documentation site. The monorepo package.json meanwhile reports version 2.0.2, and the recent tags are 2.0.2 from 2026-08-28, 2.0.1 from 2026-08-20, and 1.0.2 from 2026-08-20, so both a 1.x and a 2.x line exist side by side. Anything the schematic could not rewrite is left for you to finish by hand, and the file and line numbers are the only map you get. There is also an ordering prerequisite: applications on PrimeNG v20 or older are told to upgrade to v21 first, which makes this a two step move for older codebases.

Eight scoped packages, and only one of them is a real dependency

Eight scoped packages come out of the workspace, and the split decides what you actually install. `@openng/optimus-ui` holds the components, directives and services, and it is the only one most applications install directly. Around it sit the theme packages: `@openng/optimus-ui-themes` carries the built-in presets Aura, Material, Lara and Nora, and `@openng/optimus-ui-styled` is the styled-mode theming engine that turns those presets into CSS variables. `@openng/optimus-ui-styles` holds the base styles the components share. There is also a Tailwind CSS plugin package covering both v3 and v4, a locale package for i18n definitions, a motion package for animation and transition utilities, and a utils package for shared helpers. The runtime floor is Angular v21 or newer plus RxJS v7.8.1 or newer, which lines up with the PrimeNG v21 fork point rather than with the newest Angular release.

Icons are optional, but the examples still teach a PrimeNG class name

The icon set is the one dependency that is genuinely optional, and the documentation still teaches a PrimeNG class name. Icons are published separately as `@openng/icons`. Components accept any icon through templating, so nothing in the library forces that package on an application, but the documentation examples render icons with `pi pi-*` classes. Those names are the PrimeNG icon convention, so an application following the examples ends up depending on class names inherited from the fork's origin. The icon package is not one of the eight workspace packages; it only appears as a link out to npm, which means the install schematic has to bring it in separately for the documented examples to look right. If you migrate and later replace the icon layer, every one of those class references inside your own templates is yours to track down, and the schematic's report covers source files rather than the markup already written against them. The same split shows up in the presets. Choosing a preset is the first question the schematic asks, four presets ship in the themes package, and the styled-mode engine turns whichever one you pick into CSS variables the components read.

Publishing is gated on a production audit and runs with git checks off

The release path in package.json does two things worth reading before you rely on it. The build script sets NODE_ENV to production, then runs a check step, and that check step is a format check plus a security check. The security check is one command:

pnpm audit --prod --audit-level high

A high severity advisory in a production dependency therefore stops the build before anything is packed. The release scripts then run the build and publish every package under packages/ with git checks disabled and a summary report enabled, across three channels: the default release, a beta channel tagged beta, and a release candidate channel tagged rc. The summary lands in pnpm-publish-summary.json at the repository root. Disabling git checks means nothing in that path verifies the working tree is clean or sitting on a release branch, so the format gate and the audit are the only automatic brakes named here.

The clean script also deletes pnpm-lock.yaml

One script in package.json reaches outside the usual build folders. The clean script invokes npx rimraf with a glob that targets node_modules, dist and .angular directories, and it also removes pnpm-lock.yaml from the repository root. In a workspace whose layout is pnpm-lock.yaml plus pnpm-workspace.yaml, that lockfile is what pins every version, so a routine clean leaves you resolving versions from the registry again on the next install. For working on the packages locally there is a separate link script that filters across packages/ and runs dev:link inside each one. Contributor setup is two commands, and the first installs dependencies and git hooks together, which is why lefthook.yml sits at the root next to commitlint.config.ts, eslint.config.js, .prettierrc.json, .prettierignore, .editorconfig, .gitattributes, tsconfig.json and a .vscode directory.

The fork says what it is not, and names the date that caused it

The project is unusually direct about its boundaries, and the reason is dated. In June 2026 PrimeTek archived the PrimeNG repository and moved future major versions, starting with v22, to a commercial license, which left a lot of applications on a library with no further open source releases. Optimus UI is a community fork of PrimeNG v21, the last MIT licensed version, and it states that it stays MIT, that there is no paid tier, and that none is planned. It also states that it is not affiliated with, endorsed by, or sponsored by PrimeTek, and it repeats the trademark line for PrimeNG, PrimeFaces, PrimeReact, PrimeVue and PrimeFlex. Support is community only, with no SLA and no commercial support; issues are for bugs and discussions are for questions. CONTRIBUTING.md describes how to bring across a pull request that never landed on primefaces/primeng, with its history intact.

The repository record asserts no license, and two files in the tree do

One gap deserves a check before you resolve licensing programmatically. The repository record for openng-org/optimus-ui carries no license assertion at all, so that field is empty rather than naming a license. The files in the repository do name one: LICENSE.md exists at the root, the root README states MIT and links to it, and the monorepo package.json declares MIT in its license field. The README also states that PrimeNG v21, the fork point, was published under the same license with the original copyright notices intact, which matters because a fork that kept the original notices is claiming a different thing from one that relicensed. So the silence sits in the metadata rather than in the licensing itself, and a tool that reads only the repository record will come back with nothing at all. The separate icon package, the documentation site at optimus.openng.org, and the v1 subdomain holding the PrimeNG migration guide all live outside this repository, so a license sweep across the project surfaces needs more than one lookup. The site pages referenced from the README cover installation, philosophy, FAQ, roadmap and contribution, and the philosophy page is described as setting out both what the project commits to and what it does not do.

Editorial conclusion

Optimus UI is the right target if you have a PrimeNG v21 codebase and want a component library that keeps publishing under MIT, given that PrimeNG moved future majors starting with v22 to a commercial license. Check two things before you commit. First, read the migration schematic pinned to major version 1 and confirm the target major yourself, because the monorepo package.json already reports 2.0.2. Second, resolve the license from LICENSE.md and package.json rather than from the repository record, which carries no license assertion at all. Skip it if your application sits on PrimeNG v20 or older and you cannot budget the upgrade to v21 first, or if you need an SLA and commercial support, because neither is offered.

Frequently asked questions

Official sources

1. Issues
2. openng-org/optimus-ui on GitHub
3. Project website
4. README
5. Releases