Core Concepts
The ideas you must internalize: dependency pre-bundling, on-demand transforms, HMR boundaries, the plugin API, env variables, and asset handling.
Third-party documentation. This is independently authored analysis of the public Vite codebase — not the official docs, and not reviewed or endorsed by the Vite team.
Core Concepts
Five ideas explain most of Vite: dependency pre-bundling, on-demand transforms, HMR boundaries, the plugin pipeline, and environment variables. Each one changes how you reason about the dev experience and the shipped output.
Dependency pre-bundling
When the dev server starts, Vite runs esbuild over your dependencies and converts them to ESM, caching the result in node_modules/.vite. This collapses hundreds of small files (common in npm packages) into one fast-loading module and normalizes CommonJS/UMD to ESM so import works uniformly. Changing a dependency version or the lockfile busts the cache automatically.
On-demand transforms
Vite only transforms files the browser actually imports, on request. There is no upfront build step — start-up time stays flat even as the project grows, and the cost of editing a file is proportional to that file, not to the whole graph. This is the core reason Vite feels instant.
HMR and Fast Refresh
When a file changes, the dev server pushes a hot update over a WebSocket. Framework plugins (@vitejs/plugin-react, @vitejs/plugin-vue) decide the update boundary: a component edit triggers Fast Refresh that preserves local state; an edit to a non-component module triggers a full reload of its importers. You control this with import.meta.hot.accept for your own modules.
The plugin pipeline
Plugins are objects with hooks that run through the module pipeline in both dev and build: resolveId (map an import to a file), load (read a module), transform (rewrite its content), plus output hooks used by Rollup at build time and dev-only hooks like configureServer and handleHotUpdate. If a plugin is Rollup-compatible and doesn't use dev-only hooks, Vite can use it directly.
Environment variables
Variables from .env files are exposed through import.meta.env, but only names starting with VITE_ (default envPrefix) reach client code — everything else is stripped to avoid leaking secrets. Built-ins include MODE, DEV, PROD, SSR, and BASE_URL. Values are statically inlined at build time.