OpenWikishadcn-ui/ui

Vite Installation

Purpose and Scope

This page explains the Vite path for installing shadcn/ui, with an emphasis on the decisions a developer makes before the first component is added. In the official installation spine, a new project can begin from a visual preset builder, a terminal scaffold command, or an existing app. The Vite guide follows that same structure and specializes it for React applications created with the Vite template. Use this page when you want to understand not only which command to run, but also how generated components are expected to be imported and where monorepo conventions change the import surface.

Sources: apps/v4/content/docs/installation/vite.mdx, apps/v4/content/docs/installation/index.mdx

The core idea is that shadcn/ui does not behave like a closed component package that you only consume through a dependency. The CLI writes component source into your application, and then your app imports that local source through the configured aliases. In a single Vite app, the examples import from the app-local components directory. In a Vite monorepo, the UI package becomes the shared component home, so the consuming app imports from a workspace package instead. That distinction is important because it affects every later component import, refactor, and design-system extraction.

Sources: apps/v4/content/docs/installation/vite.mdx, templates/vite-monorepo/apps/web/src/main.tsx

Relevant Source Files

  • apps/v4/content/docs/installation/vite.mdx — Primary Vite installation guide, including the three setup paths, Vite scaffold commands, component add commands, and Card import examples.
  • templates/vite-monorepo/apps/web/src/main.tsx — First-party Vite monorepo entrypoint showing the web app importing shared globals, wrapping the app in a theme provider, and rendering the generated application root.
  • apps/v4/content/docs/installation/index.mdx — Shared installation overview that recommends shadcn/create for new projects and defines the common create, CLI, and existing-project choices across frameworks.
  • apps/v4/content/docs/installation/astro.mdx — Neighboring framework guide that mirrors the same create, CLI, add-component, and monorepo workspace guidance, useful for recognizing the shared installation pattern.
  • apps/v4/content/docs/installation/gatsby.mdx — Legacy-style installation guide showing the manual setup responsibilities that appear when a framework needs explicit path and tooling configuration.
  • apps/v4/content/docs/installation/laravel.mdx — Framework-specific guide showing that some environments require creating the host application first before running shadcn initialization.

Choosing a Vite Setup Path

For a new Vite application, the recommended first choice is shadcn/create. The shared installation overview explicitly presents shadcn/create as the recommended path for new projects because it lets you build a preset visually and then copy the generated framework-specific command. The Vite guide applies that by linking to a Vite-specific preset builder, where you choose style, colors, fonts, icons, and related options before generating a command. This is the best path when the project’s visual baseline is still being decided and you want the generated setup command to encode those choices.

Sources: apps/v4/content/docs/installation/index.mdx, apps/v4/content/docs/installation/vite.mdx

The direct CLI path is for developers who already know they want the Vite template and prefer to configure the project from prompts in the terminal. The Vite guide uses the template flag to scaffold directly, then asks the user to follow prompts for base, preset, monorepo, and related choices. That path still produces the same kind of project result: a configured Vite application that can receive registry components through the add command. Use this path when command-line setup is faster than opening the visual builder, or when you want to script the initial project creation.

Sources: apps/v4/content/docs/installation/vite.mdx

An existing Vite project is different because the app already has a source tree, dependency set, and build configuration. The shared installation overview says each framework guide includes an existing-project section with manual setup steps for that framework. The Vite page positions this as the route for manually configuring shadcn/ui in an app you already created. That choice is less about scaffolding and more about aligning aliases, styling, and component output locations with the conventions that the CLI expects when it later installs files.

Sources: apps/v4/content/docs/installation/index.mdx, apps/v4/content/docs/installation/vite.mdx

Command Flow

The preset-builder flow starts with a generated init command. The Vite guide shows the command shape as a preset token plus the Vite template. The exact command can include additional selected options such as base components, monorepo layout, or right-to-left support. Treat the displayed command as the contract between the visual choices and the CLI: once copied into your terminal, it creates the project with those choices already encoded, so the following component installation step can assume the expected file layout.

npx shadcn@latest init --preset [CODE] --template vite

Sources: apps/v4/content/docs/installation/vite.mdx

The terminal-only scaffold path uses the same CLI but replaces the preset token with an explicit template selection and interactive prompts. For a normal Vite project, the documented command is the template-specific init invocation. For a monorepo Vite project, the guide adds the monorepo flag at creation time. Setting that shape up front matters because the later add command and the import path in the application are different when the UI components live in a workspace package rather than inside the app’s own source directory.

npx shadcn@latest init -t vite
npx shadcn@latest init -t vite --monorepo

Sources: apps/v4/content/docs/installation/vite.mdx

After initialization, the Vite guide demonstrates the workflow by adding the Card component. The same add command is used for both create-based and CLI-based setups. In a monorepo, the guide gives two equivalent operational choices: run from the app workspace, or run from the repository root while pointing the command at the app configuration. The documented root form uses the configuration flag with the web application path, which keeps the command anchored to the app that should receive the component wiring.

npx shadcn@latest add card
npx shadcn@latest add card -c apps/web

Sources: apps/v4/content/docs/installation/vite.mdx

Component Imports in Vite Apps

Once the Card component is added, the Vite guide imports the generated component parts from the local UI component path and renders them in the application component. The example uses Card, CardHeader, CardTitle, CardDescription, and CardContent together, which demonstrates the normal composition model: the CLI installs source, and the app assembles that source into product UI. The important point is that imports come from the application’s configured alias rather than from a central shadcn/ui runtime package. Your own components should follow the same local import pattern after they are added.

import {
  Card,
  CardContent,
  CardDescription,
  CardHeader,
  CardTitle,
} from "@/components/ui/card"
 
function App() {
  return (
    <Card className="max-w-sm">
      <CardHeader>
        <CardTitle>Project Overview</CardTitle>
        <CardDescription>
          Track progress and recent activity for your Vite app.
        </CardDescription>
      </CardHeader>
      <CardContent>
        Your design system is ready. Start building your next component.
      </CardContent>
    </Card>
  )
}
 
export default App

Sources: apps/v4/content/docs/installation/vite.mdx

For a Vite monorepo, the import changes to the workspace UI package. The Vite guide states that the application should update the web app’s App file and import the Card component from the workspace package path instead. The template entrypoint reinforces this layout: the web app imports shared globals from the workspace UI package, imports its local App file, and wraps rendering in a theme provider. That means the app stays responsible for rendering and application composition, while the shared UI workspace carries reusable components and global styling.

import "@workspace/ui/globals.css"
import { App } from "./App.tsx"
import { ThemeProvider } from "@/components/theme-provider.tsx"

Sources: apps/v4/content/docs/installation/vite.mdx, templates/vite-monorepo/apps/web/src/main.tsx

System-to-Code Mapping

The Vite installation page is both user guide and source-of-truth for the workflow labels used in the docs UI. Its cards are not arbitrary marketing choices; they define the three supported reader entry points: build a preset, scaffold from the CLI, or configure an existing Vite project. The shared installation index uses the same categories across frameworks and names Vite as one of the templates supported by the template flag. When keeping docs, templates, or CLI prompts aligned, start with these two files because they establish the public sequence developers see.

Sources: apps/v4/content/docs/installation/vite.mdx, apps/v4/content/docs/installation/index.mdx

The neighboring installation guides show which parts of the workflow are universal and which are framework-specific. Astro mirrors the same create, CLI, add-component, and monorepo guidance but changes the example file and component import context to an Astro page and layout. Laravel shows an environment where the host app must be created first and shadcn initialization runs afterward. Gatsby shows a more manual path involving TypeScript and alias configuration. These comparisons help clarify that the Vite path is intentionally streamlined: scaffold or configure the Vite app, then add and import source components.

Sources: apps/v4/content/docs/installation/astro.mdx, apps/v4/content/docs/installation/laravel.mdx, apps/v4/content/docs/installation/gatsby.mdx

Practical Checklist and Next Steps

Use this checklist when setting up a Vite app. First, decide whether the project is new or existing. For a new project, choose shadcn/create if visual preset selection is useful, or use the CLI template command if you already know the desired setup. Second, decide whether the project should be a single app or a monorepo. Third, add a component such as Card to confirm that component generation works. Finally, verify the import path: app-local Vite projects use the components alias, while monorepo apps import reusable UI from the workspace package.

Sources: apps/v4/content/docs/installation/vite.mdx, templates/vite-monorepo/apps/web/src/main.tsx

After the first component renders, continue with pages that explain the configuration files behind the workflow. Read the CLI reference to understand init and add options more deeply, the monorepo guide if you chose the workspace layout, and the components.json reference to understand how aliases and output locations are controlled. If your setup is an existing application rather than a generated template, compare the Vite flow with the manual installation and package import guidance before adding many components, because early alias decisions determine how maintainable future imports will be.

Ask a question...