Wouldn’t someone using Shadcn just use their cli and install all the things? Wouldn’t a company using Shadcn have their own git or npm of which they can install custom private packages? I’m at a loss at what exactly the value prop of this is.
Wouldn’t someone using Shadcn just use their cli and install all the things? Wouldn’t a company using Shadcn have their own git or npm of which they can install custom private packages? I’m at a loss at what exactly the value prop of this is.
I believe the answer comes from this line:
> Custom Registry Support
This is effectively the shadcn CLI, but with the ability to add custom sources of content in the form of registries. Imagine you want to add a shadcn component, a fontawesome icon, or another custom library component. Wouldn't it be nice to have it all accessible via one unified interface.
Anything that promotes more code-owning and fewer dependencies for lower level items (components, icons, etc.) is a win in my book.
Similar prior art is sly-cli: https://sly-cli.fly.dev
@OP: I'd consider renaming your project to avoid co-opting the shadcn name, though. For your benefit and for shadcn's.
Don’t we have that already with rollup in vite? I simply import it into my jsx and use it. Npm is that interface. I guess I just don’t understand the pain this is trying to solve. I import Shadcn components, I import fontawesome icons, or hero icons, or SVG, or whatever you want. The rollup bundles everything into my public folder ready to be content-delivered. All of this is done with vite. Sly uses vite. So again, a cli tool on top a cli tool on top a cli tool just so you don’t have to import a sheet with svg’s you probably won’t use. Reducing bundle size. Great. Abstracting it all on top of an ecosystem on top of an ecosystem? Not great. Sorry. I’ll never have a use for sly or shadxn or anything that simply abstracts the layer beneath and claim it’s innovative. Vite is doing the work.
I want my own button component, not one that requires upgrades, changes, or a million hidden deps.