Back to BlogTooling

Vite 8 Ditched the Split-Brain Rollup Pipeline. Here's What You Inherit.

Vite 8 replaced the split esbuild-dev / Rollup-prod pipeline with a unified Rolldown engine. Here's what actually breaks, what to rename, and how to migrate without production surprises.

viterolldownbundlerbuild-toolsmigrationjavascript
Vite 8 Ditched the Split-Brain Rollup Pipeline. Here's What You Inherit.

Vite 8 has been in the wild since March, and with 8.0.15 dropping on June 1 carrying Rolldown 1.0.3 under the hood, the "I'll upgrade eventually" window is closing. The benchmarks are real — teams are reporting 4–20x faster production builds, and one real-world case has Linear dropping from 46-second builds to 6 — but the more interesting story is what Rolldown actually fixes architecturally, and why Vite 7's design was always going to produce the class of bugs it produced.

Why Vite 7's Two-Engine Model Was a Liability

Vite 7 ran two entirely separate tools in parallel. esbuild handled development transforms. Rollup ran production bundling. They don't share a module graph. They don't share plugin semantics. They don't share the same resolution behavior for edge cases at import boundaries.

This is the root cause of every "works in dev, breaks in prod" Vite bug you've ever filed. You weren't imagining it — your dev environment was literally running different software than your prod build. Different engines, different graphs, and a plugin API that had to bridge both in ways that were never fully consistent.

Rolldown is one Rust-based engine — built by the VoidZero team, now part of Cloudflare — that covers both paths. Same module graph, same plugin interface, same resolution behavior. The split goes away entirely.

The Breaking Changes You'll Actually Hit

Most of the migration is mechanical, but four things will bite you if you don't go looking for them first.

**build.rollupOptionsbuild.rolldownOptions.** This is the most common breaking change. If you have any production bundling configuration nested in rollupOptions, rename the key. The shape is similar but not guaranteed to be 1:1 — verify anything custom against the Rolldown docs rather than assuming it just works.

// before (Vite 7)
export default {
  build: {
    rollupOptions: {
      output: { manualChunks: { vendor: ['react', 'react-dom'] } }
    }
  }
}

// after (Vite 8)
export default {
  build: {
    rolldownOptions: {
      output: { manualChunks: { vendor: ['react', 'react-dom'] } }
    }
  }
}

**CSS minification defaults to Oxc.** build.cssMinify previously used esbuild. Now it uses Oxc's CSS minifier. For most apps the output is identical or slightly smaller, but if your styles look off in a prod build after upgrading, this is the first thing to check. Do a visual diff on a staging deploy before touching prod. Don't skip this if you're using any unusual CSS features or vendor-prefixed properties.

**Circular import warnings are now loud.** Rolldown flags circular imports where Rollup 4 stayed silent. This feels like a breaking change, but it's actually Rolldown surfacing bugs that were always there. Don't add suppression comments or ignore the output — look at the actual circular chain and break it. It's almost always a real latent architectural issue in your dependency graph.

**import.meta.hot.accept no longer takes a URL.** If you have custom HMR code or a plugin that calls import.meta.hot.accept with a URL string, switch to passing a module id instead. This is a niche change, but it produces silent HMR failures if you miss it — the kind where hot reload stops working but nothing throws an error.

Migration Checklist

The upgrade path is short. Work through these in order after bumping the package:

Run npm install vite@8, do a local prod build, and check the console output for warnings before deploying anywhere. Most teams get through the full checklist in under an hour.

One Thing to Watch: Plugins

Vite 8 keeps backward compatibility with the Rollup plugin API, so most vite-plugin-* packages work without changes. The risk is if you're using Rollup plugins directly — not through Vite's plugin interface — or if you've written custom plugins that reach into Rollup internals.

Open your vite.config.ts and look at the plugins array. Anything that isn't a vite-plugin-* import is worth testing explicitly. The community plugin ecosystem has been mostly keeping pace since Vite 8 launched in March, but some lower-traffic plugins haven't published a compatibility update yet. Check the GitHub issues for any plugin you depend on before upgrading in a production CI pipeline.

If you're on a monorepo setup, test each package's build individually. Rolldown's stricter circular import detection sometimes catches cross-workspace cycles that Rollup tolerated silently — those are the ones most likely to cause a surprise on upgrade day.

The Speed Numbers in Context

The 10–30x headline comes from cold builds on large monorepos. For a typical mid-size app, expect 2–5x faster production builds and faster dev startup. HMR improvements are real but less dramatic — esbuild was already quick enough on dev transforms that the relative gap is smaller there.

The consistency benefit matters more than raw speed for most teams. Fewer dev/prod divergence incidents, one plugin interface, one thing to debug when a build goes sideways. That's the durable win from the Rolldown switch, not just the benchmark number.

Bottom Line

Vite 8 with Rolldown 1.0.3 is production-ready and the migration is genuinely short. Rename rollupOptions, check your CSS output on staging, treat circular import warnings as signal rather than noise, and verify any non-standard plugins. For most apps that's a one-afternoon upgrade with a meaningfully more coherent build pipeline on the other side — one that eliminates a whole category of hard-to-reproduce bugs by simply not running two different engines anymore.