When you run a Vite project locally, the browser requests source modules as it needs them, so code changes can appear quickly. During development, Vite avoids [bundling the full application up front](https://vite.dev/guide/why), transforms requested modules, and uses hot module replacement (HMR) to update the affected module graph. For production, Vite bundles and optimizes the application so the browser does not need to fetch a large number of nested imports at runtime.

Framework plugins add framework-specific transforms and refresh behavior. Projects may still need configuration for environment variables, path aliases, monorepos, SSR, or custom builds. Deployment introduces separate hosting and routing decisions, including SPA rewrites.

## [Copy link to heading](#development-server-and-build-system)Development server and build system

Running `vite` starts the development server, while `vite build` produces deployable assets. Both commands use the same project configuration but run different pipelines.

React and Vue supply their own runtime behavior through framework integrations. Vite supplies the plugin surface, transformation hooks, and HMR APIs those integrations use.

## [Copy link to heading](#on-demand-source-modules)On-demand source modules

The development server starts by separating dependencies from application source. Dependencies often contain many internal modules but change infrequently. Vite pre-bundles them with Rolldown in Vite 8 to reduce the number of browser requests and convert packages with CommonJS or UMD entry points into ES modules the browser can consume.

Vite does not bundle the full application before the development server starts. Instead, it waits for the browser to request an entry module, then intercepts each import it discovers, applies the necessary transforms, and serves the result over native ES modules. Because unrequested routes and features are not processed, they do not delay server startup.

## [Copy link to heading](#hot-module-replacement)Hot module replacement

After the initial load, Vite tracks modules and their import relationships. When a file changes, the update moves through the affected importers until it reaches an [accepting HMR boundary](https://vite.dev/guide/api-hmr). If a framework plugin can accept the update there, it can replace a component without a full reload and preserve its state. Otherwise, Vite reloads the page and resets the application’s in-memory state.

## [Copy link to heading](#rolldown-and-oxc)Rolldown and Oxc

Vite orchestrates the production build. Rolldown bundles the application and performs production optimizations, while Oxc provides high-performance parsing and transformation within the toolchain.

Oxc handles [JavaScript transformation and minification](https://vite.dev/blog/announcing-vite8#a-unified-toolchain) within the toolchain. Rolldown also uses Oxc components for parsing, module resolution, and built-in syntax transforms.

## [Copy link to heading](#framework-plugins)Framework plugins

Vite provides the shared build and HMR hooks. Framework plugins, such as the official React and Vue integrations maintained in the Vite organization, use those hooks to transform framework-specific files and refresh components without unnecessarily reloading the page.

Vite also draws a clear line around TypeScript support. It transpiles `.ts` and `.tsx` files so they can run in the browser, but it does not type-check them. Type errors must be caught by a separate process, such as `tsc --noEmit` in an npm script or CI, or by an editor integration during development.

Vite, framework plugins, and application code each own different parts of the development workflow. When something goes wrong, that separation makes it easier to identify where to look. Vite handles syntax transforms, a framework plugin may preserve component state during refresh, and the application owns its runtime exceptions.

## [Copy link to heading](#project-configuration)Project configuration

Vite's defaults cover a standard development server and production build. You still need to configure project-specific requirements, such as how the app reads environment variables, resolves imports, handles workspace packages, or renders on the server.

- **Environment variables:** values prefixed with `VITE_` are exposed to client code. They must not contain secrets, and their values arrive as strings unless the application converts them.

- **Path aliases:** `resolve.alias` remains available. Vite 8 can opt into `tsconfig` path resolution with `resolve.tsconfigPaths: true`. That option is off by default and has a small performance cost.

- **Libraries and monorepos:** library mode changes the files Vite generates and how other projects consume them. Linked workspace dependencies are treated as source, and non-ES-module dependencies may need optimizer configuration.

- **SSR and unusual builds:** Vite exposes low-level SSR APIs, but higher-level frameworks and plugins often own the application integration. Custom asset manifests, repository roots, and output conventions can also require config.

## [Copy link to heading](#create,-run,-and-build-your-first-vite-project)Create, run, and build your first Vite project

Start by creating a Vite project and running it locally. Vite 8 requires [Node.js 20.19+ or 22.12+](https://vite.dev/guide/), and individual templates can set a higher requirement, so confirm the project's Node version before scaffolding.

Scaffold a React project, enter the directory, and install its dependencies.

```
npm create vite@latest my-vite-app -- --template react
cd my-vite-app
npm install
```

The extra `--` forwards `--template react` through npm to the Vite scaffolder. You can substitute another supported template or omit the template flag and choose interactively.

Start the development server.

```
npm run dev
```

Open the local URL printed in the terminal. Then change visible copy in a component and save it. The browser should receive an HMR update through the development module graph without waiting for a production bundle.

Build the production output.

```
npm run build
```

For a standard project, Vite writes the production assets to `dist`.

Serve those assets locally for a production-build check.

```
npm run preview
```

Use `vite preview` to serve the built files locally and catch asset-path or production-only issues before deployment. It is intended for local inspection, not as the server for a production site.

## [Copy link to heading](#coding-agent-workflows)Coding-agent workflows

Vite's short feedback loop also suits coding-agent workflows. An agent can make a change, observe the result through HMR, and run a production build as a separate checkpoint. Vite speeds up validation, though it cannot judge the quality of generated code.

Vite 8 makes browser failures more visible to terminal-based workflows through [`server.forwardConsole`](https://vite.dev/config/server-options#server-forwardconsole). The setting can activate automatically when `@vercel/detect-agent` detects an AI coding agent. With the value set to `true`, Vite forwards unhandled errors plus `console.warn` and `console.error`; other console levels require explicit `logLevels` configuration.

Forwarded errors give an agent useful runtime evidence without requiring someone to copy messages from the browser. They do not show what the rendered interface looks like, so verifying visual behavior still requires browser automation, tests, or another way to inspect the application in a browser.

## [Copy link to heading](#deploying-vite-on-vercel)Deploying Vite on Vercel

Local validation checks the project on one machine. A deployment makes that result available to another developer, reviewer, or automated check. When Vercel detects a supported Vite project, it can configure the [standard build command and output directory](https://vercel.com/docs/builds/configure-a-build) without requiring those fields to be entered manually. If your project uses a custom build or Vercel does not detect it as Vite, configure the build command and output directory yourself.

With a Git-connected Vercel project, a push to a non-production branch creates a [Preview Deployment](https://vercel.com/docs/git), and a pull request receives a unique Preview Deployment with its own URL, which reviewers can open. A commit URL stays tied to that specific commit, while a branch URL tracks the latest deployment for the branch.

To deploy directly from your project directory, use the Vercel CLI. If the Vercel CLI is not already installed, install it and authenticate by running `vercel login`. Then run `vercel` from your project directory to create a Preview Deployment. The CLI may prompt you to link the directory to a Vercel project. Automated workflows can also deploy through the REST API. Vercel MCP lets an authenticated AI agent deploy project files directly to Vercel. The [`deploy_to_vercel`](https://vercel.com/docs/agent-resources/vercel-mcp/tools) tool can create the project if needed, without a Git repository or the CLI. This feature is currently in Beta, so we recommend human confirmation before the tool runs.

## [Copy link to heading](#deployment-configuration)Deployment configuration

A successful Vite build still leaves routing, rendering, repository layout, and custom output behavior to the project. A client-side single-page application that uses history-based routing needs a catch-all rewrite on Vercel so a direct request to a nested route reaches `index.html`:

```
{
  "rewrites": [
    { "source": "/(.*)", "destination": "/index.html" }
  ]
}
```

The rewrite applies to a client-side SPA. SSR and full-stack projects use different runtime and framework integrations. A monorepo may need an explicit project root, and custom output directories or build commands may need project settings.

The word “preview” also names two different checks. `vite preview` serves a production build locally. A commit-specific Vercel deployment URL identifies a stable snapshot, subject to the project's retention and access settings. A branch URL tracks the latest deployment for that branch.

## [Copy link to heading](#vite-faqs)Vite FAQs

**Is Vite a framework?**

No. Vite is a development server and build tool. Frameworks such as React, Vue, and Svelte integrate through plugins and supply the application's runtime behavior.

**Is Vite a bundler?**

Vite is a development server and build tool rather than a standalone bundler. It serves source modules during development and orchestrates production bundling with Rolldown.

**Does Vite bundle source during development?**

Vite pre-bundles dependencies and serves application source modules on demand during development.

**Does Vite type-check TypeScript?**

No. Vite transpiles TypeScript syntax but does not perform type checking. Run a TypeScript compiler or another type-checking tool separately.

**Can** `**vite preview**` **host a production site?**

Not as a production deployment. The command serves the production build locally for inspection. Use a production hosting platform to deploy the output.

Vite keeps the local workflow fast by serving source on demand, applying focused HMR updates, and building optimized production assets. Vercel carries those assets into a deployment that a team can review through a generated URL.