Vite 8 + Rolldown Migration Guide: Cut Build Times by 87% in 2026

Vite 8 stable landed on March 12, 2026, and the Vite 8 Rolldown migration is the single most impactful build tool upgrade most frontend teams will make this year. For the past five years, Vite used a split architecture: esbuild for lightning-fast dev server transforms, Rollup for production bundles. The problem? Two bundlers meant two configs, two sets of quirks, and output that could subtly differ between dev and prod. Vite 8 collapses that into one: Rolldown handles everything. This guide walks through what actually changed under the hood, what breaks in real projects, and the exact two-step migration path that avoids surprises. If you are building with React, Svelte, Vue, or plain JavaScript on Vite 7, this is the upgrade to plan for now.

What actually changed inside Vite 8?

The core architecture shifted from three separate tools to one unified Rust binary.

In Vite 7, the stack was: esbuild for dev transforms and dependency pre-bundling, Rollup for production builds, and either esbuild or terser for minification. That meant you maintained esbuild options for dev behaviour and rollupOptions for prod — two mental models for one build pipeline. Vite 8 replaces all of this with Rolldown as the single bundler for both environments, Oxc (also Rust) as the JavaScript transformer replacing esbuild’s transform step, and Lightning CSS as the default CSS minifier replacing esbuild’s CSS handling. The result is that your dev server and your production output now use identical module resolution and transform paths — the “it works in dev but breaks in prod” class of bugs becomes much rarer. If you are curious about other ECMAScript tooling changes in 2026, our ECMAScript 2025 guide covers iterator helpers and Promise.try that pair well with the new toolchain.

How much faster is Vite 8 in real production projects?

The headline numbers are 10-30x, but real-world gains depend heavily on project size and plugin complexity.

The most cited real-world benchmark comes from Linear: their production build dropped from 46 seconds to 6 seconds after migrating — an 87% reduction. Ramp reported a 57% reduction, Beehiiv a 64% improvement. GitLab’s data is the most striking: switching to Rolldown-Vite brought their build from 2.5 minutes to 22 seconds versus Vite 7, and 43x faster than their original Webpack setup. On the modest end, a typical single-page React app sees around 5x faster cold builds. The dev server HMR speed is largely unchanged from Vite 7 because that was already fast with esbuild. What changes most is production build time, where Rolldown’s single-pass Rust bundler outpaces Rollup’s JavaScript-based tree-shaking significantly. There is one catch worth knowing: Vite 8’s main Node.js process currently uses around 7x more physical RAM than Vite 7 in dev mode because Rolldown keeps more module graph data in memory. For CI pipelines with memory limits, monitor this before upgrading.

# Quick benchmark: compare your current build time first
time npx vite build

# Then after migration:
time npx vite build
# Most teams see this number drop 50-90%

How do you migrate from Vite 7 to Vite 8 safely?

The Vite team recommends a two-step process so you can isolate bundler issues from API changes.

Step 1 — Try Rolldown on Vite 7 first. The Vite team published rolldown-vite, a drop-in replacement for the vite package that runs Rolldown under the hood while staying on the Vite 7 API surface. Install it and run your existing build to check for Rolldown-specific breakage before any other changes:

# Step 1: swap vite for rolldown-vite, keep everything else the same
npm remove vite
npm install rolldown-vite

# Run your build — fix any errors you see here before proceeding
npm run build

Step 2 — Upgrade to Vite 8 and update your config. Once your build passes on rolldown-vite, the Vite 8 upgrade itself is mostly a config rename exercise:

// vite.config.js — before (Vite 7)
export default {
  build: {
    rollupOptions: {
      output: {
        manualChunks: { vendor: ['react', 'react-dom'] }
      }
    },
    minify: 'esbuild'
  }
}

// vite.config.js — after (Vite 8)
export default {
  build: {
    rolldownOptions: {          // renamed from rollupOptions
      output: {
        // manualChunks is deprecated — use codeSplitting instead
        codeSplitting: {
          groups: [{ name: 'vendor', test: /node_modules/ }]
        }
      }
    },
    cssMinify: 'lightningcss'  // default; can set 'esbuild' to revert
  }
}

What actually breaks when you upgrade to Vite 8?

Three issues account for about 80% of upgrade failures seen in the wild.

1. CommonJS interop. This is the most common breakage. Rolldown handles default imports from CJS modules differently from Rollup. If you import a package that ships CommonJS and the build fails with errors like “does not provide an export named ‘default'”, add this to your config temporarily while you track down the culprit package:

// vite.config.js — temporary CJS interop fix
export default {
  legacy: {
    inconsistentCjsInterop: true  // restores Vite 7 behaviour; remove once fixed
  }
}

2. manualChunks is deprecated. If you used build.rollupOptions.output.manualChunks to split vendor bundles, Rolldown replaces this with codeSplitting.groups. The old option still works with a deprecation warning in Vite 8.0 but will be removed in a future minor. Migrate it now. 3. Yarn PNP users are blocked. Rolldown’s module resolver is native Rust code and cannot be monkey-patched the way Yarn PnP patches Node’s require. If your project uses Yarn with nodeLinker: pnp in .yarnrc.yml, you either need to switch to nodeLinker: node-modules or wait for the Rolldown team’s PnP support, which is on their roadmap. You can also check how we handle JavaScript module patterns in our higher-order functions guide for patterns that work well with the new bundler.

How does Vite 8 compare to Turbopack and Rspack in 2026?

The three serious contenders now all run on Rust-based cores — the differentiator is ecosystem fit, not raw speed.

Tool	Cold Prod Build	Framework Lock-in	Plugin Ecosystem	Best For
Vite 8 + Rolldown	10-30x faster than Vite 7	None — framework-agnostic	Rollup-compatible (largest)	React, Vue, Svelte, vanilla JS
Turbopack (Next.js 16)	Fast; default in Next.js 16	Next.js only	Next.js plugins only	Next.js projects exclusively
Rspack 1.x	Under 4s on large apps	None — Webpack API compat	Most Webpack plugins work	Webpack migrations, large monorepos

The practical rule: if you are on Next.js, Turbopack is the path of least resistance. If you are migrating from Webpack and have a large plugin dependency, Rspack lets you keep your existing config. For everything else — React without Next.js, Vue, Svelte, library builds — Vite 8 is the balanced choice with the largest plugin ecosystem.

Should you upgrade to Vite 8 right now?

Yes, if you are on Vite 7 with a standard ESM project. Wait a version if you rely on Yarn PNP or have significant CJS dependencies.

The counterintuitive production finding from teams who have already migrated: the performance improvement on CI is often larger than local benchmarks suggest, because CI machines have slower disks and less CPU cache than developer laptops — exactly the conditions where Rust’s single-pass bundling pulls ahead the most. The 7x dev-mode RAM increase is real but only matters if your CI runner has tight memory limits (under 2 GB). On a standard 4-8 GB runner, you will not hit it. The Vite team has flagged this as a known issue and is working on reducing Rolldown’s in-memory module graph size. Most production teams should upgrade now and batch the CJS interop fixes into the same PR as the config rename — it is a half-day of work for most codebases.

• Vite 8 replaces esbuild + Rollup with Rolldown, a single Rust bundler — dev and prod now use identical transform paths, eliminating the dev/prod parity bug class.
• Real production data shows 50-87% build time reductions; CI environments benefit even more than local machines due to slower disk I/O.
• The two-step migration (rolldown-vite on Vite 7 first, then Vite 8) isolates bundler issues from API changes and is the safest upgrade path.
• Rename build.rollupOptions to build.rolldownOptions and replace manualChunks with codeSplitting.groups — these two changes cover 90% of config work.
• CJS interop changes are the most common runtime breakage — use legacy.inconsistentCjsInterop: true as a temporary fix while auditing your CJS dependencies.
• Yarn PNP users must switch to nodeLinker: node-modules until Rolldown adds native PnP support.

Frequently Asked Questions

What is Rolldown in Vite 8?

Rolldown is a Rust-based JavaScript bundler built by the Vite team to replace both esbuild and Rollup inside Vite. It ships in Vite 8 as the single bundler for both dev server transforms and production builds, delivering 10-30x faster build times while maintaining full Rollup plugin API compatibility.

How much faster is Vite 8 than Vite 7?

In real production projects, Vite 8 with Rolldown is 5-43x faster than Vite 7. Linear’s build time fell from 46 seconds to 6 seconds (87% reduction). GitLab saw a 7x improvement over Vite 7 and 43x over their old Webpack setup. Smaller projects see more modest gains of 2-5x.

Is migrating from Vite 7 to Vite 8 safe?

For most projects, yes — especially if you avoid CommonJS modules and don’t use Yarn PNP. The recommended safe path is a two-step migration: first swap vite for rolldown-vite on Vite 7 to catch bundler-specific issues, then upgrade to Vite 8. This isolates any Rolldown problems from Vite 8 API changes.

What breaks when upgrading to Vite 8?

Three things cause most Vite 8 upgrade failures: (1) build.rollupOptions renamed to build.rolldownOptions, (2) CJS interop changes that break default imports from CommonJS modules, and (3) Yarn PNP incompatibility with Rolldown’s native Rust resolver. Windows users should also ensure they are on the stable 8.0.0 release, not a beta.

Do my existing Vite plugins work with Vite 8?

Most do. Rolldown implements the same plugin API as Rollup and Vite 7, so the majority of plugins work without changes. The exceptions are plugins that use esbuild-specific transform options, Rollup hooks that Rolldown does not yet implement, or plugins relying on import.meta.hot.accept accepting a URL instead of an id.

Does Vite 8 use more memory than Vite 7?

Yes, in dev mode. Rolldown’s in-memory module graph currently uses around 7x more physical RAM than Vite 7’s dev server. This is a known issue the Vite team is actively reducing. In production builds (CI), the memory profile is comparable. Monitor your CI runner’s memory if it has less than 2 GB available.

The shift to a single Rust bundler is not just a performance win — it is an architectural simplification that makes Vite easier to reason about. Once you are on Vite 8, dev and prod behaviour align more closely than ever before, and your build config shrinks. The one thing most guides do not tell you: run the two-step migration on a feature branch, not main. Install rolldown-vite on Vite 7, run your full test suite and visual regression checks if you have them, fix what breaks, then upgrade to Vite 8 in a second PR. Two small PRs are safer than one big bang upgrade. Drop a comment below if you hit a CJS interop edge case not covered here — we will update the guide. Subscribe to NexGismo for more production-grade JavaScript guides like this one.