zard-ui/zardui: an Angular component library built around a shadcn style registry

What Zard/ui is and how it differs from a normal Angular package

Zard/ui describes itself as a modern Angular component library inspired by shadcn/ui, built with Tailwind CSS, for developers who want accessible open source components that are free to use. The repository description adds Ng-zorro as the second influence, so the visual and behavioural reference points are the React-oriented shadcn/ui and the established Angular component set.

What matters for a technical decision is the distribution model. A shadcn style library is not consumed as a compiled dependency with a version of its own. The components are copied into the consuming project as source, which means the application owns the code, can restyle it in place, and is not pinned to a library release cycle. The repository supports that reading: the package manifest in the repository root is named `@zard/source` at version `0.0.0`, which is the shape of an internal workspace package rather than a published component library. The published artefact of the project is the registry, the CLI and the documentation site.

The project is MIT licensed, and the licence file is at the repository root. The documentation lives on a separate site, zardui.com, with the component documentation under `/docs`. The README itself is short, so the component catalogue, the installation instructions and the API details are all in that site rather than in the repository, which is the first thing to know before planning an adoption.

The monorepo behind the site, the registry and the components

The repository root is a monorepo, and the directory names describe the whole toolchain. `apps/` holds the web application that serves the documentation site, `libs/` holds shared libraries, `packages/` holds the publishable workspace packages, and `api/` is a separate area for the API layer. `tools/` and `scripts/` carry the build helpers, and `nx.json` marks the workspace as an Nx monorepo.

Several directories point to the parts of the project a consumer never sees but a contributor has to work with. `.verdaccio/` indicates a local Verdaccio registry, which is how the registry packages are served during development, and `vercel.json` shows the documentation site is deployed to Vercel. `jest.config.ts` and `jest.preset.cjs` set up the unit test runner, and `eslint.config.mjs`, `.prettierrc`, `.prettierignore`, `.lintstagedrc` and `commitlint.config.mjs` cover linting, formatting and commit message rules. `.husky/` installs the git hooks, and `commitlint-plugin.cjs` is a local commitlint plugin, so the message convention is enforced by the repository's own code rather than by configuration alone.

There is also an agent-facing surface. The `skills/` directory with `skills-lock.json` and a `context7.json` file at the root suggest that the component documentation is prepared for tools that read repository context, and `check:skills` is one of the verification scripts. The `.claude/` directory and `.coderabbit.yaml` point to the assistant tooling the project uses for contributions.

The practical consequence for an adopter is that the project is more than a folder of Angular components. It is a documentation site, a registry, a CLI, an MCP server and a set of code generators that all have to agree with each other on every release.

The registry, the CLI and the MCP server

The registry is the mechanism that turns a component into something a project can pull in. The scripts show the loop: a registry build, a check that the registry is consistent, and a local server for serving it.

"build:registry": "npx tsx scripts/build-registry.cts && npm run check:registry",
"check:registry": "npx tsx scripts/check-registry.cts",
"serve:registry": "npx tsx scripts/serve-registry.cts",

Alongside that sits a command line interface and a Model Context Protocol server, each built through Nx targets:

"build:cli": "npx nx run cli:build",
"build:mcp": "npx nx run mcp:build",
"publish:mcp": "npx nx run mcp:publish",

The `cli` script itself runs the CLI in development mode and then serves the registry, which tells you the two are meant to be used together during local development. The MCP server is a separate publishable unit with its own build and publish targets, and it can be run in watch mode with `dev:mcp`.

The naming of the checks is a good way to read the project's priorities, because each one guards a specific promise to the consumer. `check:api-docs` guards the API documentation against drift. `check:scrollbar` guards the scrollbar behaviour, which is a detail users notice when it is wrong. `check:install-docs` guards the installation instructions, and `check:skills` guards the agent skill files. All of them run as TypeScript scripts through `tsx`.

A developer working on the registry therefore has a fairly explicit tool: build the registry, check it, serve it locally, and let the CLI pull components from that local server during development.

A build pipeline that generates before it compiles

The `build` script is worth reading line by line, because it shows that the published site and the published components are both generated artifacts.

"build": "npm run generate:theme-tokens && npm run generate:highlight && npm run generate:md && npm run generate:llms && npm run build:registry && node apps/web/update-routes.mjs && npx nx run web:build --configuration=production && npm run generate:md:docs",

The order is: generate theme tokens, generate the highlight output, generate markdown, generate the LLM-facing files, build the registry, update the routes of the web app, build the web app for production, and finally generate the documentation markdown. Theme tokens are synchronised by `scripts/sync-theme-tokens.cts`, and the highlight output comes from a generator inside the highlight package.

Two of these steps exist for machine readers rather than for browsers. `generate:llms` runs `apps/web/generate-llms.mts` with the web app's generate tsconfig, and `generate:md` runs `apps/web/generate-markdown.mts` with the same config. The site is therefore built to be consumed as text by language models as well as by browsers, and the `context7.json` file at the repository root belongs to that same effort. The `skills/` directory and its check script are the other half of it.

Two environment settings are visible. The `.env.example` file contains a single variable:

PORT=4222

The dev script starts the workspace with `node --env-file-if-exists=.env scripts/dev.mjs`, so the environment file is optional and a missing `.env` does not stop the development server, but when it exists it sets the port the local tooling listens on.

How releases are tested and versioned

Testing is split into unit tests, end to end tests and the documentation checks. The unit test target runs across the whole workspace:

"test": "nx run-many --target=test --all",
"e2e": "nx e2e web-e2e",

There is a watch variant of the unit test run, and the end to end target can be run with a user interface through the separate `e2e:ui` script, which is the difference between a headless assertion run and a browser you can watch. The end to end project is named `web-e2e`, so the coverage is aimed at the documentation site rather than at the components in isolation.

Versioning follows a beta line that has just turned over. The recent releases include v1.0.1 on 2026-10-09, v1.0.0-beta.134 and v1.0.0-beta.133, both on 2026-10-08, which means the project was running numbered betas at a high rate right up to the first stable release. A consumer reading that sequence learns two things: the 1.0 line is new, and the component surface has been changing quickly until very recently.

The contributor workflow is described in the README as a simple GitHub Flow with automated releases, and the project keeps a contributing guide, a code of conduct, a security policy and a changelog at the repository root. The last push was on 2026-10-12, three days after the release noted above.

What to verify before adopting a component library this young

The first limitation is age. A library whose stable version appeared on 2026-10-09 after a long run of betas has, by definition, not yet been through the cycle where consumers report breakage, the project reacts, and the API settles. A team that plans to standardise on it should expect some churn in the component APIs and should pin to a specific release rather than tracking the newest tag.

The second limitation is where the information lives. The README is short and points to the documentation site, so there is no component list, no install command and no API reference inside the repository. That is a normal arrangement for this kind of project, but it means evaluating the library means reading the site, and it means the repository alone cannot tell you whether the specific component you need exists.

The third limitation is the cost of the toolchain. Running the project locally means Node, Nx, TypeScript executed through `tsx`, a Verdaccio registry for local package serving, Jest and end to end targets and Vercel deployment configuration. For a consumer of the components none of that is needed, but for a contributor it is the price of entry, and the number of separate check scripts is a sign of how many ways the generated artifacts can drift from the source.

What the project gets right is worth saying too. The licence is MIT, the code of conduct, security policy and changelog are present, the release automation is described, and the registry, CLI and MCP server are all built from the same source of truth, which is the arrangement that keeps a copy-in component library coherent over time.

Editorial conclusion

Adopt Zard/ui when you build Angular applications with Tailwind CSS and want components in the shadcn style, meaning source you own and edit, and when you accept that the component catalogue lives on the documentation site rather than in the repository README. Do not adopt it as a packaged Angular dependency if your pipeline expects a single npm install to provide every component, since the distribution model is a registry plus a CLI. Before starting, check the install instructions for the component you need, the release you take, since v1.0.1 shipped on 2026-10-09 after a long beta series, and the Node tooling the registry scripts expect.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. zard-ui/zardui on GitHub