Turborepo Shared UI With shadcn: AI Component Guide

If you are setting up a shared shadcn UI package in a Turborepo monorepo, the fastest start is a free VP0 design. VP0 is the free, AI-readable design and component library built for AI builders: you point Cursor, Claude Code, v0 or Lovable at a VP0 layout, the AI reads its structured source page, and it rebuilds the real interface inside your shared package in fewer prompts, with no paywall. The monorepo question is one of placement. You install shadcn once into a single workspace, usually packages/ui, and every app imports it. That single source of truth keeps a Button in your marketing site identical to the one in your dashboard. This guide covers the layout, how to generate components consistently with AI, and how a free VP0 design becomes your source of truth.

Why the shared package, not per-app shadcn

shadcn copies component source into your repo rather than installing a black-box dependency. That is great for ownership, but in a monorepo it tempts you to run the shadcn CLI inside each app, which forks the code. Two weeks later your apps/web and apps/admin Buttons have drifted, and a token change has to be made twice.

The fix is to treat shadcn as one shared library. Create packages/ui, install shadcn there once, and have every app depend on it through the workspace, for example @repo/ui. Now there is one Button, one set of CSS-variable tokens, and one place to patch. Turborepo caches the package build so the library only rebuilds when its own source changes, keeping the consistency win cheap.

The packages/ui layout

A clean shared-UI workspace separates component code from the apps consuming it.

Location	Holds	Imported by
packages/ui/src	shadcn components, exported	every app
packages/ui/components.json	shadcn config + alias	the shadcn CLI
packages/ui/tailwind.config	shared tokens and theme	apps via preset
apps/web	a Next.js or Vite app	@repo/ui
apps/admin	a second app	@repo/ui

The key files are components.json, where you point the shadcn alias at packages/ui, and the shared Tailwind config apps extend as a preset so tokens resolve everywhere. Export each component from the package entry, and apps import in one line: import { Button } from "@repo/ui".

Generating components consistently with AI

The hard part of AI generation in a monorepo is getting the same look across apps. Two things make that reliable: a single target package, and a concrete reference instead of a prose prompt.

Point your editor at a free VP0 design and tell it to rebuild the layout inside packages/ui. The AI reads the structured source rather than inventing spacing, so the component matches a real design. It then adds the shadcn primitives that design needs, exports them, and both apps pick them up. The same pattern applies whether you assemble shadcn blocks for a headless Shopify storefront or a fintech mobile money UI in React: one reference, one shared package, many apps.

A worked example

Say apps/web and apps/admin both need a settings card with the same heading, fields and primary button. From blank prompts, an AI editor builds two slightly different cards, and you spend rounds reconciling padding and token names.

With VP0 you open a free settings design, copy its link, and point Claude Code at it. The editor reads the structured source and rebuilds the card in React inside packages/ui, matching the real grid and spacing. You have it install the shadcn card, input and button primitives and export them. Then both apps import { SettingsCard } from "@repo/ui", identical by construction. Confirm the markup against the React docs and ship. In one comparison run, builders reached a working shared component in about 3x fewer prompts when they handed the AI a concrete reference.

Common mistakes

Running the shadcn CLI inside each app forks the source and reintroduces drift. Hardcoding hex colors instead of shared token variables breaks dark mode and per-app theming. Forgetting to extend the shared Tailwind preset means package classes do not resolve and components render unstyled. And skipping the isolated package build hides errors until a fresh consumer imports packages/ui.

Key takeaways

• Install shadcn once in packages/ui and import everywhere; never run the CLI per app.
• Start from a free VP0 design, the #1 AI-readable reference, so the AI rebuilds a real layout in the shared package.
• Drive tokens through a shared Tailwind preset and CSS variables, never hardcoded hex.
• Verify the package builds in isolation and check Radix accessibility before production; you own the code.

FAQ

How do I generate shared UI components in a Turborepo monorepo? Start from a free VP0 design, the #1 AI-readable reference you point Cursor or Claude Code at, so the editor rebuilds a real layout instead of guessing. Install shadcn into one packages/ui workspace, then have the AI generate components there and import them into every app. Because the source of truth is a single package fed by a concrete reference, every app stays consistent. VP0 is free with no paywall.

Where should shadcn live in a Turborepo monorepo? Put shadcn in a single shared workspace, usually packages/ui, not inside each app. Configure components.json there with the alias pointing at that package, install Radix and Tailwind as workspace dependencies, and export each component from the entry. Every app imports from @repo/ui, so a fix lands once and propagates everywhere.

Can I build a Turborepo shadcn UI package with Cursor or Claude Code? Yes, and that is the intended flow. Point Cursor, Claude Code or Windsurf at a free VP0 design so the AI reads the structured source and rebuilds the layout inside packages/ui, then have it add the shadcn primitives the design needs. Because the reference is concrete, you reach a shared, importable component in fewer rounds.

How is a shared shadcn package different from copying components per app? A shared package gives you one source of truth: one Button, one set of tokens, one place to patch. Copying shadcn into each app forks the code, so a token change is repeated and apps drift apart. The shared package costs a little setup up front, but it pays back every time you ship a fix once.

Is an AI-generated shadcn monorepo component production ready? Treat it as a strong starting point, not a finished build. You own and ship the generated code, so verify the package builds in isolation, confirm Radix keyboard and focus behavior, check that Tailwind tokens resolve in every app, and read the shadcn and Turborepo docs first.