zedkit and shadcn/ui
Install @zedtech/zedkit-ui or copy published registry bricks — wraps, registry install, when to use plain shadcn, and FAQ.
Every claim below points at a file you can open in the public repo.
Who this is for
You already use shadcn/ui or Radix primitives and wonder whether
@zedtech/zedkit-ui replaces them, duplicates them, or sits beside them.
What zedkit wraps (verify in source)
The UI package lists runtime dependencies in
packages/ui/package.json.
Today that includes, among others:
| Library | Role in zedkit | Catalog example |
|---|---|---|
Radix UI (@radix-ui/react-*) | Accessible primitives for dialogs, menus, tabs, etc. | Open modal dialogs (Derived from: shadcn/ui (dialog) in CATALOG.md) |
vaul | Drawer motion and behavior | Slide in a drawer panel |
react-hook-form + zod + @hookform/resolvers | Form state and schema validation | Build validated forms |
@tanstack/react-table | Data table sorting, filtering, pagination | Show a sortable, filterable, paginated data table |
sonner | Toasts | Show toast notifications |
tailwind-merge, class-variance-authority, clsx | Class composition and variants | Merge class names without conflicts |
Each catalog need’s Wraps line names the direct npm dependency; many bricks also carry Derived from: shadcn/ui (...) when the component file follows the shadcn layout.
What zedkit adds
- Composed admin patterns — layout shell, data table, multi-step flows, and similar needs are first-class catalog entries, not only atomic primitives.
- Shared theme tokens —
packages/ui/src/styles.cssand Theme an admin app document dark/light setup for Tailwind v4. - Generated docs — catalog → MDX pages, live previews, and (for registry bricks) install
JSON from
registry.json(see COMPONENT-PAGE.md). - Thin wrappers elsewhere — non-UI packages follow the repo golden rule: one stable import surface over a mature library.
npm install vs registry (shadcn add)
| Path | When | What you get |
|---|---|---|
pnpm add @zedtech/zedkit-ui | You want the published package API and CSS entry | Imports from @zedtech/zedkit-ui; version pinned on each doc page’s Install tabs |
npx shadcn@latest add https://zedkit.app/r/<brick>.json | You want source files in your repo like upstream shadcn | Hosted JSON from pnpm registry:build. Register @zedkit first for composed items (below). Init with --base radix --preset nova (kit bricks are Radix, not Base UI). |
Registry bricks are listed in registry.json; only published JSON URLs under /r/ are
documented on component pages. If a brick is not in the registry yet, use npm imports until
it ships.
Adding registry bricks
Initialize with the Radix preset, then add the hosted JSON:
npx shadcn@latest init -y --base radix --preset nova
npx shadcn@latest add https://zedkit.app/r/badge.jsonComposed bricks (drawer, confirm-dialog, …) declare @zedkit/* siblings. Register the
docs namespace once in a project with components.json:
npx shadcn@latest registry add @zedkit=https://zedkit.app/r/{name}.jsonThen run shadcn add for the composed item. Install the theme brick
when you need shared success/warning/overlay tokens and motion utilities without the npm
styles.css package.
Updating copied files
After a copy, the files are yours (MIT). There is no automatic update channel.
- Registry URLs always resolve to the latest published item — they are not version-pinned.
- Compare upstream changes:
npx shadcn@latest add <same-url> --diff. - Replace your edits:
npx shadcn@latest add … --overwrite(review the diff first). - npm path: bump
@zedtech/zedkit-uiwith your package manager instead.
Full theme tokens and styles.css still come from the npm package today; copied bricks only
ship the CSS slices attached to each registry item plus the optional theme brick.
When to prefer plain shadcn/ui
Stay on upstream shadcn/ui (or your own forks) when:
- You need full control over every component file and do not want a versioned package boundary.
- Your design system diverges from the kit tokens and you will not adopt
styles.css. - You only need one primitive and none of the composed catalog needs apply.
Reach for zedkit when several catalog needs match your admin app and you want docs, previews, and install commands to stay aligned with the npm release.
Scenario
You start a Next.js admin app. You install @zedtech/zedkit-ui, follow the theme doc, and
copy the Button usage from Trigger actions with buttons.
Later you add a drawer via npx shadcn add using the registry URL on that component page so
the file lands in your tree with the same import paths the docs show.
Troubleshooting
| Symptom | What to check |
|---|---|
shadcn add 404 | Brick not published yet — check registry.json and the component page’s Install section. |
| Styles look like unstyled HTML | Theme doc not applied (Tailwind v4 + kit CSS). |
| Types differ from shadcn docs | You imported @zedtech/zedkit-ui; props match the generated Props table on the catalog page, not third-party snippets. |
| Want only Radix, no kit | Use Radix directly; zedkit does not block that — it is an optional layer. |
FAQ
How is zedkit different from shadcn/ui?
shadcn/ui is a copy-into-your-repo workflow around Radix primitives. zedkit ships a versioned npm UI package plus optional registry JSON for some bricks. It adds composed admin patterns, shared theme tokens, and generated docs aligned with catalog needs. It does not replace upstream shadcn when you want every file local-only.
Can I copy zedkit components like shadcn/ui?
Yes, for published registry items: npx shadcn@latest add https://zedkit.app/r/<brick>.json in a project with components.json. 33 registry bricks are published today; the rest of the kit is npm-only. Copied files live in your repo — you own them (MIT). Updates are manual unless you run shadcn add again with --overwrite.
Does zedkit lock me in?
On the npm path you depend on @zedtech/zedkit-ui like any MIT package — remove it if you outgrow it. On the copy path the source is yours with no proprietary runtime. Registry URLs always serve the latest published item (not version-pinned). Full theme tokens and styles.css still come from the npm package today.
Is zedkit production-ready?
It is public MIT software under active development. Catalog maturity labels apply: stable needs have no badge and follow semver on 1.0 packages; alpha and beta entries can still change. Use the maturity legend and compatibility matrix before betting a critical launch on a specific need.
Next steps
- Getting started — prerequisites and first commands
- Golden rule — wrapping other libraries in core, server, or nest
- Documentation index — pick a need by folder