On May 7, 2026, VoidZero shipped Rolldown 1.0 stable. Rolldown is the Rust-based JavaScript bundler that has been quietly absorbing one of the most-used pieces of frontend tooling on the planet: it's the default bundler inside Vite 8, which itself went stable in March. The 1.0 release isn't a surprise launch — it's the end of a two-year migration that culminated when the Vite team flipped the default to Rolldown earlier this year.
If your team ships anything built with Vite — and at this point, that includes most React, Vue, Svelte, SolidJS, and Astro apps — this is a release worth understanding. Not because it forces you to do anything, but because it locks in a contract for the bundler that's going to run your builds for the foreseeable future, and it sets up some changes to local development that are going to land over the next few months.
What "1.0" actually means here
Rolldown follows semantic versioning, and the 1.0 designation means the ^1.0.0 public surface is now locked. That covers option names, types, and plugin hook signatures. VoidZero is explicit that there are no planned breaking changes to that API, with the exception of features still marked experimental.
The team flags one nuance worth reading carefully: output behavior can still change. Dead code elimination, chunking heuristics, and inlining defaults will keep improving as the project matures. That doesn't change the runtime semantics of the code you ship, but it does mean your bundle sizes and chunk boundaries may shift across minor versions. If your CI gates on exact bundle byte counts, plan for some drift.
For teams running Vite, the implication is simpler. Vite 8 already shipped Rolldown as the default. Upgrading from the latest RC to 1.0 needs no code changes. The contract you've been depending on is now formally guaranteed.
How we got here, briefly
The migration was deliberately slow. The first public Rolldown release was 0.10.1 in April 2024. A rolldown-vite package shipped in May 2025 as a technical preview so plugin authors and end users could opt in early. Vite 8's beta in December 2025 made Rolldown the default, the RC in January 2026 locked the API, Vite 8 stable shipped in March, and Rolldown 1.0 stable closed the loop in May.
The reason this took two years is that Rolldown didn't just need to be fast — it needed to be a Rollup-compatible plugin host. Before Rolldown, Vite used esbuild for the dev transform and Rollup for production bundling. Two transformation pipelines, two plugin systems, and a layer of glue code between them. A drop-in Rust bundler that wasn't plugin-compatible would have broken thousands of community packages overnight. So Rolldown had to implement Rollup's plugin API in Rust, and it had to do it well enough that most existing Vite plugins worked unchanged.
That groundwork is what unlocks the rest of the story.
What's actually new
Three things are worth knowing about specifically.
Hook filters keep plugins out of the hot path
Rollup-compatible plugins are still written in JavaScript, which means each Rust-to-JS hop has overhead. Rolldown's plugin API adds hook filters: a plugin can declare an id, code, or moduleType filter, and if the filter doesn't match, the bundler skips the JS hop entirely. Adding plugins no longer linearly slows your build, as long as those plugins declare appropriate filters.
For plugins that haven't been updated, Rolldown ships a withFilter helper that wraps them on the consumer side — so you can opt a third-party plugin into the fast path from your own config.
// rolldown.config.js
import { defineConfig, withFilter } from 'rolldown'
import legacy from 'some-legacy-plugin'
export default defineConfig({
input: 'src/main.ts',
plugins: [
withFilter(legacy(), { id: /\.svelte$/ }),
],
})
This is the kind of detail that doesn't show up in headline benchmark numbers but matters enormously in real codebases with twenty or thirty plugins active.
Granular code splitting
Chunking is configurable in a way Rollup never quite was. You can declare webpack-style chunk groups directly in your Vite or Rolldown config:
// vite.config.ts
import { defineConfig } from 'vite'
export default defineConfig({
build: {
rolldownOptions: {
output: {
codeSplitting: {
groups: [
{ name: 'vendor', test: /node_modules/ },
{ name: 'shared', test: /src\/shared\// },
],
},
},
},
},
})
Framer reported a 67% reduction in chunk count after moving to Rolldown's chunking rules. Smaller chunk graphs are a real performance win — fewer chunks means fewer round trips, less HTTP/2 overhead, and a simpler critical path for initial render. It's also one of the few build-time changes that consistently improves Largest Contentful Paint on real-world pages.
Aggressive dead code elimination
Rolldown leans on @__PURE__, @__NO_SIDE_EFFECTS__, and package.json sideEffects hints to do more aggressive dead code elimination than Rollup did out of the box. There's also a DCE-only minification mode that strips dead code without mangling identifiers, which is useful when you want readable output for debugging without paying for unused code paths.
If you ship a library, audit your package.json sideEffects field. It's the cheapest performance win available right now, and Rolldown actually respects it.
The case studies are real
Performance claims usually need a pinch of salt. The numbers VoidZero published are concrete: Ramp reported a 57% build time reduction, Mercedes-Benz.io up to 38%, Beehiiv 64%. Framer and PLAID are running it in production. Full benchmarks live in rolldown/benchmarks.
For your own team, the impact depends on bundler-bound time. If CI is dominated by typecheck, test, or deploy steps, Rolldown won't move that needle. If vite build takes minutes on a large SPA, expect a noticeable drop — and you've probably already gotten it, since Vite 8 has been stable for two months.
What's coming next
The two announcements buried in the "what's next" section of the 1.0 post are worth flagging.
The first is Vite full bundle mode. Vite's original sales pitch was unbundled ESM during development — every module served as a separate request, with HMR layered on top. That worked at small to medium scale. At large scale it didn't: a cold dev start on a big app could fire off thousands of network requests. With Rolldown fast enough to bundle on every reload, the calculus changes. VoidZero is reporting 3x faster dev startup, 40% faster full reloads, and 10x fewer network requests in early measurements.
The second is lazy barrel optimization moving toward stable. Barrel files — the index.ts files that re-export from everything in a folder — have always been a footgun in JavaScript tooling. Bundlers had to load every module in the barrel even if only one was used downstream. Rolldown's lazy barrel optimization walks the export graph and only includes modules that are actually referenced. The experimental version is already in 1.0; stabilizing it would let teams keep their ergonomic barrel files without paying for them at build time.
Practical takeaways
If you're on Vite 8, you don't need to do anything — Rolldown 1.0 is already underneath you. The 1.0 stamp is a contract guarantee, not a migration deadline.
If you're maintaining a Vite plugin, take a pass over your hooks and add id, code, or moduleType filters where they apply. Your users won't see your plugin in their profiler if it stays out of the hot path. The filter API is documented in Rolldown's plugin reference.
If you're still on Vite 5 or 6, the upgrade to Vite 8 is the meaningful move here. The Rolldown 1.0 ship makes it materially safer than it was a few months ago, because the API surface is now locked.
And if you're starting a new project, default to Vite 8. There is no longer a credible "wait and see" position on Rolldown as the bundler — it's stable, it has a published roadmap, and the projects depending on it in production aren't speculative anymore.
The deeper signal in this release is the one VoidZero understates in the post: Rolldown is no longer a Vite-internal detail. It's a standalone bundler with a Rollup-compatible plugin ecosystem and esbuild-class performance, available for any project that wants to use it directly. For build tooling that's been stuck on the same trade-offs for a decade, that's the real news.