Vite 8 and Rolldown: Is the Migration Worth It?

If your build tool upgrades used to mean a config rewrite and a weekend of regression testing, Vite 8 breaks that pattern. It swaps out the bundler underneath your project and, for most setups, you won’t have to touch a config file to benefit. The headline number: a 19,000-module production build that took 40 seconds under the old Rollup-based pipeline finishes in under 2 seconds under the new one.

What actually changed

Since Vite’s early versions, the tool has run two different bundlers for two different jobs: esbuild handled fast on-the-fly transforms during development, and Rollup handled the final production bundle. That split worked, but it meant two engines with two sets of behavior, and occasional “works in dev, breaks in build” bugs traceable to exactly that seam.

Vite 8, stable since March 2026, replaces both with Rolldown, a Rust-based bundler built as a drop-in replacement for Rollup’s API but designed from the start to also handle the dev-server transform role esbuild used to own. One engine, one behavior model, both jobs.

# Upgrading is usually just the version bump
npm install vite@latest

# Rolldown is the default bundler in Vite 8, no flag needed
npm run build

The project also pairs Rolldown with Oxc, a Rust-based toolchain for parsing, transforming, and linting JavaScript and TypeScript, which is what replaces esbuild’s transform role in the dev server.

The numbers, not the marketing copy

Vite’s release announcement leans on a “10-30x faster” headline, which sounds like the kind of round number vendors reach for regardless of what’s true. The underlying benchmark is more specific and worth citing directly: a production build of a 19,000-module test project (10,000 React JSX components plus 9,000 icon files, minification and source maps on) took 40.10 seconds with Rollup and 1.61 seconds with Rolldown.

That’s about 25x on this specific benchmark, and it lines up with independent coverage from InfoQ, which reported the same order-of-magnitude gains when the stable release shipped. The “10-30x” range in the announcement isn’t one number stretched to sound good, it’s the spread you get once you factor in project size:

Project size	Typical speedup
Small (a few hundred modules)	2-5x
Mid-sized (low thousands of modules)	5-10x
Large (tens of thousands of modules)	10-30x

The pattern makes sense once you think about why: Rolldown is a compiled, multi-threaded bundler competing against Rollup’s single-threaded JavaScript implementation. The performance gap between “compiled and parallel” and “interpreted and single-threaded” widens as there’s more work to parallelize. A tiny project doesn’t have enough modules to spread across cores; a monorepo with tens of thousands does.

What migration actually looks like

The part that surprises people used to previous bundler-swap migrations (Webpack to Vite, CRA to anything) is how little most projects need to change. Vite 8 ships a compatibility layer that automatically converts common esbuild options and rollupOptions entries in your vite.config.js into their Rolldown and Oxc equivalents:

// vite.config.js (this config from Vite 7 keeps working unchanged)
export default {
  build: {
    rollupOptions: {
      output: {
        manualChunks: {
          vendor: ['react', 'react-dom'],
        },
      },
    },
  },
  esbuild: {
    jsxFactory: 'h',
  },
}

Both blocks get translated under the hood. The place migrations actually break is plugins that reach past the documented Rollup or esbuild plugin API and poke at internals directly, transformer plugins that pattern-match on esbuild’s internal AST shape, for example. Those need explicit Rolldown support from the plugin author, and not every plugin has shipped it yet. Before migrating a production app, check your plugin list against Rolldown’s compatibility notes rather than assuming everything just works.

A safe rollout path:

1. Bump Vite in a branch, run your existing test suite and build pipeline unchanged.
2. Diff the build output size and chunk structure against your current production build; a working migration should produce near-identical output, just faster.
3. Check any custom plugins for Rolldown compatibility notices, and pin or patch anything that hasn’t caught up.
4. Roll out to CI first, where build time savings compound across every PR, before pushing to local developer machines.

Where this fits if you’re choosing a stack today

For teams evaluating Next.js versus TanStack Start or comparing modern JavaScript toolchains generally, bundler speed is one input among several, but it’s not a small one. A 25x build time reduction changes CI cost and iteration speed in ways that add up over a year of daily builds, especially for larger codebases where the old Rollup-based pipeline was already the slowest step in the pipeline.

If your project already runs on Vite, this upgrade is close to a free win: little to no config rewrite, and the gains grow with the size of the problem you already have. If you’re on Webpack or another Rollup-adjacent setup and weighing whether to move to Vite at all, Rolldown just made that decision easier, since the destination is now faster than the source in most cases, not just more modern.

The actual work isn’t the bundler swap, it’s verifying your plugins keep up. Budget an afternoon to test the migration in a branch before scheduling it for the whole team, and treat any custom Rollup plugin as the thing to check first, not the config file.