Library / SDK
taiga-family/taiga-ui avatar
taiga-family/taiga-ui

Taiga UI: an Angular component library that lives or dies by its version table

Angular components library for awesome people

4,059 stars579 forksTypeScriptApache-2.0

At a glance

What is it?
Taiga UI is a tree-shakable Angular UI kit of 130+ components published as separate npm packages. Its real constraint is not features but the version compatibility table, and that is what should drive the adoption decision.
Who is it for?
Adopt Taiga UI if you are on Angular 19 or newer and want a component library whose styling is exposed through CSS custom properties, with a dark theme available out of the box. Do not adopt it if you are pinned to Angular 12 through 15, or if you need a Figma library for the current major version: the README says Figma is available only for 2.x and 3.x, and that the next Figma library is in progress.
Can I use it commercially?
Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 1 day ago.
What is it written in?
Mainly TypeScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 3, 2026, and from our analysis. They are not legal advice.

Editorial analysis

The problem Taiga UI solves, and the teams it fits

Most Angular UI kits ask you to accept their visual language wholesale. Taiga UI takes a different position: the README describes it as "fully-treeshakable" and says the components are "very flexible and are ready for any use case", while the library handles what it calls basic UX aspects so you can focus on product features. That split is the pitch. You get behaviour and accessibility wiring, and you keep control of appearance through CSS custom properties, with a dark theme included.

The repository is a monorepo. The package.json at the root is named @taiga-ui/components, marked private, and declares npm workspaces over projects/*, so the published artifacts are built from that tree rather than from a single package. The README states the project is split into "multiple base libraries and several add-ons", and it points at @taiga-ui/cdk as one of the published packages. It also states the library began as an internal product and is used by 50+ projects in production, which is a claim from the README rather than something an outside reader can verify.

Who is this for? Teams already committed to Angular, on a modern version, who want a broad component set and are willing to learn the library's own conventions. The README is explicit that the project leans on dependency injection heavily and that components use OnPush with strict TypeScript. If your team treats those as constraints to work around rather than defaults to adopt, the fit is poor.

How the packages, entry points and polymorphism actually fit together

Two mechanisms shape everything else. The first is secondary entry points. The README says the project "harnessed the power of Secondary Entry Points mechanism", which is what makes the tree-shaking claim concrete: importing a single entity from the library should not drag the rest of it into your bundle. In practice this means the library is not one import surface but many, and the granularity is the point.

The second is dynamic content. The README states the library is "based on ng-polymorpheus dynamic content approach" and uses "Web APIs for Angular" for the browser APIs it needs. Both are separate repositories under the same GitHub organisation. Polymorpheus is what lets a component accept a template, a component or a string where content is expected, which is why so many Taiga UI components are described as flexible rather than opinionated about what you put inside them.

On top of that sits a scale claim: the README says the library has 130+ components, 100+ directives, and dozens of tokens and utils. Tokens are the styling layer, since the README says all styling goes through CSS custom properties. The consequence for a new user is that there are two places to look when something renders wrong: the component's own API, and the token that feeds its CSS. Neither is more authoritative than the other.

The monorepo tooling is visible in the root package.json. Builds run through Nx, with scripts such as run-many:build:libs invoking nx run-many --target build --all --exclude=demo. Linting is ESLint, spelling is checked with cspell, and releases go through standard-version plus a scripts/release.ts helper with release:major, release:minor and release:patch variants. None of that affects consumers directly, but it explains why the changelog moves in step across packages.

Installing Taiga UI and rendering a first component

The README does not walk through installation itself. It says: "See our Getting started page to start working with Taiga UI", linking to taiga-ui.dev/getting-started, and it offers a StackBlitz starter at taiga-ui.dev/stackblitz for a quick sample. So the authoritative install steps live on the documentation site, not in the repository README. What the README does give you is the package naming: the badge and links reference @taiga-ui/cdk, and the root package.json is @taiga-ui/components.

Before installing anything, check the version table. It maps 5.x.y to Angular ^19.0.0 through latest, marked as current, and 4.x.y to Angular ^16.0.0 through latest, marked as LTS ending on 01.01.2027. Versions 3.x.y and 2.x.y are marked as no longer supported. Installing a Taiga UI major that does not match your Angular version is the most likely way to waste an afternoon.

The repository's own build and demo scripts show how the maintainers run the project locally, which is useful if you want to read the source or reproduce a demo rather than consume the package:

bash
npm install
npx nx build demo
npx cypress open --browser chrome --project ./projects/demo-cypress

The first command installs the monorepo's dependencies. The second builds the demo application through Nx, which is the same target the build:demo script wraps. The third opens the Cypress runner against the demo-cypress project, which is where the component tests live. If you are evaluating Taiga UI rather than contributing to it, the StackBlitz starter is the faster path because it skips this local setup entirely.

For a real first use, follow the Getting started page rather than guessing at imports. The README's own framing tells you what to expect: you import individual entities from secondary entry points, you style through CSS custom properties, and you get a dark theme without assembling one yourself.

Where Taiga UI gets in your way

The version table is the sharpest limitation, and it cuts in both directions. If your application is on Angular 12 through 15, the README lists 3.x.y and 2.x.y as no longer supported, so you are choosing between an unsupported Taiga UI major and an Angular upgrade. That is a real constraint, not a documentation gap.

The LTS window is the second constraint. The README states 4.x.y LTS ends on 01.01.2027. If you adopt the 4.x line because your Angular version sits in the ^16.0.0 range, you are adopting onto a branch with a published end date. The 5.x line is the one marked current, and it requires Angular ^19.0.0 or later.

Design handoff is the third. The README says Figma is "available only for 2.x and 3.x versions" and that the next Figma library is "in progress" for the latest version. A team whose designers work from a Figma library will not find one matching the current major, and the README does not give a date for when that changes.

The engineering defaults are a fourth consideration. The README states the project is "not afraid to use DI to the max", that all components use OnPush, and that the whole project is developed with strict TypeScript. Those are good defaults in a greenfield Angular application. In a codebase that has avoided OnPush or runs with strict mode off, adopting Taiga UI means either changing those settings or accepting components that assume them.

Finally, scale is a cost. The README presents 130+ components and 100+ directives as a strength, and for coverage it is. For a small application that needs a button, a dialog and a form field, the surface area you have to learn is larger than the surface area you will use.

Taiga UI against Angular Material and PrimeNG

The comparison people actually search for is Taiga UI versus Angular Material, and the difference is philosophical rather than a feature checklist. Angular Material implements Material Design, so the visual language is fixed by a specification and your customisation happens within it. Taiga UI does not commit to a named design system in the README. It commits to CSS custom properties for all styling, which means the visual language is yours to define and the library supplies behaviour and structure. If your product needs to look like itself rather than like Material, that distinction matters more than any individual component.

Against PrimeNG the split is different. PrimeNG is a broad component suite with its own theming layer and a large catalogue. Taiga UI's stated differentiators are the secondary entry point tree-shaking, the ng-polymorpheus dynamic content model, and the CSS custom property styling. The tree-shaking claim is the one worth testing on your own bundle, because it is the kind of property that depends on how you import, not only on how the library is built.

A third reference point is ng-zorro, which appears in the same search results. It is an Angular implementation of Ant Design, so it carries the same fixed-specification property as Angular Material. All three of these are real alternatives with their own design commitments. Taiga UI is the one in this group that declines to name a design system and pushes styling decisions to the consumer.

Maintenance, versioning and the licence

The repository is not archived, and the last push was on 2026-09-23. Recent releases include v5.25.0 and v4.100.0, both published on 2026-09-21, and v5.24.0 on 2026-09-14. The pattern is worth reading carefully: the 5.x line and the 4.x LTS line are both receiving releases, which matches the README's table where 4.x.y is marked LTS and 5.x.y is marked current.

Upgrade cost depends on which line you are on. Moving within a major is routine. Moving from 4.x to 5.x carries an Angular version requirement, since 5.x.y targets Angular ^19.0.0 and later while 4.x.y targets ^16.0.0 and later. The repository's release tooling, visible in the root package.json as standard-version plus scripts/release.ts, produces the changelog entries you would read before such a jump. The CHANGELOG.md file sits at the top level of the repository.

The licence is Apache-2.0, stated in both the README badge and the root package.json. Apache-2.0 is a permissive licence that includes an explicit patent grant, which is generally why organisations accept it without a review cycle. That is a description of the licence, not legal advice; if your organisation has a policy on which licences are pre-approved, this is the identifier to check against it.

Editorial conclusion

Adopt Taiga UI if you are on Angular 19 or newer and want a component library whose styling is exposed through CSS custom properties, with a dark theme available out of the box. Do not adopt it if you are pinned to Angular 12 through 15, or if you need a Figma library for the current major version: the README says Figma is available only for 2.x and 3.x, and that the next Figma library is in progress. Before writing any code, confirm which major you are installing, because the README's table ties 5.x.y to Angular ^19.0.0 and later, and 4.x.y to Angular ^16.0.0 and later with LTS ending on 01.01.2027.

Frequently asked questions

What is Taiga UI?

It is a tree-shakable Angular UI kit made up of multiple base libraries and several add-ons, according to the README. It is built on the ng-polymorpheus dynamic content approach and uses Web APIs for Angular for the browser APIs it needs.

Is Taiga UI free?

Yes. The repository is licensed under Apache-2.0, which the README shows as a badge and the root package.json states as the license field. That is a permissive licence, though it is not legal advice for your organisation's policy.

How does Taiga UI compare to Angular Material?

Angular Material implements a fixed design specification, while the Taiga UI README does not name a design system at all. Instead it states that all styling uses CSS custom properties, with a dark theme out of the box, leaving the visual language to the consumer.

How does Taiga UI compare to Material?

The comparison lands in the same place as the Angular Material one: Taiga UI's README commits to CSS custom properties for all styling rather than to a named design system, so the visual language stays with the consumer while the library supplies behaviour and structure.

What is a Taiga UI alternative?

The README does not name alternatives, but the search results around this project point at Angular Material, PrimeNG and ng-zorro. Of those, Angular Material and ng-zorro implement fixed design specifications, while Taiga UI declines to name one.

Official sources

  1. License: Apache-2.0
  2. Project website
  3. README
  4. Releases
  5. taiga-family/taiga-ui on GitHub
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/taiga-family-taiga-ui.svg)](https://hysenlabs.com/projects/taiga-family-taiga-ui)