Centralized shadcn/ui component library vs. per-repo usage for enterprise teams

Help
,
1

I am looking for opinions from teams using shadcn/ui at scale.

We’re building an enterprise front-end ecosystem with multiple applications. We like shadcn’s philosophy (copy-paste, local ownership, Tailwind-first), but we’re debating how to apply it across many repositories.

The two options we’re considering:

Option A: Centralized component library

  • A shared npm package built on top of shadcn

  • Contains shared primitives, custom components, and opinionated patterns

  • Consumed by all apps

  • Centralized versioning, updates, and governance

Option B: Per-repo shadcn usage

  • Each app installs shadcn directly

  • Components are copied and owned locally per repo

  • Shared patterns are duplicated or synced manually

  • Maximum flexibility, less coupling

Key things we’re weighing:

  • Shared custom components
    (e.g., domain-specific components, complex compositions, behavior-heavy components)

  • Theme variability
    (multiple brands / themes, token overrides, future re-skinning)

  • Maintenance overhead
    (updating components across many apps, bug fixes, consistency)

  • Team autonomy vs consistency

  • shadcn philosophy alignment
    (does centralizing defeat the purpose?)

For teams who’ve gone down either path:

  • What has worked well at scale?

  • Where did you hit pain?

  • Did anyone start decentralized and later centralize (or vice versa)?

  • How do you handle theming and shared “non-primitive” components?

Looking for real-world experiences rather than a purely theoretical answer.

4

Have you considered creating your own shadcn registry?

1 Like