Vite 8 Swapped Its Bundler. Here's What Breaks.

Vite spent six years as the tool that made bundler choice feel irrelevant. Vite 8 makes it relevant again, because it swapped both of them at once.

Rollup is out, Rolldown is in. esbuild is out, Oxc is in — for transforms and for JavaScript minification. Lightning CSS becomes the default CSS minifier. That is not a version bump. That is a transplant, and it explains why the migration guide is long.

Most of the coverage has focused on the speed numbers. The numbers are real. They are also not the thing that will cost you a Thursday.

The numbers, and what they do not say

From the official Vite 8 announcement: Rolldown benchmarks 10–30x faster than Rollup, and the named production results are Linear at 46 seconds to 6 seconds, Beehiiv at a 64% reduction, Ramp at 57%, and Mercedes-Benz.io at up to 38%.

Read the spread rather than the headline. A 38% improvement and a 7.6x improvement in the same list means the payoff depends almost entirely on what your build was doing before. Rolldown removes bundling cost. If your build is dominated by type-checking, image processing, a slow CI runner or a dozen framework plugins doing their own work, you get the tail end of that range, not the front.

The dev server is the other misread. Vite's dev experience was already fast because it served native ESM and skipped bundling; the dependency optimizer switching from esbuild to Rolldown makes cold starts better on large dependency graphs, but if you expected your HMR to transform, it will not. Build time is the prize.

One cost that does not appear in any benchmark: install size grew by roughly 15 MB against Vite 7. On a laptop, irrelevant. Across a CI matrix with a cold cache, measure it before you celebrate.

The breakages that actually bite

The migration guide lists a lot. In practice the failures cluster into four kinds, and only one of them is loud.

1. CommonJS interop is now consistent — which means different

Vite 8 makes default-import handling behave the same in dev and build. That is the correct decision and it is also the one most likely to break a working app, because plenty of codebases accidentally depend on the old asymmetry. The symptom is a module that is undefined at runtime in exactly one of the two modes, usually an older CJS-only dependency imported as a default.

Related: external module require() calls are now preserved rather than rewritten into imports. If you ship a library or an SSR bundle, check the output before you check the tests.

2. Module resolution heuristics are gone

The old browser and module field sniffing has been removed. Packages with modern exports maps are unaffected. Packages last published in 2019 are exactly the ones that relied on the sniffing, and they fail by resolving to the wrong entry rather than by erroring — which is how you end up debugging a Node build that pulled a browser bundle.

3. The browser target moved without asking

Defaults went from Chrome 107 to 111, Edge 107 to 111, Firefox 104 to 114, and Safari 16.0 to 16.4. If you have a support matrix in a contract, or an enterprise customer base pinned to an older browser, this is a silent compliance change in a minor line of a migration doc. Set build.target explicitly and stop depending on the default.

4. import.meta.url in UMD and IIFE builds

It is no longer polyfilled and evaluates to undefined. Anything resolving worker or asset paths that way in a legacy output format breaks at runtime, not at build time. Grep for it before you ship.

If you maintain a plugin, this is your migration

App authors get a bumpy afternoon. Plugin authors get a real port.

Change	What you do about it
transformWithEsbuild() deprecated	Move to transformWithOxc()
Load/transform hooks converting to JS	Return moduleType: 'js' explicitly
Parallel hooks now run sequentially	Re-check any hook you assumed was concurrent
Bundle object not shared across hooks	Stop mutating bundle state between hooks
structuredClone(bundle) unsupported	Use structuredClone({ ...bundle })
Hooks removed	shouldTransformCachedModule, resolveImportMeta, renderDynamicImport, resolveFileUrl need rewrites
Object-form manualChunks removed	Convert to the function form
build() throws BundleError	Unwrap it in any custom build script

The "parallel hooks now run sequentially" line deserves a second look. It is a one-line note with real performance consequences for any plugin that fanned out I/O in a hook and assumed concurrency. If your plugin got slower after the upgrade while the overall build got faster, that is where to look first.

Minification changed hands, quietly

JavaScript minification moved from esbuild to the Oxc minifier, which the migration guide notes operates under different assumptions. CSS minification defaults to Lightning CSS, with esbuild still available.

"Different assumptions" is doing quiet work in that sentence. Minifiers make judgement calls about what is safe to drop or rewrite, and a change of minifier is a change of judgement. Diff your output bundle sizes and smoke-test the production build rather than trusting that a green test suite on unminified dev code proves anything. If you want a quick sanity check on a single file outside your pipeline, the browser-based JS minifier and CSS minifier in our free tools are enough to eyeball a before-and-after.

The migration path the Vite team actually recommends

For anything complex, do not jump straight to 8. The announcement recommends staying on Vite 7 and switching the vite package for rolldown-vite first. That isolates Rolldown-specific breakage from every other Vite 8 change, so when something fails you know which transplant rejected.

Node requirements are unchanged from Vite 7: 20.19+ or 22.12+. One fewer thing to coordinate.

A practical order: pin build.target explicitly, move to rolldown-vite on 7 and let it sit in CI for a week, audit your plugin list for anything unmaintained, then upgrade. The plugin audit is the step people skip and regret — a plugin that has not shipped since 2024 is not getting a Rolldown port, and you are better off finding a replacement in the open-source listings or the developer tools category before the upgrade than during it.

Should you upgrade now?

Upgrade now if your build time is a daily irritation, your dependency tree is modern, and your plugin list is short and maintained. The payoff is immediate and the risk is bounded.

Wait if you ship a library with UMD or IIFE outputs, depend on pre-exports-map packages, maintain custom plugins with removed hooks, or have a contractual browser support floor below the new defaults. None of those are permanent blockers; they are just work you want to schedule rather than discover.

And the Environment API, which a lot of framework authors are waiting on, is still explicitly a work in progress. If that is what you are upgrading for, it is not here yet. That is the kind of detail worth checking before a migration rather than after, which is the whole argument behind comparing developer tools on mechanics instead of marketing.

FAQ

Does Vite 8 make the dev server faster?

Marginally, mostly through the dependency optimizer now running on Rolldown instead of esbuild, which helps cold starts on large dependency graphs. The headline gains are in production builds. If you upgrade expecting faster HMR, you will be disappointed.

Do my Rollup plugins still work?

Many do, since Rolldown targets Rollup API compatibility, but four hooks were removed outright and several behaviours changed — parallel hooks now run sequentially, the bundle object is no longer shared across hooks, and JS-producing transforms must declare moduleType: 'js'. Audit each plugin rather than assuming.

What Node version does Vite 8 need?

Node.js 20.19+ or 22.12+, the same as Vite 7. Node is not the thing that will block this upgrade.

Can I keep using esbuild?

For CSS minification, yes — Lightning CSS is the new default but esbuild remains an option. For JavaScript transforms and minification, Oxc is the path forward, and transformWithEsbuild() is deprecated in favour of transformWithOxc().

Why did my bundle size change after upgrading?

Because the minifier changed. Oxc's minifier makes different assumptions than esbuild's, and Lightning CSS handles CSS differently. Small size deltas in either direction are expected; large ones are worth investigating as a correctness question, not just a size one.

Is the Environment API stable in Vite 8?

No. The Vite team describes it as still being worked on, with regular ecosystem meetings to coordinate. Framework authors building on it should expect further change.

---

Fast builds are worth an afternoon of migration. They are not worth an unaudited plugin list — do that part first.