shadcn cli v4 just turned every component library into a payload

shadcn just shipped cli v4. Almost everyone is reading it as a tooling update. It isn't. It's a distribution shift, and component libraries that don't catch up are about to disappear from the conversation.

What v4 actually changes

The headline feature is registry:base: one payload that ships components, dependencies, CSS variables, fonts, and config. Run a single command and an entire design system lands in the project — Tailwind config rewritten, tokens injected, components copied, fonts wired into next/font.

Before v4, "install a design system" was a four-step ritual: copy components, hand-merge the Tailwind config, hand-copy the CSS variables, install the right fonts. Each step was a place for the user to give up. v4 collapses it to one.

There's also registry:font as a first-class type. Fonts are now a payload the registry ships, not a separate next/font/google import the consumer has to wire themselves. And the new /skills namespace gives coding agents the registry-authoring context they need — agents that know how to consume a registry, and agents that know how to build one.

Three lines from the v4 changelog do almost all the work:

# Inspect what a registry will add before anything is written
npx shadcn view https://example.com/r/dashboard.json

# Add a whole design system in one shot
npx shadcn add https://example.com/r/base.json

# Author a registry that ships fonts + tokens + components together
npx shadcn registry build

The third one is the interesting one.

The economy that just opened up

Until v4, "ship a component library" meant ship an npm package. Consumers npm install, import from a barrel, and you're a dependency they can't easily remove. The tradeoff: black-box code, version-bump churn, and zero ability for the user to edit the component.

shadcn's pitch was always the opposite — copy-paste, own the code, no dependency. v4 turns that pitch into a deployable artifact. You author a registry, host the JSON anywhere (S3, R2, GitHub Pages, your marketing site), and any user with npx shadcn can install your design system in one command. No npm, no version negotiation, no peer-dep matrix. The user owns the code from second one.

That's an economy. And economies attract supply.

Within a month of v4 dropping, registry.directory listed dozens of independent registries — dashboard kits, animation libraries, charts, motion primitives, AI-component sets. Some free, some paid, some hybrid. None of them shipping npm packages. None of them locked into a single framework's release cadence.

If you're building a component library in 2026 and you don't ship a registry, you're delivering a worse product on a slower channel.

What we changed

We've been on the npm path with @otfdashkit/ui since launch. v4 changed how we think about the next twelve months.

Today — npm package for components that are pure JS/TSX with no heavy peer dependencies. npm install @otfdashkit/ui still works and isn't going anywhere.

This quarter — every component in our SDK is also published as a registry item at r.otf-kit.dev/<name>.json. Two channels, same source of truth, generated from the monorepo on every push.

Next — heavy-peer components (Skia animations, Lottie players, MMKV-backed stores) ship registry-only. The user installs the peer when they install the component, not when they install the SDK. The npm barrel stops being a dump for every cross-platform dep.

Then — the kits themselves become registry payloads. Buy a kit license, get a private registry URL, run npx shadcn add and the whole production codebase lands in your repo. No git clone, no template-copy, no manual config — and re-installing on a future client project takes one line.

Why this matters for agent-driven dev

The reason v4 is timed well is that Claude Code, Cursor, and Lovable now read registries natively. A user can paste a shadcn add URL into Cursor's chat and the agent installs the design system, then continues building against it. The registry is not just a distribution channel — it's a briefing format for the agent.

shadcn's /skills namespace makes that explicit. The skill gives the agent registry-authoring context: how registry.json works, which item types exist, how to express dependencies, how to handle CSS variables. Run a Cursor task like "add a new variant of our Card component to the registry" and the agent now knows what to write and where.

The honest take

We don't have our registry shipping in production yet. The infra exists (r.otf-kit.dev resolves), the build script is wired, but the registry JSONs aren't yet at parity with the npm packages. That's the next two-week sprint.

Until we get there, our kits are not "shadcn-CLI compatible" in the literal sense — we've corrected that copy across the marketing site after a maintainer flagged the gap. Honest framing is part of the brand. The registry ships when the registry ships, and we'll write a follow-up post the day it does.

The point isn't that we're early. It's that the channel is real, and every component library is about to have to decide whether to ship one. shadcn just made the answer obvious.