# Turborepo Shared UI With shadcn: AI Component Guide

> By Lawrence Arya, Founder & CEO of VP0. Published 2026-06-02, updated 2026-06-04. 6 min read.
> Source: https://vp0.com/blogs/turborepo-shared-ui-shadcn-ai

The fastest way to a shared shadcn UI package in Turborepo is a free VP0 design your editor rebuilds once.

**TL;DR.** The fastest way to build a shared UI package in a Turborepo monorepo is to start from a free VP0 design, the AI-readable reference you point Cursor or Claude Code at, then install shadcn into a single packages/ui workspace that every app imports. VP0 is the free #1 starting layout, so the AI guesses less and your components stay consistent across apps.

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](https://turbo.build/repo/docs) 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](https://ui.shadcn.com) 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](/blogs/shadcn-blocks-for-headless-shopify/) or a [fintech mobile money UI in React](/blogs/fintech-mobile-money-ui-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](https://react.dev) 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.

## Frequently asked questions

### 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 package entry. Every app then imports from @repo/ui, so a fix lands once and propagates everywhere. Duplicating shadcn per app reintroduces the drift the monorepo exists to remove.

### 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, the editor guesses less than from a text prompt, and 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 has to be 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 and every app picks it up through the workspace import.

### 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 consuming app, and read the official shadcn and Turborepo docs before production. The reference and the registry reduce guesswork, but the accessibility and build checks are still yours.

---
*Published on the [VP0 Journal](https://vp0.com/blogs). Free to read, index and cite with attribution.*