On May 7, Rolldown 1.0 shipped stable. A patch release, v1.0.1, followed six days later. For most JavaScript developers the moment will pass unnoticed - your vite build will simply be faster the next time you run it. That is precisely the point. The bundler underneath the most widely used frontend tool on the planet has been rewritten in Rust, and the changeover is meant to feel like nothing happened.
It is worth pausing on what happened anyway. Vite 8, released on March 12, was the version that pulled Rolldown into the default install. Rolldown 1.0 is the bundler underneath finally calling itself production-ready in its own right. The combination ends a thirteen-year run for Rollup as the production bundler of choice in the JavaScript ecosystem, and it quietly reorganises the build pipeline that ships almost every modern frontend.
Two bundlers, one tool, one long-running problem
Until Vite 7, every Vite project was secretly running two bundlers. esbuild handled the dev server: pre-bundling dependencies, transforming TypeScript and JSX on the fly, doing the work where you needed millisecond response times. Rollup handled production: code splitting, tree-shaking, plugin hooks, the long tail of optimizations you need for a real deploy.
Splitting the work made sense in 2020. esbuild was the only thing fast enough for dev. Rollup was the only thing flexible enough for production. The cost was a permanent dev/prod gap: behavior that diverged between the two, plugins that ran in one but not the other, source maps that disagreed on what a line was. Anyone who has spent an evening chasing a bug that only appeared in vite build but never in vite dev knows the shape of it.
Rolldown collapses both jobs into a single Rust binary. It is the bundler in dev, the bundler in production, the thing that pre-bundles dependencies, the thing that does the final optimization pass. One pipeline, one source of truth, one place to look when something goes wrong.
What Rolldown 1.0 actually is
Rolldown is built by VoidZero, the company Evan You founded in late 2024 specifically to rewrite the JavaScript toolchain in Rust. The same team owns Vite, Oxc (the Rust-based parser, resolver, transformer, and minifier), and Rolldown itself. That alignment matters: for the first time in a long time, the build tool, the bundler, and the underlying compiler are all maintained by one group with a shared roadmap.
The stated design goal, repeated across the RC announcement in January and the 1.0 post, is to combine "the speed of esbuild and the ecosystem compatibility of Rollup." Read that closely. Rolldown is not trying to invent a third bundler model. It is trying to be Rollup that runs at esbuild speed, with a deliberately narrower scope than Rollup so it can stay fast.
Rolldown is a JavaScript/TypeScript bundler written in Rust intended to serve as the future bundler used in Vite.
That line, from the project's own README, is the entire pitch in one sentence. It is not trying to displace Webpack in legacy enterprise builds. It is not trying to be a Turbopack competitor. It is trying to be the engine Vite needed.
The Rollup compatibility story
The interesting engineering choice is not the speed. esbuild has been fast for years. The choice is the plugin API.
Rolldown adopts Rollup's plugin interface - the hooks (resolveId, load, transform, renderChunk, and so on), the metadata shape, the lifecycle. That is what makes the migration plausible. @vitejs/plugin-vue, @vitejs/plugin-react, the unplugin ecosystem, and most of the long tail of community Vite plugins keep working without changes. Vite 8's rollupOptions still resolves. The Rollup output options still resolve. The plugin you wrote in 2023 still runs.
There are sharp edges. Rolldown ships with Oxc-powered replacements for hot-path plugins that used to run in JavaScript - @rollup/plugin-commonjs and @rollup/plugin-node-resolve are now redundant; the work happens inside Oxc, in Rust, with no plugin boundary to cross. Rolldown also introduces hook filters that let plugins declare up front which file types they care about, so the JavaScript bridge stays cold for files that do not match. The 1.0 release notes are explicit that this is a soft compatibility, not a strict one: if your project uses niche Rollup plugin hooks or advanced transformation features, the team's guidance is to test your build after upgrading.
In practice that has meant most teams upgrade without incident, and a small percentage hit a plugin doing something exotic with the render-phase API. The cost-benefit math is brutal enough that nobody is dwelling on it.
The numbers
The 10-30x figure that the announcement leads with compares Rolldown to Rollup on apples-to-apples production builds. It is real, and the gap widens with project size - the bigger your monorepo, the more obvious the speedup. The DevClass writeup from the Vite 8 launch captures the better story, which is what actually happened to real codebases:
- Linear: production build dropped from 46 seconds to 6 seconds.
- Ramp: 57% reduction in build time.
- Mercedes-Benz.io: up to 38% reduction.
- Beehiiv: 64% reduction.
These are not synthetic benchmarks. They are companies that ran the beta against production codebases and reported the numbers back. The 1.0 announcement adds a memory figure too: peak resident memory during builds is reportedly cut by up to 100x in worst-case projects - not because Rolldown is doing less work, but because it can drop intermediate state the moment it is no longer needed in a way a garbage-collected JavaScript bundler structurally cannot.
If you ship CI that pays per minute, the 46-to-6 number is a budget line.
What this does to Rollup
The official messaging on Rollup is gracious. The Vite 8 post thanks Rollup at length and makes no statement about deprecating it. The Rolldown 1.0 post is careful to position the project as inheriting Rollup's plugin API rather than competing with Rollup itself. Nobody is putting a gravestone on the lawn.
And yet. Rollup's reason for existing in the modern ecosystem was that Vite used it. Library authors who pick a bundler today - and Rolldown's library-mode sibling tsdown is increasingly the answer there too - have a Rust-speed option that runs their existing Rollup plugins. The InfoQ piece from November framed Rolldown as "Rollup-compatible API with the speed of Rust," which is also a fair description of what now happens to Rollup's market position.
Rollup will be maintained. Rollup will keep working. Rollup will also stop being what new projects reach for, because the same plugins now run on something an order of magnitude faster. That is the actual shift, and the absence of a deprecation announcement does not change it.
The opt-out path, or lack of one
Vite 8 does not expose a flag to fall back to the esbuild-plus-Rollup combo. If you upgrade to Vite 8, you are on Rolldown. The documented migration path for cautious teams is to first move from vite to the rolldown-vite package on Vite 7 - a drop-in replacement that lets you flip just the bundler while everything else stays on the older Vite. Once that is stable in your CI, you upgrade to Vite 8 proper.
This is unusually direct for a major Vite upgrade. There is no period of "Rolldown is opt-in for early adopters." The beta was opt-in. Stable is not.
How to actually upgrade
The pragmatic order, if you are coming from Vite 7:
# 1. Stay on Vite 7 but swap the bundler.
pnpm remove vite
pnpm add -D rolldown-vite
# 2. Run your build. Diff the output. Diff your bundle analyzer.
pnpm build
# 3. Once green in CI for a week, upgrade.
pnpm add -D vite@^8Three things are worth watching after the swap. First, your CommonJS interop edges - require() calls inside ESM packages, default export shapes from older libraries. Rolldown handles these inside Oxc, and the result is usually cleaner than the old plugin chain, but not always identical. Second, source maps - they generally improve, but anything that consumes them (Sentry release uploads, custom error reporters) should be re-tested. Third, any plugin doing CSS post-processing in generateBundle - that is the hook most likely to behave slightly differently.
If you maintain a Vite plugin, the migration is usually nothing. Most plugins compile against the Rollup type signatures and are forward-compatible by accident. The exception is anything reaching into this.parse or this.getModuleInfo expecting Acorn-shaped AST nodes - Rolldown's parser is Oxc, the AST is similar but not identical, and that gap is where most plugin authors will spend an afternoon.
The bigger picture, briefly
Rolldown is the visible piece of something larger. The same team is shipping Oxc - already faster than Prettier at formatting, faster than ESLint at linting, faster than Babel at transforming - underneath Rolldown, but also as a standalone toolchain. The unplugin-oxc project wires Oxc directly into Rollup, esbuild, Webpack, and Rspack for teams that want the parser speedup without the full migration.
Step back and the pattern is unmistakable: every layer of the JavaScript build toolchain - parser, transformer, formatter, linter, bundler - is being rewritten in Rust by overlapping groups of people. Biome on the linter and formatter side. Oxc and Rolldown on the parser and bundler side. swc continuing as Next.js's compiler. The Zig-and-then-Rust Bun toolchain as a fourth axis. They will not all survive. The toolchain that exists in 2030 will look very different from the one we ship today.
Rolldown 1.0 is interesting not because it is the fastest bundler - it is, today, but that lead is contested. It is interesting because it picked the right compatibility surface. By committing to Rollup's plugin API, it inherited a decade of accumulated ecosystem work for free, and made the migration cost approximately zero for the median team. That is a harder engineering achievement than the speed.
This week
If you ship on Vite, install rolldown-vite on Vite 7 and let it bake. The migration is small, the upside is large, and your CI bill will notice. If you ship a Vite plugin, run your test suite against Rolldown now and report anything that breaks - the team is actively gathering edge cases in the 1.0 issue tracker, and the window where they will fix things quickly is open. If you are starting a new library, look at tsdown before reaching for Rollup.
And if you maintain a Rollup-only plugin, the strategic question is whether to mark it Rolldown-compatible explicitly. The answer is almost certainly yes. The default bundler changed underneath you - quietly, on a Tuesday in May - and pretending it did not will not slow anything down.