Introduction to Vite: Architecture, Dependency Pre‑Build, and Plugin System

Vite is presented as the latest entry in a decade‑long evolution of frontend build tools, contrasting it with earlier bundlers like webpack, Rollup, and esbuild, and highlighting its reliance on native ES‑module support in browsers and Go‑based tooling for speed.

The background section explains that traditional bundlers suffer from slow startup and hot‑module replacement (HMR) latency as projects grow, while Vite solves these issues by serving source files directly in development and delegating production builds to Rollup.

Core functionalities include a dev server that avoids bundling, dependency pre‑bundling (pre‑build) using esbuild for CommonJS/UMD compatibility and performance, an efficient HMR mechanism, and a production build pipeline that leverages Rollup.

The source layout is illustrated with the following directory tree:

./src
├── client # client‑side runtime, WebSocket and HMR code
│   ├── client.ts
│   ├── env.ts
│   ├── overlay.ts
│   └── tsconfig.json
└── node # local server code
    ├── __tests__
    ├── build.ts # production Rollup build
    ├── certificate.ts
    ├── cli.ts # CLI entry
    ├── config.ts
    ├── constants.ts
    ├── http.ts
    ├── importGlob.ts
    ├── index.ts # export entry
    ├── logger.ts
    ├── optimizer # dependency pre‑build
    ├── packages.ts
    ├── plugin.ts
    ├── plugins # plugins
    ├── preview.ts # preview server after build
    ├── server # dev server core
    ├── ssr
    ├── tsconfig.json
    └── utils.ts

7 directories, 18 files

The article focuses on the server directory, especially the createServer function in src/server/index.ts , which performs configuration resolution, HTTP+Connect server creation, plugin container initialization, server object construction, and middleware setup.

When the server starts, it runs plugin buildStart hooks, triggers dependency pre‑bundling via runOptimize , and finally begins listening on a port.

Dependency pre‑bundling serves two purposes: converting CommonJS/UMD packages to ESM for development compatibility, and improving runtime performance by consolidating many small modules into larger bundles. The configuration interface is shown below:

export interface DepOptimizationOptions {
  /**
   * Entry files, default parsed from HTML; can be overridden.
   */
  entries?: string | string[]
  /**
   * Files to pre‑bundle.
   */
  include?: string[]
  /**
   * Dependencies to exclude from pre‑bundling.
   */
  exclude?: string[]
  /**
   * esbuild options for the pre‑bundle step.
   */
  esbuildOptions?: Omit<
    EsbuildBuildOptions,
    | 'bundle'
    | 'entryPoints'
    | 'external'
    | 'write'
    | 'watch'
    | 'outdir'
    | 'outfile'
    | 'outbase'
    | 'outExtension'
    | 'metafile'
  >
}

Pre‑bundle results are cached in node_modules/.vite , with a metadata file ( _metadata.json ) that records a hash, a browser hash, and a map of optimized dependencies (example shown below):

{
  // configuration hash
   hash :  afcda65e ,
  /**
   * Query string added to browser requests for cache busting.
   */
   browserHash :  c369dd06 ,
   optimized : { // optimized dependency list
     react : {
      // built file path
       file :  /Users/.../node_modules/.vite/react.js ,
      // original source path
       src :  /Users/.../node_modules/react/index.js ,
      // indicates CommonJS usage
       needsInterop : true
    },
     react-dom : {
       file :  /Users/.../node_modules/.vite/react-dom.js ,
       src :  /Users/.../node_modules/react-dom/index.js ,
       needsInterop : true
    },
     lodash : {
       file :  /Users/.../node_modules/.vite/lodash.js ,
       src :  /Users/.../node_modules/lodash/lodash.js ,
       needsInterop : true
    }
   }
}

The pre‑bundle workflow includes computing a hash from lockfiles and Vite config, comparing it with the cached hash, scanning imports (using scanImports ), parsing with es-module-lexer , and finally invoking esbuild to generate the bundled files quickly.

During runtime, the vite:import-analysis plugin rewrites import statements to point to the cached files (e.g., import __vite__cjsImport2_react from /node_modules/.vite/react.js?v=0f16c3f0 ), and the resolvePlugin resolves these paths to actual files.

Request handling is performed by two main middlewares: transformMiddleware (core transformation) and indexHtmlMiddleware (HTML handling). The article also outlines the Vite plugin system, which extends Rollup hooks and adds Vite‑specific hooks such as config , configResolved , transformIndexHtml , and handleHotUpdate . An example of a simple Vite plugin is provided:

export default function myPlugin() {
  const virtualModuleId = '@my-virtual-module'
  const resolvedVirtualModuleId = '\0' + virtualModuleId

  return {
    name: 'my-plugin', // displayed in warnings/errors
    resolveId(id) {
      if (id === virtualModuleId) {
        return resolvedVirtualModuleId
      }
    },
    load(id) {
      if (id === resolvedVirtualModuleId) {
        return `export const msg =  from virtual module `
      }
    }
  }
}

Finally, the article recommends debugging tools such as vite-plugin-inspect (accessed at localhost:3000/__inspect/ ) and the built‑in vite --force --debug command to trace plugin execution and server startup.