Inconsistent code between website, repo, and CLI. Why?

[jkinley]

The toggle from the repo and website have this code:

const toggleVariants = cva(
  "cn-toggle group/toggle inline-flex items-center justify-center whitespace-nowrap outline-none hover:bg-muted focus-visible:ring-[3px] disabled:pointer-events-none disabled:opacity-50 [&_svg]:pointer-events-none [&_svg]:shrink-0",
  {
    variants: {
      variant: {
        default: "cn-toggle-variant-default",
        outline: "cn-toggle-variant-outline",
      },

The toggle from the CLI install has this code:

const toggleVariants = cva(
  "group/toggle inline-flex items-center justify-center gap-1 rounded-lg text-sm font-medium whitespace-nowrap transition-all outline-none hover:bg-muted hover:text-foreground focus-visible:border-ring focus-visible:ring-[3px] focus-visible:ring-ring/50 disabled:pointer-events-none disabled:opacity-50 aria-invalid:border-destructive aria-invalid:ring-destructive/20 aria-pressed:bg-muted data-[state=on]:bg-muted dark:aria-invalid:ring-destructive/40 [&_svg]:pointer-events-none [&_svg]:shrink-0 [&_svg:not([class*='size-'])]:size-4",
  {
    variants: {

So what is going on? What is this new cn-* class pattern? Is it an old pattern now? What is the source of truth?

[jkinley]

I better understand it now. The cn-pattern will be in the raw components in github. They are used to build the various styles. I don't know why I was having an issue with the manual install of the toggle-group. I promise the CSS was not rendering correctly. Anyway, not sure I am a fan of the new shadcn/create anymore. Feels like its added a lot of complexity for not much gain.

[jkinley]

So I figured it out. The reason the toggle-group CSS was 'messed-up' was bc when you run the CLI it now installs this in your global.css:

@import "shadcn/tailwind.css";

Since I have a custom registry without a components.json and I have installed all the components manually, I never would have known I need this. As I understand it, depending on what you select what adding a components.json, it uses this at build time to add the proper CSS for the style you pick luma, mira, etc.

So since our custom registry did not use shadnc/create. No idea what to to now to make sure that our components will work predictably. And so now shadcn is utitlizing node modules. I do not get this move at all. Maybe it has some benefits but it sure is making it difficult to update our custom registry.

I hope this helps someone. I will continue to research, test, and experiment and post my findings here.

[Rick1330]

Understanding Version Mismatches in shadcn-ui

I see you've noticed inconsistencies between the website documentation, the source code in the repository, and what the CLI actually installs. This is a common point of confusion for new users!

The Root Cause:
The shadcn-ui project is moving incredibly fast. The website (ui.shadcn.com) and the CLI fetch components from a Registry. This registry is often a snapshot or a specific versioned branch, whereas the "Source Code" you see in the main branch of the GitHub repo might contain experimental features or refactors that haven't been "published" to the registry yet.

Why the CLI might look different:

1. Registry Sync: When you run npx shadcn@latest add, it pulls from https://ui.shadcn.com/registry. If the maintainers updated the registry but didn't update the "manual" docs yet (or vice-versa), you'll see a gap.
2. CLI Versions: If you aren't using @latest, you might be pulling from an older registry schema.
3. Tailwind/React Versions: Recent updates have started preparing for Tailwind v4 and React 19/Next.js 15, which caused significant changes to the "base" components (like the utils.ts and button.tsx).

Best Practices for Consistency:

• Trust the CLI: The CLI is the most "stable" way to get components that work with your current components.json configuration.
• Check the canary branch: If you want to see the "bleeding edge" code that matches the most recent changes, look at the canary branch in the repo instead of main.
• Manual Updates: If you see a feature on the website that you love, but the CLI doesn't give it to you, it's often easiest to just copy the JSX directly from the website's "Code" tab.

If this helps explain why you're seeing different versions of the code, please mark it as the answer!

[jkinley]

Thanks, @Rick1330, but this was not the issue. The issue is that now you must have this in your shadcn project or the styles will not work correctly. For developers making their own registries before shadcn/create came a long, this is confusing and not well documented. For things to work correctly with a custom registry, you must update your registry to incorporate the new styles correctly, or shadcn will not work correctly. I had to create a testing project and build with shadcn/create and then reverse-engineer my registry to update it a make it work with the new changes.

@import "shadcn/tailwind.css";

[Rick1330]

@jkinley Great catch on the @import "shadcn/tailwind.css"; requirement. You've hit on a major shift in how shadcn handles its new styling engine.

For custom registries that were built before the latest CLI update, this is indeed a "breaking" change because shadcn is moving from "pure copy-paste of utilities" to a hybrid model where some base styles are encapsulated in that node_module import to support the newer design systems. Your solution of reverse-engineering the create template is exactly the right move for anyone maintaining a legacy registry. Thanks for sharing the specific CSS entry point!

[jkinley]

@jkinley Great catch on the @import "shadcn/tailwind.css"; requirement. You've hit on a major shift in how shadcn handles its new styling engine.

For custom registries that were built before the latest CLI update, this is indeed a "breaking" change because shadcn is moving from "pure copy-paste of utilities" to a hybrid model where some base styles are encapsulated in that node_module import to support the newer design systems. Your solution of reverse-engineering the create template is exactly the right move for anyone maintaining a legacy registry. Thanks for sharing the specific CSS entry point!

Yeah, I have found out the hard way. This shift is really unfortunate for people that want to use shadcn for custom registries. We can't really tap into the presets as every time you apply a preset it overrides all the components.

Have customized components? Too bad they get over-ridden. Have custom variants with updated CVA values ( you know, for things like statuses- primary, warning, success), they all get over-ridden. I really like the idea behind the presets, but the way it is implemented is more for devs directly consuming shadcn; not using it to make their own design system. This seriously gives me pause on that to expect on the future of shadcn for custom registries.

[lokeshwardewangan]

yeah this is a bit confusing 😅

you’re basically seeing two different versions:

• cn-* classes → newer/experimental style system (used in repo/site)
• CLI output → stable version with Tailwind classes inline

CLI doesn’t use the cn-* pattern yet, so it looks different.

nothing is wrong, just not fully consistent right now.

if you want safe option → follow CLI
if you want that cn-* setup → you’ll have to wire it manually

kinda feels like they’re still figuring this part out tbh

[jkinley]

@lokeshwardewangan Thanks for some of the clarity! I am glad I am not the only one feeling somewhat confused.