Why does shadcn components suddenly depend on "npm i shadcn"

[nova9]

<Switch/> component doesn't work without @import "shadcn/tailwind.css";. Manual installation doesn't mention that we need to add following to index.css

It’s unusual for shadcn to offload logic to an internal npm package. Is this an intentional change in philosophy, or an oversight?

@theme inline {
  @keyframes accordion-down {
    from {
      height: 0;
    }
    to {
      height: var(
        --radix-accordion-content-height,
        var(--accordion-panel-height, auto)
      );
    }
  }

  @keyframes accordion-up {
    from {
      height: var(
        --radix-accordion-content-height,
        var(--accordion-panel-height, auto)
      );
    }
    to {
      height: 0;
    }
  }
}

/* Custom variants */
@custom-variant data-open {
  &:where([data-state="open"]),
  &:where([data-open]:not([data-open="false"])) {
    @slot;
  }
}

@custom-variant data-closed {
  &:where([data-state="closed"]),
  &:where([data-closed]:not([data-closed="false"])) {
    @slot;
  }
}

@custom-variant data-checked {
  &:where([data-state="checked"]),
  &:where([data-checked]:not([data-checked="false"])) {
    @slot;
  }
}

@custom-variant data-unchecked {
  &:where([data-state="unchecked"]),
  &:where([data-unchecked]:not([data-unchecked="false"])) {
    @slot;
  }
}

@custom-variant data-selected {
  &:where([data-selected="true"]) {
    @slot;
  }
}

@custom-variant data-disabled {
  &:where([data-disabled="true"]),
  &:where([data-disabled]:not([data-disabled="false"])) {
    @slot;
  }
}

@custom-variant data-active {
  &:where([data-state="active"]),
  &:where([data-active]:not([data-active="false"])) {
    @slot;
  }
}

@custom-variant data-horizontal {
  &:where([data-orientation="horizontal"]) {
    @slot;
  }
}

@custom-variant data-vertical {
  &:where([data-orientation="vertical"]) {
    @slot;
  }
}

@utility no-scrollbar {
  -ms-overflow-style: none;
  scrollbar-width: none;

  &::-webkit-scrollbar {
    display: none;
  }
}

[shafisma]

Shadcn/ui is not a normal component package.
It provides the actual component source code directly into your project so you can fully own and customize it.

The new npm package called "shadcn" is only a CLI tool.
It helps automate adding components, installing required dependencies, and configuring Tailwind.

Because of this setup, the CLI may insert extra CSS imports like:
@import "shadcn/tailwind.css";
This file includes shared utilities and animations needed for some components.

That is why the Switch component did not work until that CSS was included.

This change is intentional and not an oversight.
The components still do not rely on a runtime package, only the tooling has changed.

[nova9]

Thank you for the reply @shafisma. @import "shadcn/tailwind.css"; does not get added automatically when running npx shadcn@latest add switch.

It's only being added when running npx shadcn@latest create. Which means Manual Installation has to mention to install shadcn using npm I shadcn and import the css file using @import "shadcn/tailwind.css";

[shafisma]

So, This now behaves like a documentation gap, not a philosophy shift.

[oxc]

I disagree. This is the first file that requires shadcn to be installed during compile time. Of course you can create your custom copy on your own, but so far shadcn did this for you, creating copies in your codebase. That's no longer the case now.

[nova9]

I disagree. This is the first file that requires shadcn to be installed during compile time. Of course you can create your custom copy on your own, but so far shadcn did this for you, creating copies in your codebase. That's no longer the case now.

Exactly. It seems like an implementation done by someone who couldn't imagine the implications of it. Or Vibe coding. Or both.

[oxc]

Not to mention that shadcn already modifies your tailwind.css to add stuff for components. I believe it would even add the accordion animations that are now also in tailwind.css. What was wrong with the old approach?

I would support a separate shadcn.css, which gets "exclusively" managed by shadcn. But you could probably already do that by specifying that file as tailwind.css in your components.json

On a side note, adding shacdn to my package.json has the downside of pulling in a lot of dependencies, some of which I already tried hard to get out of my node_modules (like zod 3)

[Nikhil1920]

This is quite unusual for shadcn. And there isn't even a mention of creating the file manually in the documentation. Is the change made to increase the npm downloads vanity metric.

[jkinley]

I agree. The docs on how to properly update your custom registry have not been helpful. I had to figure out a lot of the new changes by trial and error. Since the addition of shadcn/create there has to be shadcn node modules for shadcn/tailwind.css that gets imported into global.css as @import "shadcn/tailwind.css";. Without this the new styles like Luma, Mira, Novo, will not work correctly. I agree it is weird and not very clear unless you are always using the CLI. I for one, would love it if they would create a roadmap page in the docs to help give those that are using this for custom registries a heads up. It seems more recent changes have been geared towards one of uses of shad rather than a toolkit to build your own registry.

[vutran-tvg]

I can't get it.
Our production Docker builds started failing because shadcn pulls in @modelcontextprotocol/sdk@1.29.0 → hono@4.12.10 / @hono/node-server@1.19.12:

# npm audit report

@hono/node-server  <1.19.13
Severity: moderate
@hono/node-server: Middleware bypass via repeated slashes in serveStatic - https://github.com/advisories/GHSA-92pp-h63x-v22m
fix available via `npm audit fix`
node_modules/@hono/node-server

hono  <=4.12.11
Severity: moderate
Hono: Non-breaking space prefix bypass in cookie name handling in getCookie() - https://github.com/advisories/GHSA-r5rp-j6wh-rvv4
Hono has incorrect IP matching in ipRestriction() for IPv4-mapped IPv6 addresses - https://github.com/advisories/GHSA-xpcf-pg52-r92g
Hono missing validation of cookie name on write path in setCookie() - https://github.com/advisories/GHSA-26pp-8wgv-hjvm
Hono: Path traversal in toSSG() allows writing files outside the output directory - https://github.com/advisories/GHSA-xf4j-xp2r-rqqx
Hono: Middleware bypass via repeated slashes in serveStatic - https://github.com/advisories/GHSA-wmmm-f939-6g9c
fix available via `npm audit fix`
node_modules/hono

2 moderate severity vulnerabilities

Our CI runs npm audit --audit-level=moderate as a security gate. The audit fails, and we can't deploy. The vulnerable packages are a web hono that has nothing to do with CSS utilities or UI components.

The dependency chain: shadcn@3.8.5 → @modelcontextprotocol/sdk@1.29.0 → hono@4.12.10 / @hono/node-server@1.19.12
(yes, it's an old version, I'm happy with it until I see this issue)

I never expected a UI component library to bring a web server framework into my dependency tree. The philosophy of shadcn/ui was "copy the code, own it", no extra dependency unless the component required. But now I'm forced to install 241 packages including an MCP SDK and an HTTP framework — just to import a file containing accordion keyframes, Radix data-attribute variants, and a no-scrollbar utility.

[uranderu]

Hi @shadcn I would love to get your input on this. As you replied in this PR #10435 which addressed my "issue" #10415 This is an intentional choice.

As several people have described above this breaks the "copy the code, own it" promise that is fundamental to the project. It also introduces a massive amount of (heavy) dependencies by installing the entire project. Shadcn/ui already needs and modifies a "globals.css" file, why can't these rules be added there? This seems like a very hefty price to pay.

[ryanberg-slalom]

The standard "globals.css" file is exactly where I expected to see those shorthand variants added, after our Separator component added via CLI wasn't displaying correctly and I went digging. For now, we updated our separator component to use the non-shorthand data-attribute selectors. But we might copy the CSS in @nova9's post to our globals.css file if that'll be stable going forward.

[dantman]

I find most of these custom variants to be problematic. I only ended up in this thread after spending a bunch of time debugging why when I used pnpm dlx shadcn@latest add separator to overwrite the separator.tsx in an old project and the separator wasn't working at all.

I even went and debugged the separator code itself and eventually realized that data-horizontal:h-px was why it was not working. As it stands data-horizontal:h-px already looks like it means .data-horizontal\:h-px { &[data-horizontal] { height: 1px; } } so there is no way from looking at the code I should expect that data-horizontal: is actually a shadcn/tailwind.css custom selector not part of my codebase meaning .data-horizontal\:h-px { &:where([data-orientation="horizontal"]) { height: 1px; } } instead. So naturally this looked more like a mistake and I only ended up here after checking whether anyone had already made a PR to fix it.

I would be more understanding if this were namespaced like shadcn-horizontal or at minimum did not overload the existing TailwindCSS data- behaviour like orientation-horizontal to match the RadixUI/BaseUI orientation={orientation} prop. Those would actually lead to a "this is not built-in Tailwind CSS, it must be something custom" realization.

[a-axton]

With all of these dependabot issues lately I opted to just hardcode these in globals.css, it seems unnecessary to have a local dependency on shadcn especially when it holds some heavy dependencies. Shadcn already has patterns for creating utils + hardcoding things in globals.css I don't see how this is any different

[krizh-p]

You either die a hero, or you live long enough to see yourself become the villain. This definitely looks like an intentional philosophy change for the AI era

[HasanMothaffar-OSG]

Check out the May 2026 - shadcn eject entry here in the changelog: https://ui.shadcn.com/docs/changelog.

I stumbled accross this today by chance.

[sxppro]

It seems to me a pretty big change to force the components to be unusable out of the box without installing the dependency shadcn - isn't this why the library was made copy and paste in the first place? Seems to me a complete backflip on how shadcn UI was conceived.

I am curious to hear, from the creator's point of view, as to why this dependency was introduced, as well as the lack of documentation of it, especially on the components.

[shadcn]

Hi everyone. I go over why I had to do this in https://ui.shadcn.com/docs/changelog/2026-05-shadcn-eject and how you can eject out of it.

Let me know if this helps. Happy to answer any question here.

[uranderu]

While I get the reasoning, I do not see why this is the default. You already add custom CSS in the globals file. Why not for this as well? With all due respect but you do not address any of the criticism in this thread.