Vite: instant development server and production build

On a sizable project, the previous generation of tools rebuilt everything before showing the first page. Thirty seconds of waiting at startup, several seconds after every save, and attention drifts away.

Vite started from a simple observation: browsers can read ES modules on their own, so they may as well receive the files as they are.

Definition

Vite is a development tool combining two things: a server that hands your sources over as native ES module, without bundling them, and a build command that produces the optimized version for release.

// vite.config.js
import { defineConfig } from 'vite';

export default defineConfig({
  server: { port: 3000 },
  build: {
    outDir: 'dist',
    sourcemap: true,
  },
});

A project starts with npm create vite@latest, which lays out the structure and the dependencies. Everything after that fits in two scripts: vite to develop, vite build to produce the folder you ship.

Two modes, two engines

In development, nothing is bundled. The browser requests files one by one, Vite transforms them on the fly and sends back only the one that just changed. That is what makes startup independent from the size of the project.

For production the opposite applies: a Bundler groups, prunes and minifies, because a hundred requests would cost the visitor far too much. Installed dependencies are prepared upfront by a fast tool, which avoids re-processing them at every start.

Three conventions worth knowing

• index.html is the entry point: it lives at the root of the project, not inside an assets folder, and it is what references the main script.
• The public folder is copied as is: whatever sits there is neither transformed nor renamed, handy for a file that must keep its exact address.
• Environment variables are prefixed: only those starting with VITE_ reach the browser, through import.meta.env. It is a guardrail against leaking a secret key into the code sent to the client.

Frequently asked questions

On a new project it is generally the default choice, for its speed and its lighter configuration. Webpack keeps its place on existing applications built on a plugin ecosystem assembled over the years, and a migration is something you plan rather than improvise.

The most common cause is a path whose capitalization does not match the file name exactly. A development machine's file system often ignores that, the server's does not. Also check files imported dynamically through a computed path, which the build cannot guess.

Not at all: it works just as well with no interface library, and official plugins cover the main frameworks. It simply happens to have become the usual starting point for React projects. Our React course starts from that base, which saves an evening of configuration before the first line of code.