Vite 7 ships the most consequential change in the toolchain's history: the production build no longer runs on Rollup. It runs on Rolldown, a bundler written in Rust, which has become the default for teams shipping to production. For most developers the change is invisible - you bump a version, run a build, and everything is faster. But if you run a large application, a monorepo, or a plugin-heavy stack, the swap deserves a deliberate migration rather than a drive-by upgrade. This post covers what actually changes and how to migrate without surprises.
What Rolldown actually changes
Rolldown is a Rust reimplementation of Rollup's architecture: the same plugin interface, the same input/output model, a different engine. The practical consequences fall into three buckets:
- Build speed. Cold builds on large applications typically improve three- to five-fold, with the biggest gains in dependency bundling and the tree-shaking pass. A build that took forty seconds often lands somewhere around ten.
- Memory. Peak resident memory stays roughly flat as the module graph grows, instead of scaling linearly the way a JavaScript engine's heap does. If your CI node has been OOM-killing builds, Rolldown frequently fixes that for free.
- Stable dev, faster build. Development still runs through Vite's dev server; Rolldown takes over the production side. That split is the point — you get Rollup-compatible output without paying Rollup's build-time cost.
# before: vite@6 (Rollup-based)
# after: vite@7 (Rolldown-based)
npx vite build
# 3421 modules transformed.
# dist/assets/index-a1b2.js 412.87 kB │ gzip: 118.30 kB
# built in 9.42s # was ~41s on Vite 6The migration path in practice
- Upgrade the toolchain. Bump Vite to 7 and confirm your framework integration is compatible. The React, SvelteKit, SolidStart, and Vue toolchains all ship compatible builds; if your framework pins Vite 6, that pin - not Rolldown — is your real constraint.
- Build twice, diff the output. Produce builds with Vite 6 and Vite 7 into separate directories and compare chunk counts, entry sizes, and asset hashes. Expect minor differences in chunk partitioning: Rolldown schedules module resolution in parallel, so a module can land in a different chunk than under Rollup's serial walk. That is normal, not a bug.
- Re-baseline your bundle budget. Tree-shaking results are nearly identical, but export inlining and module concatenation can shift final size by a couple of percent in either direction. Set your size-gate thresholds from one clean baseline build, not from guesswork.
- Audit the plugin stack. This is where migration effort concentrates, so read the next section before flipping the switch.
Plugin compatibility: where the real work is
Rolldown targets the Rollup plugin API, so most pure-JavaScript plugins work unchanged. Failures cluster in three places:
- Plugins that reach past the public API. Anything that touches Rollup internals - resolver hacks, direct module-graph access - is the likeliest to break. If a fix exists, pin to the version that declares Vite 7 compatibility rather than running the latest.
- Source-map and asset pipelines. A handful of CSS and asset plugins produced subtly different source maps during the preview period. If your error reporting or coverage tooling depends on map fidelity, diff generated maps against a known-good build before trusting the new output.
- Native bindings. Some minifiers and transforms ship native or WASM accelerators that assume Rollup's hook timing. A build that dies inside a native plugin with no JavaScript stack trace is your cue to swap in a pure-JavaScript equivalent and retest.
| Concern | Rollup (Vite 6) | Rolldown (Vite 7) |
|---|---|---|
| Cold build, large app | ~40 s | ~9 s |
| Peak memory | Scales with module count | Roughly flat |
| Chunk partitioning | Deterministic, serial walk | Deterministic per run, parallel-scheduled |
| JS plugin API | Reference implementation | Same interface, compatible |
| Tree-shaking result | Baseline | Within ~2% either direction |
A note on incremental and watch builds
Most migration anxiety is about the production build, but the change also touches the watch and HMR loop in subtle ways. Rolldown's module graph is built and invalidated differently, so a large refactor can trigger a slightly different set of hot reloads than you saw under Rollup. Nothing you will notice day to day, but if your team relies on HMR for a fast feedback loop during heavy edits, spend an afternoon in watch mode after the upgrade and confirm your perceived speed. It is a cheap check that catches the rare case where an invalidated module is re-bundled wholesale instead of patched, which would read as a full-reload flash at the worst moment in a long editing session.
What to watch in production
Once you cut over, two signals matter more than the build itself. First, cache behavior: if you hash-fingerprint assets, the changed chunk partitioning invalidates your CDN cache exactly once. Schedule that deploy so the cache flush is an expected event rather than a mystery traffic spike. Second, error-stack fidelity: source maps remain structurally identical, but the module identifiers inside change. If your error tracker keys on module paths, verify the mapping on day one or you will spend a week chasing "missing" files.
Rolldown is not a new way of bundling. It is the same way of bundling at a different speed, and the migration is deliberately boring - which is exactly what you want from infrastructure.
When to hold off
If your pipeline is small - a few hundred modules - the win is seconds and the risk is negligible either way, so upgrade at your convenience. If you run an exotic plugin stack, a forked Vite, or a framework that has not yet released a Vite 7-compatible build, stay on Vite 6 until the framework moves. Rolldown's compatibility target is the ecosystem, not your repo: waiting a few weeks for a framework pin to move is cheaper than debugging a half-upgraded toolchain.
Comments