Improvements/bug fixes release strategy

[mattphillips]

Hey @shadcn thanks so much for building this library it's awesome!

I've been using various components for a little while and am happy to see yesterday's release - congrats 🎉.

The new release has raised some interesting questions around versioning, bug fixes, improvements and overall depending on this library. I understand why you've chosen to not publish this as an npm package (for now) and I really like this approach as it gives me the flexibility to enhance the components as I see fit.

With that said, what is the recommended strategy to pull in improvements/fixes as a project depending on various components? Or is there a way to at least know that components have been updated / fixed (I'm thinking of versioning here)?

I'd love to hear your thoughts on this 😄

[shadcn]

@mattphillips Thanks for the ping on this.

To be honest, my original plan for these components was to provide more of a starting point or template rather than a full-blown library. Meaning you use it as a base to build your own and the code is pretty much yours after initialization.

However, with this project gaining traction, I'm revisiting my approach a bit.

I'm now looking into a solution for supporting updates either via documentation or using codemods.

I'll be sure to keep you updated on my progress and let you know as soon as we have something ready for testing.

[marcindulak]

I'm sorry for adding a comment in addition to bumping the existing :eyes:, but is there any progress wrt the update strategy?

Due to the specifics of this project, could some kind of helper functionality built into the cli be another option to consider in order to maintain components in a project that uses shadcn-ui?

[shadcn]

@marcindulak I'm working on a diff command to compare changes with upstream.

See https://ui.shadcn.com/docs/changelog#diff-experimental

[marcindulak]

Will it also include an indication of versions of the downstream component libraries (like cmdk used for https://ui.shadcn.com/docs/components/command or similar) used to generate the components?

When a security vulnerability is discovered in a downstream project or a new feature is needed, a helper to guide the downstream component upgrade path will be handy.

[wuleninja]

Hi, a thousand (at least) thanks for this excellent library, Morty! :) Love the avatar btw. I was going to suggest this exact same feature. In fact, I've stumbled upon the issue of packaging a component library that uses Shadcn, and thus Tailwind, which results in broken style in my depending app. And YOU confirmed my intuition about how I could handle my component library: with the now-much-beloved copy-paste paradigm! Packaging & releasing to NPM is such a hassle!! And with Tailwind, we have to [hack around]() to make it work in client apps, while not being sure to be able to override the default styles. But if my library is part of my client app's code... it's a wonderful world again, where everything works as dreamed!

Only thing is: what about versioning? Well, I already have a tool of my own that automates a lot of stuff (ramping up the backend part of my app in a k8s cluster, while connecting the frontend to the load balancer, generating code, compiling, downloading translations from gdrive, etc). I'm going to use it to download my library's code right into my project, as you did with your CLI tool.

But I'll also try to add some notion of version, so that all the apps using my lib will know about new versions. Probably using the version no of the package.json file.

[shadcn]

This issue has been automatically closed because it received no activity for a while. If you think it was closed by accident, please leave a comment. Thank you.

[elpddev]

@wuleninja Wanted to ask, the fact that Tailwind is bundled as npm package, does not stop you from taking Tailwind source from github, put it your code and maintain it. Would not that be essentially the same strategy as taking this lib and copying it?

[marcindulak]

@shadcn - please add more of your thoughts about this issue.

I see https://www.npmjs.com/package/shadcn-ui on npm. Is this a permanent change of direction, and https://ui.shadcn.com/docs#is-it-available-as-an-npm-package needs to updated to reflect it?

I would also like to explain a point of view which counters the approach of copy-pasting code from external, maintained projects present on npm. A code copy-pasted from a different project becomes an additional maintenance liability, both in terms its security and code evolution. When vulnerabilities are discovered, without the npm audit features it's harder to track and address the vulnerabilities. See an example at https://github.com/SheetJS/sheetjs/issues/2667#issuecomment-1250093342. One can argue that even when taking into account that some developers store production secrets on their machines, vulnerabilities discovered by npm audit may be irrelevant in some cases, see that view at https://overreacted.io/npm-audit-broken-by-design/, but they may become relevant in other cases, see https://jfrog.com/blog/malware-civil-war-malicious-npm-packages-targeting-malware-authors/ or https://www.aquasec.com/blog/can-you-trust-your-vscode-extensions/.

Now, when shacd-ui exists on npm, could you comment on the question how it could help in tracking the dependencies of the ui components it provides, like https://ui.shadcn.com/docs/components/accordion, on their downstream dependencies. I mean how can I get an extra hint when deciding whether in my project to update dependencies used by shadcn-ui like https://daypicker.dev/, https://www.embla-carousel.com/, https://recharts.org/en-US/, https://cmdk.paco.me/ or others? Will the update break any of the components I copied from shadcn-ui into my project?

[gpbl]

My 2 cents: I've just released a major version of the react-day-picker package (used by Calendar) and now users are confused why their code copied from shadcn-ui doesn't work anymore.

The shadcn-ui installation docs do not cite the version of the external package to install, and users are now installing an incompatible version. Others are opening a PR with a fix - but it seems difficult to see it merged anytime soon.

I believe the initial strategy "to provide more of a starting point or template" is failing when adding external dependencies. The need of a "release strategy" is a consequence of this design choice. @shadcn will end to rewrite a dependency system (like is partially doing with CLI), and well... good luck with that.

The good news is that release strategy and dependencies handling are issues already solved by npm.

This UI library looks great and deserves for sure a better treatment. In my opinion, to survive needs to be published to npm and adopt semver.

[shadcn]

@marcindulak The shadcn-ui npm package is just the cli. It pulls components from the registry. So the registry always holds the latest "versions" of the components.

@marcindulak @gpbl The cli has support for pinned dependencies (which I just did for react-day-picker while we upgrade to v9).

We don't really need to handle versioning inside the components since it's generally a thin layer on top of the dependencies. When you upgrade, you upgrade the underlying dependencies (in this case react-day-picker).

On our end, we'll make sure we test and document the upgrade for the components. See https://ui.shadcn.com/docs/components/input-otp#changelog as an example.