标签：#shadcn

You know the drill. You build a beautiful set of shadcn/ui components for Project A — a Button, a Card, a Dialog with custom animations. Then Project B kicks off. You copy the files over. Then Project C. Then a subtle bug is found in the Button. Now you're patching it in three places. This is the classic monorepo problem, and it's exactly what I set out to fix. What I Built turborepo-react-shadcn-starter is a production-ready monorepo template that wires up: Turborepo for workspace orchestration and intelligent build caching React + Vite for the fastest possible frontend dev experience shadcn/ui as a shared package — write once, use everywhere TypeScript across the entire workspace ESLint with shared config baked in The key insight: shadcn/ui lives in @repo/ui , a shared package, not inside any single app. Every app in your monorepo consumes the same components from the same source of truth. The Problem with Typical Setups Most teams drop shadcn/ui directly into a single app. That works fine until you need a second app. Then your choices are: Copy-paste the components → drift and duplication immediately Publish to npm → versioning overhead for internal code Monorepo with a shared package → ✅ This is the right answer Turborepo makes option 3 near-effortless, but setting it up from scratch (workspace configs, TypeScript path aliases, ESLint sharing, shadcn CLI pointing at the right package) takes a few hours of trial and error. This starter eliminates all of that. What's Inside turborepo-react-shadcn-starter/ ├── apps/ │ └── web/ # Vite + React app ├── packages/ │ ├── ui/ # @repo/ui — shared shadcn/ui components │ ├── eslint-config/ # @repo/eslint-config │ └── typescript-config/ # @repo/typescript-config ├── turbo.json └── package.json apps/web — The Main App A clean Vite + React app already wired to consume components from @repo/ui . No boilerplate to delete, no config to untangle. packages/ui — The Shared Component Library This is where all your shadcn/ui components

\shadcn/ui and Material UI optimise for opposite priorities. Choose shadcn/ui to own your component code, ship a near-zero runtime, and control every pixel; choose Material UI (MUI) for breadth — 90+ components and a paid data grid — behind Google's Material Design. shadcn/ui has ~116,000 GitHub stars and ships copy-paste components; MUI has ~98,000 stars and ~7.3M weekly npm downloads. Both are MIT-licensed and free for commercial use. This guide covers the parts you only learn by shipping both: how each behaves in the Next.js App Router, the runtime cost, real theming and dark-mode code, forms, data tables, and migration mechanics. What's the real difference between shadcn/ui and Material UI? The difference is ownership, and it decides everything downstream. MUI is an npm dependency ( @mui/material ) you install and import from node_modules — you never touch the source. shadcn/ui is a copy-paste registry: you run a CLI, the component lands in your repo, and it is now your code. shadcn/ui is unstyled, built on Radix UI primitives and Tailwind CSS. MUI ships Material Design and an Emotion (CSS-in-JS) runtime. With MUI you install and import: bash npm install @mui/material @emotion/react @emotion/styled cta.tsx import Button from " @mui/material/Button " ; export function Cta () { return < Button variant = "contained" > Get started </ Button >; } With shadcn/ui the CLI copies the source into your project and you import from your own path — there is no library to upgrade or override: bash npx shadcn@latest add button cta.tsx import { Button } from " @/components/ui/button " ; export function Cta () { return < Button > Get started </ Button >; } That ownership changes how you customise. shadcn's button.tsx lives in your repo and uses class-variance-authority (cva) for variants — you add one directly: components/ui/button.tsx // components/ui/button.tsx — this file is yours const buttonVariants = cva ( " inline-flex items-center justify-center rounded-md ... " , { varia