Rolldown is the bundler inside Vite 8: the tool that takes your .vue, .ts and CSS files and produces the optimised files in dist/ when you run vite build. It is written in Rust, and it replaced the pair Vite used before, esbuild for development and Rollup for production builds. On 7 May, after a release candidate phase that started in January, it reached 1.0.0, which the announcement calls stable and ready for production.
If your Vue app is on Vite 8, it already builds with Rolldown, and updating Vite to 8.0.12 brings in 1.0 without a change to your code. You meet Rolldown directly in two places: the build options in vite.config.ts, where one common Vite 7 chunking setting no longer works, and the errors a failed build prints.
What 1.0 promises
Rolldown follows semantic versioning, so everything in the ^1.0.0 range keeps its public API. The announcement spells out what that covers: option names, option types and plugin hook signatures stay backward-compatible, and there are no planned breaking changes to the public API. The one exception is anything marked experimental.
It is just as clear about what is not frozen. The output can still change. Dead code elimination (removing code nothing uses), chunking and inlining heuristics will keep improving, and option defaults may shift to produce smaller and faster bundles. The team says this does not change how the output behaves at runtime, and that such changes will be noted in the release notes.
For anyone already on the latest release candidate, the post says upgrading needs no code changes. The changes since the RC are mostly bug fixes, plus two experimental pieces: watch mode rebuilt on a new native file watcher, with WASM support, and a native MagicString (the library plugins use to edit code while keeping source maps) that can stand in for the JavaScript version.
Speed, plugins and smaller bundles
The announcement puts Rolldown at 10 to 30 times faster than Rollup, with the gap growing as projects get bigger, and on par with esbuild. It quotes three production results: Ramp cut its build time by 57%, Mercedes-Benz.io by up to 38% and Beehiiv by 64%. Rolldown uses Oxc, the Rust toolchain from the same team, for parsing and minification.
Plugin compatibility was the condition for putting it inside Vite. Rolldown implements Rollup's plugin API, and the post says most Vite plugins work out of the box on Vite 8. Two additions make plugins cheaper. A plugin can declare a hook filter on the module id, code or module type, and Rolldown then skips the trip from Rust to JavaScript for modules that do not match. Built-in plugins written in Rust, such as replacePlugin and esmExternalRequirePlugin, replace common Rollup plugins.
For the output, the post highlights:
- more aggressive dead code elimination, which honours
@__PURE__,@__NO_SIDE_EFFECTS__and thesideEffectsfield - inlining of constants and TypeScript
const enumvalues - granular code splitting with chunk rules, credited with a 67% reduction in chunks at Framer
How it fits with Vite 8 and Vite+
The announcement calls swapping Vite's bundler a two-year project:
- April 2024: the first public release
- December 2024: the first 1.0 beta
- May 2025:
rolldown-vite, a temporary preview package - December 2025: the Vite 8 beta, with Rolldown as the default bundler
- January 2026: the 1.0 release candidate
- 12 March 2026: Vite 8 stable
- 7 May 2026: Rolldown 1.0
It names Vite 8 as Rolldown's main entry point, so new Rolldown features and improvements reach Vite users directly.
Vite+ is the other place Rolldown appears. It is VoidZero's unified toolchain, open source under the MIT licence and in alpha since 13 March, which wraps Vite, Vitest, Oxlint, Oxfmt, Rolldown and tsdown behind one vp command. The Rolldown announcement mentions Vite+ only through the vp tab in its command snippets, which puts vp add -D rolldown next to the npm, pnpm, yarn and bun commands.
Update Vite to get Rolldown 1.0
Rolldown reaches your app through Vite. Vite 8.0.11, published on 7 May, still shipped with release candidate 18. Vite 8.0.12, published on 11 May, pins rolldown 1.0.0 exactly. Update Vite and check which Rolldown you got:
npm install -D vite@^8.0.12
npm ls rolldown
The second command should print rolldown@1.0.0 under vite@8.0.12. Vite 8 still needs Node 20.19 or a later 20.x release, or Node 22.12 or newer, according to its engines field.
Then run npm run build and compare the file sizes Vite prints with your last build. They may move a little; that is the "output behaviour may still change" clause at work, not a bug.
Rename rollupOptions and replace manualChunks
In a Vite 8 config, Rolldown's options live under build.rolldownOptions. The build options reference lists build.rollupOptions as a deprecated alias for the same thing, and worker.rollupOptions is renamed worker.rolldownOptions in the same way. The alias still works, but one option inside it does not. This chunking config is common in Vite 7 projects:
import vue from '@vitejs/plugin-vue'
import { defineConfig } from 'vite'
export default defineConfig({
plugins: [vue()],
build: {
rollupOptions: {
output: {
manualChunks: {
vue: ['vue', 'vue-router', 'pinia'],
},
},
},
},
})
Rolldown 1.0 warns that manualChunks should be a function, then stops the build with TypeError: manualChunks is not a function. The Vite 8 migration guide says the object form of manualChunks is no longer supported and the function form is deprecated. The replacement is Rolldown's codeSplitting option with groups:
import vue from '@vitejs/plugin-vue'
import { defineConfig } from 'vite'
export default defineConfig({
plugins: [vue()],
build: {
rolldownOptions: {
output: {
codeSplitting: {
groups: [
{ name: 'vue', test: /node_modules[\\/](vue|@vue|vue-router|pinia)[\\/]/, priority: 2 },
{ name: 'vendor', test: /node_modules/, priority: 1 },
],
},
},
},
},
})
Each group's name becomes the chunk name, so this build writes a vue- file and a vendor- file into dist/assets/. test matches module ids; Rolldown's reference recommends [\\/] rather than / so the pattern also matches Windows paths. When a module matches two groups, the higher priority wins, which is why the Vue group takes Vue's packages before the catch-all vendor group sees them.
How to read a Rolldown error
When a build fails, Vite prints error during build: followed by an error whose first line counts the problems, such as Build failed with 1 error:. The errors come next, at most five, and an ellipsis stands for the rest. Errors Rolldown detects itself carry a code in square brackets and a code frame: the source line involved, with the problem underlined. Import a function under a name the other file does not export, and you get this:
[MISSING_EXPORT] Error: "formatPrice" is not exported by "src/utils/money.ts".
╭─[ src/stores/cart.ts:1:10 ]
│
1 │ import { formatPrice } from '../utils/money'
│ ─────┬─────
│ ╰─────── Missing export
───╯
Read it in three parts:
- The code in brackets,
MISSING_EXPORT, identifies the kind of problem. - The message names the file missing the export, in quotes. The frame header names the file doing the importing, with line and column:
src/stores/cart.ts:1:10. - The frame underlines the exact name that failed.
In this case money.ts exports formatMoney, and the fix is to correct the import.
Errors thrown by a plugin look different. They start with [plugin vite:vue] and a file path, which tells you the Vue plugin failed while compiling that component, so the problem is in the .vue file's template or script rather than in how modules connect. A stack trace follows all of this. Read the first lines first; they usually hold the answer.
What the Rolldown team is working on next
The post lists two next steps, both work in progress.
- Full bundle mode for Vite's development server. It bundles the whole app in development the way production does, instead of serving each file as a separate module. The team quotes preliminary numbers of 3 times faster startup, 40% faster full reloads and 10 times fewer network requests.
- Stable lazy barrel optimisation. A barrel is an
index.tsthat re-exports a whole folder. Bundlers have traditionally compiled every module behind it, even when you use only part of it; the optimisation, experimental in 1.0, compiles only the modules you use.