From Source Graph to Deployable Site: Rolldown, Oxc, and Network-Aware Output

Vite's production build answers a different question from its development server: not “what is the smallest amount of work needed for the next browser request?” but “what arrangement of code and assets should a real browser receive over a real network?” This chapter follows Vite from source entries through Oxc transformation, Rolldown bundling, chunk and asset generation, preload relationships, and backend manifests. The goal is to make production output understandable as a delivery system rather than as a mysterious folder produced by vite build.

The development graph was organized around feedback. The browser asked for modules, Vite transformed them, and HMR used their relationships to localize change. That arrangement is useful while source is moving, but it is not automatically efficient to ship. A deployed browser should not have to discover a long sequence of nested imports before it can execute the page. Production bundling is therefore not a historical leftover from before native ESM; it is a response to a different bottleneck.

Production starts by changing the question

In development, delaying work is valuable. If a route is never visited, its source does not need to be transformed before the developer can inspect the current route. In production, the cost of discovery moves to every user and every network connection. A browser that receives one module and only then learns that it needs another can create a chain of request and parse delays. The build can inspect the application graph in advance and choose a delivery shape that makes those relationships cheaper to traverse.

Vite begins the production pass with an entry point. For a standard application, that is usually an HTML entry. Projects can define other inputs for libraries, SSR, or specialized build arrangements. The entry choice is not a small configuration detail: it determines which graph is being built and what kind of output Vite can generate. A library entry, a browser application entry, and a server-rendering entry have different consumers and therefore different output expectations.

The build then applies the transformation and bundling pipeline. In the Vite 8 toolchain represented by the repository snapshot, Oxc is the native transformation and minification side of the pipeline, while Rolldown is the bundler that assembles the module graph into output chunks. Vite supplies the surrounding rules: browser or server platform, target, asset handling, CSS behavior, source maps, plugin execution, file names, and manifests. The underlying tools are important, but Vite remains the layer that turns them into an application build contract.

Oxc and Rolldown do different jobs. Oxc transforms source into a form appropriate for the selected target and can perform the configured minification. Rolldown follows imports, determines chunk boundaries, and generates the bundle outputs. A transformation can change syntax without deciding which modules share a file. A bundler can know the graph without being the component that lowers every source-language feature. Keeping those roles distinct helps explain why a Vite configuration can set a browser target, a minification policy, and a code-splitting strategy separately.

The plugin pipeline crosses this boundary as well. A plugin may resolve an identifier, load virtual content, transform a framework file, or participate in output generation. During production, build-oriented hooks and output metadata become available. During development, the server may only call the hooks needed for a requested module.