Kim BoenderVite 8 + Rolldown: Faster Builds and One Bundler to Rule Them All
Kim Boender
Vite has been the constant in my development setup for years. New project? Vite. Quick prototype? Vite. Production Nuxt 3 app? Vite, obviously. So when Vite 8 dropped on March 12, 2026, I cleared my afternoon. This isn't a routine version bump — it's the most significant architectural change the tool has seen since Vite 2, and after spending time with it across a few real projects, I can say the hype is mostly justified.
The headline: Vite 8 replaces its old dual-bundler setup with a single Rolldown-powered pipeline. Here's what that actually means, what changed, and how to migrate without surprises.
What Is Rolldown?
Rolldown is an open-source, Rust-based JavaScript bundler built specifically to become the engine underneath Vite. It's developed by the VoidZero team — the same people behind Vue and Vite — and is designed to be fully compatible with the Rollup plugin API while delivering performance closer to esbuild.
The old Vite architecture had a fundamental tension baked into it: esbuild handled development transforms and dependency pre-bundling (fast, Rust-based), while Rollup handled production builds (slower, JavaScript-based, but extremely powerful). This dual-bundler split caused real friction. Plugins that worked in dev sometimes behaved differently in production builds. Bundle outputs could diverge from what you'd expect based on dev behavior. Two bundlers meant two sets of edge cases to think about.
Rolldown is the solution. One bundler, one plugin pipeline, one set of expectations.
The Performance Numbers
The benchmark Vite ships: 10–30x faster production builds compared to Rollup. The often-cited real-world example is Linear, whose production build time dropped from 46 seconds to 6 seconds after migrating to Vite 8.
I migrated a mid-size Nuxt 3 application over a weekend. Prior to the upgrade, production builds were sitting at around 35 seconds. Post-migration: under 5 seconds. Admittedly this is a project with a lot of TypeScript and some moderately complex chunk splitting, so the gains compound. Smaller projects will see smaller absolute improvements, but the percentage improvement is consistent.
On the dev server side, the experience is largely the same — Vite was already fast in dev, and the startup time change is marginal. The real win is in CI pipelines.
What's New in Vite 8
A Unified Bundler Pipeline
As mentioned, Rolldown replaces both esbuild (for transforms) and Rollup (for bundling). The compatibility layer Vite provides means that most existing plugins and configurations carry over without modification. The Vite plugin registry at registry.vite.dev now tracks compatibility across Vite, Rolldown, and Rollup, which is a useful reference before upgrading projects with unusual dependencies.
Native TypeScript Path Aliases
Before Vite 8, resolving tsconfig.json path aliases in Vite required the vite-tsconfig-paths plugin. Now it's built in:
// vite.config.ts
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
export default defineConfig({
plugins: [vue()],
resolve: {
tsconfigPaths: true,
},
})Set resolve.tsconfigPaths: true and your @/ and other aliases resolve out of the box. You can remove vite-tsconfig-paths from your dependencies unless you need its more advanced features.
Module Federation
Module Federation — the pattern for sharing code across independently deployed frontend apps — now has first-class support. If you've been wrestling with @originjs/vite-plugin-federation workarounds for micro-frontend setups, Vite 8 simplifies that significantly. This is something I've been watching for since we started experimenting with micro-frontends at a client last year, and having it in core is a meaningful improvement.
Built-in DevTools and Console Forwarding
Vite 8 ships with browser DevTools integration for build analysis and debugging. The more immediately useful addition: browser console logs are now forwarded to the dev server terminal. This sounds minor, but if you've ever spent time debugging SSR rendering issues where client and server console outputs live in different places, you'll appreciate it.
emitDecoratorMetadata Support
For those using NestJS on the backend with Vite powering the toolchain, emitDecoratorMetadata is now supported via Rolldown's Babel plugin integration. Less duct-tape configuration required for decorator-heavy codebases.
Migration: What Actually Changed
For standard Vite setups, the upgrade is low-friction. Here's what to watch for:
rollupOptions is now rolldownOptions
The most common breaking change. build.rollupOptions has been renamed to build.rolldownOptions, and the same applies to worker.rollupOptions → worker.rolldownOptions.
// Vite 7
export default defineConfig({
build: {
rollupOptions: {
output: {
manualChunks: {
vendor: ['vue', 'pinia', 'vue-router'],
},
},
},
},
})
// Vite 8
export default defineConfig({
build: {
rolldownOptions: {
output: {
manualChunks: {
vendor: ['vue', 'pinia', 'vue-router'],
},
},
},
},
})Vite 8 includes a shim that auto-converts rollupOptions to rolldownOptions, so your existing config won't immediately explode. But update it — the shim ships with a deprecation warning and won't survive a future version.
CommonJS Interop Is Stricter
This is where most migration headaches come from. Rolldown preserves require() calls for externalized modules rather than converting them to import statements the way Rollup did. If you have code that relies on that implicit conversion — often lurking in older packages or internal utilities — you'll see require is not defined errors in the browser console.
The fix is usually to explicitly mark the problematic packages as external, or to update them to proper ESM. Running vite build --debug gives you a detailed view of how Rolldown is resolving modules, which makes tracking down the culprit faster than guessing.
import.meta.hot.accept Change
Passing a URL to import.meta.hot.accept() is no longer supported — you need to pass a module ID. This is a niche change that only affects custom HMR implementations, but worth auditing if your codebase has any.
extglobs Not Yet Supported
Extended glob patterns in Rollup input options aren't supported in Rolldown yet. This is listed as a known limitation on the roadmap. If your config uses extglob patterns, either simplify them or wait for a follow-up release.
Vue and Nuxt Compatibility
For Vue developers specifically: the ecosystem is ready. Nuxt, @vitejs/plugin-vue, and @vitejs/plugin-vue-jsx were all tested against Rolldown early by the framework teams. My Nuxt 3 migration required exactly one manual change — renaming rollupOptions — and everything else (Pinia, Vue Router, unplugin-auto-import, unplugin-vue-components) worked without touching a thing.
If you're on the latest nuxt package, you're likely already getting Vite 8 under the hood in new projects. Check your package.json if you're unsure.
How to Upgrade
# Upgrade Vite and related plugins
npm install vite@latest @vitejs/plugin-vue@latest --save-dev
# For Nuxt projects
npm install nuxt@latest --save-devAfter upgrading:
- Rename
rollupOptionstorolldownOptionsin yourvite.config.ts - Remove
vite-tsconfig-pathsif you use it for basic path aliasing — replace withresolve.tsconfigPaths: true - Run a production build and scan for CommonJS interop warnings
- Test HMR if you have any custom
import.meta.hotlogic - Check the official migration guide if you have a complex config — it's thorough
Worth Upgrading Today?
Absolutely. Vite 8 is stable, the ecosystem has had a few weeks to shake out compatibility issues, and the performance gains are real and measurable. For new projects, there's no reason to reach for Vite 7. For existing projects, the upgrade is low-risk on standard setups.
The Rolldown bet has paid off. The VoidZero team spent two years building toward this, and the result is a build tool that finally has the performance and consistency its ambitions always implied. If you're running any CI pipelines that feel sluggish, upgrading to Vite 8 is probably the highest-ROI change you can make this week.