Back to BlogTooling

Vite 8 Lands: Rolldown Unifies Dev and Prod, and Your Build Drift Goes With It

Vite 8 ships Rolldown as the single bundler for both dev and production, retiring the esbuild-dev/Rollup-prod split that caused subtle environment drift for years. Here's what changed, what to audit, and the real performance story.

ViteRolldownbuild toolsbundlerJavaScriptperformance
Vite 8 Lands: Rolldown Unifies Dev and Prod, and Your Build Drift Goes With It

Vite had a dirty secret it kept for five years. Your dev server ran esbuild — a Go-based tool built for raw speed — while production builds ran on Rollup, a JavaScript bundler with a rich plugin ecosystem but nowhere near esbuild's performance. The two coexisted inside Vite as a kind of permanent tension: fast local iteration, careful production bundling, and a guaranteed surface for mismatch bugs in between.

Vite 8 ends that arrangement. The new release ships Rolldown as its single bundler for both dev and build — a Rust-based tool that hits esbuild-level performance while remaining fully compatible with the Rollup plugin API. Same pipeline, both modes, no more surprises.

The Old Split and Why It Hurt

The dual-bundler model was a pragmatic choice in 2021. esbuild was the only tool fast enough to power instant HMR. Rollup had the plugin ecosystem developers needed for production. Running both in parallel was the obvious solution.

The cost showed up in subtle ways:

  • Rollup plugins that modified chunk output (renderChunk, generateBundle) only ran during vite build, never in the dev server

  • Tree-shaking decisions differed between the two tools — dead code that survived in dev could vanish in production, or vice versa

  • CSS extraction order could diverge between environments

  • Dynamic import handling had edge cases that esbuild and Rollup resolved differently

You'd ship something that tested clean locally, only to have it fail in CI because the production bundler interpreted an import graph differently than the dev server did. The bug wasn't in your code — it was in the toolchain contract.

Rolldown Is Not Just esbuild in Rust

Rolldown is a Rust implementation of Rollup built by the VoidZero team — the same group behind Vite, Vitest, and Oxc. The goal was never "rewrite esbuild." It was "give Rollup the performance profile of a native tool while keeping the Rollup plugin API that the ecosystem already depends on."

The result: Rolldown runs at native speed, supports the full Rollup plugin lifecycle, and pairs with Oxc — a Rust-based JavaScript parser — as the frontend layer that feeds it semantic analysis.

In practice, Oxc parses your source and hands Rolldown information about module structure, side effects, and symbol references that Rollup could only approximate via heuristics. That semantic grounding makes Rolldown's tree-shaking more accurate and its HMR invalidation more precise. It also means Vite's entire toolchain now speaks the same language: Vite at the top, Rolldown as the bundler, Oxc as the parser and transformer — all written in Rust, all maintained by the same team.

The New Pipeline

Both dev and build now share one transform pipeline. Plugins run in the same environment regardless of mode. The behavior you see locally is exactly what ships.

What You Actually Get

**Performance**: The Vite team's benchmarks on large projects show cold builds running 10-30x faster than Vite 7. A 500-module app that took 45 seconds under Rollup now completes in under 5. HMR invalidation matches esbuild's sub-100ms profile.

**Persistent module-level caching**: Rolldown can cache resolved and transformed modules across builds — something the Rollup architecture made difficult. Incremental rebuilds on unchanged modules skip the full transform cycle entirely.

**Module Federation**: The dual-bundler setup made Module Federation messy because dev-mode and build-mode outputs had to be manually reconciled. With Rolldown owning both, native Module Federation support lands in Vite 8 without reaching for external plugins.

**Better tree-shaking**: Oxc's semantic analysis gives Rolldown accurate side-effect information at the module level. More dead code gets eliminated, and less live code gets accidentally dropped. The difference is most noticeable in large component libraries where re-exports are common.

Migrating from Vite 7

For most apps, the upgrade is one line:

npm install vite@8 --save-dev

Three things worth auditing before you merge:

**optimizeDeps.esbuildOptions is deprecated.** Rolldown doesn't accept raw esbuild options. The equivalent is optimizeDeps.rolldownOptions, and most values map directly:

// Vite 7
optimizeDeps: { esbuildOptions: { target: 'es2020' } }

// Vite 8
optimizeDeps: { rolldownOptions: { output: { format: 'es' } } }

The migration guide has the full option mapping table.

**CSS code splitting is more aggressive.** Rolldown extracts CSS earlier in the pipeline. If your load order depends on CSS being bundled inline with specific JS chunks, check your output structure after upgrading.

**Plugin authors: your dev-mode hooks now run.** Hooks like renderChunk and generateBundle were Rollup-only in Vite 7 — they never fired during dev. They now fire in both modes. If you maintain a plugin, test the dev path explicitly before releasing a Vite 8-compatible version.

esbuild doesn't disappear entirely. Vite 8 still pulls it in as an optional peer dependency for CSS minification in dev mode by default. Most projects can ignore this; if you want a fully esbuild-free build, you can opt out via the css.minify config.

Should You Upgrade?

For personal projects and new work: immediately. The build time difference is obvious after the first vite build run, and the unified pipeline removes a whole class of "works locally" bugs from your mental model.

For production apps with complex plugin chains: run a branch build first, verify the output matches what Vite 7 produced, and smoke test for a day. Use vite build --debug rolldown to inspect the transform steps if anything looks off. The behavioral surface between Vite 7 and 8 is small — but it exists, especially around plugins that hook into the production-only lifecycle.

The dual-bundler model was always a compromise waiting to be retired. Rolldown makes it unnecessary, and the payoff isn't just speed — it's a build pipeline you can actually reason about from source file to deployed bundle, with no hidden split in the middle.