Why a shadcn registry alone is not enough for Payload installs
A concise guide to the gap between file delivery and true Payload-native installs, and why a CLI wrapper still matters even when a shadcn-compatible registry exists.
Registries distribute files. Payload-native installs also need schema registration, type generation, import-map updates, and compatibility checks around those files.
File delivery is necessary, but not sufficient
A registry is excellent at delivering files, dependencies, and a distribution format developers already understand. That solves part of the problem. It does not solve the Payload-specific repo updates that make those files usable inside a real project.
If the block still needs manual registration or cleanup after the files land, the install is not done yet.
Payload adds repo-wiring responsibilities
Payload adds a second layer of work on top of the registry. That second layer is exactly where brittle copy-paste flows usually fail.
- registering block configs in the right collection or layout
- wiring render components into the block renderer
- refreshing generated types after schema changes
- refreshing import maps when admin components move
The wrapper CLI owns the Payload-native workflow
That is why a wrapper CLI still matters. `init` can validate the project shape. `add` can coordinate the install steps in the right order. `doctor` can detect version drift, missing peers, and install conflicts before deploy.
Use the public layer to earn trust first
An open-core approach works well here. The public registry acts as the trust layer and proves install quality. Premium kits can come later, once the basic install story is obviously reliable and worth paying to repeat.
Want to turn this into a real install conversation?
Join the waitlist with source tracking attached, or inspect the public proof on GitHub if you want to validate the current alpha shape first.