Vite 8 beta: Rolldown becomes the bundler

Every Vue project scaffolded with npm create vue@latest builds with Vite, and until now Vite has built with two other tools: esbuild to transform files during development and to pre-bundle dependencies, and Rollup to produce the production bundle. The first beta of Vite 8, published on 3 December, replaces both with Rolldown. The beta announcement says the team focused on keeping the configuration API and plugin hooks unchanged; what changes is the build underneath them.

Vite 7.2 is still the stable release: it was published on 5 November, and 7.2.6 is the version a fresh project gets today. The beta is for testing. A Vue app's config barely changes, but the JavaScript and CSS minifiers, the default browser targets and one CommonJS rule all change at once, so a build on a branch now shows what the upgrade will involve.

Why Vite now uses one bundler instead of two

The announcement names the cost of the old arrangement: two transformation pipelines, two plugin systems, and a growing amount of glue code to keep development and production behaving the same.

Rolldown is a bundler written in Rust by the VoidZero team with the explicit goal of being used inside Vite. It supports the Rollup plugin API, so most Vite plugins keep working. For everything a bundler needs around it, it uses Oxc, the same team's parser, resolver, transformer and minifier. Vite, Rolldown and Oxc are now maintained together, which is the structural point of the release.

The speed numbers come from early adopters of rolldown-vite, the technical preview VoidZero announced at the end of May: Linear's production build went from 46 seconds to 6, Mercedes-Benz.io cut its build time by up to 38 percent and Beehiiv by 64 percent. Rolldown's own benchmarks put it at esbuild's level and 10 to 30 times faster than Rollup.

Renamed and new options in your Vite config

The migration guide describes a compatibility layer that translates the old Rollup and esbuild options into the new ones and marks the old names as deprecated. A vite.config.ts from create-vue sets only plugins and the @ alias, so it needs no edits. Two renames matter if you added options of your own.

build.rollupOptions is renamed build.rolldownOptions, and output.manualChunks is deprecated in favour of advancedChunks. A config that splits a vendor chunk changes from the function form to a declarative one:

import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'

export default defineConfig({
  plugins: [vue()],
  build: {
    rolldownOptions: {
      output: {
        advancedChunks: {
          groups: [{ name: 'vue', test: /\/node_modules\/(vue|vue-router|pinia)\// }],
        },
      },
    },
  },
})

name is the chunk's name, used in its file name, and test picks modules by their path. By default a group also takes in what its modules import, so Vue's internal @vue/* packages land in the same chunk without being listed.

The esbuild option becomes oxc, and the guide lists the mapping: esbuild.jsxInject to oxc.jsxInject, esbuild.define to oxc.define, and so on. A Vue project rarely sets any of these.

The beta also adds one option and one automatic feature. resolve.tsconfigPaths: true makes Vite resolve imports through the paths in tsconfig.json; it is off by default because it costs a little speed. TypeScript's emitDecoratorMetadata option is now supported automatically.

New defaults that change the build output

Minification moves to the Oxc minifier for JavaScript and to Lightning CSS for stylesheets. You can switch back with build.minify: 'esbuild' (deprecated) or build.cssMinify: 'esbuild', but esbuild is now an optional dependency, so you must install it yourself first. The guide gives two warnings. Lightning CSS lowers more syntax (rewrites newer CSS for older browsers), so a CSS bundle may grow slightly. And the two JavaScript minifiers make slightly different assumptions about your code.

The default browser target moves up, from Chrome 107, Edge 107, Firefox 104 and Safari 16.0 to Chrome 111, Edge 111, Firefox 114 and Safari 16.4. These match the Baseline Widely Available set for 1 January 2026, browsers released about two and a half years before that date. A project that must support older browsers sets build.target explicitly.

CommonJS interop can change how code runs, not only how it builds. A CommonJS package is one written with require and module.exports instead of import and export. The default import from such a package now follows one rule in development and production, where before the two used different rules. A package that depended on the difference may import differently; the deprecated legacy.inconsistentCjsInterop: true restores the old behaviour for now while you report the problem to the package author.

What the beta removes or does not support

Other entries in the guide carry no such promise, among them:

• The system and amd output formats are not supported.
• Oxc does not support esbuild's property mangling options (mangleProps and related) or esbuild.supported.
• build.rollupOptions.watch.chokidar is removed; use rolldownOptions.watch.notify instead.
• Vite no longer guesses between the browser and module fields of a dependency's package.json by reading the files; it follows resolve.mainFields in order. A package that relied on the guess needs a resolve.alias entry or a patch.
• Oxc does not yet lower native decorators (rewrite them for runtimes without decorator support), so a project that uses them needs a Babel or SWC plugin for now.
• Extglob patterns (glob syntax such as +(a|b)) are not supported yet.

A Vue application built as ES modules is unlikely to meet most of these. The exception is the browser and module change, because it depends on your dependencies' package.json files, not on your own config.

What plugin authors should check

If you maintain a Vite plugin, four items in the guide are for you. Rolldown assigns a module type from the file extension, so a load or transform hook that turns another format into JavaScript may need to return moduleType: 'js':

import { readFileSync } from 'node:fs'
import type { Plugin } from 'vite'

export function txt(): Plugin {
  return {
    name: 'txt-loader',
    load(id) {
      if (!id.endsWith('.txt')) return
      const content = readFileSync(id, 'utf8')
      return {
        code: `export default ${JSON.stringify(content)}`,
        moduleType: 'js',
      }
    },
  }
}

Hooks that Rollup ran in parallel now run one after another. The bundle object passed to generateBundle and writeBundle can no longer be assigned to (use this.emitFile()), is not shared between hooks, and fails structuredClone() unless you spread it first. And four Rollup hooks are not supported: shouldTransformCachedModule, resolveImportMeta, renderDynamicImport and resolveFileUrl.

What comes next: Full Bundle Mode and Vite+

The announcement says Full Bundle Mode will ship soon. It bundles in development too, and preliminary results show three times faster dev server startup, 40 percent faster full reloads and ten times fewer network requests. Two experiments, raw AST transfer and native MagicString transforms, aim to let plugins written in JavaScript keep up with the Rust core.

Around all of this sits Vite+, which VoidZero showed at ViteConf in Amsterdam in October and described in its announcement as a unified toolchain on top of Vite: vite new, vite test through Vitest, vite lint through Oxlint, vite fmt, vite lib, vite run and vite ui, built on Oxc and Rolldown. The announcement described it as still in development, with a public preview targeted for early 2026. It also set out a commercial, source-available licence, free for individuals, open source projects and small businesses, while Vite, Vitest, Rolldown and Oxc stay open source under MIT. None of it is part of the Vite 8 beta.

Try the beta in a branch

The announcement offers two routes. The gradual one, recommended for large or complex projects, moves from Vite 7 to rolldown-vite, which is Vite 7 with Rolldown and nothing else changed, then to Vite 8, so that any failure is isolated to the bundler. The direct one is a version change. Make a branch first (git switch -c vite-8-beta) so main keeps building on 7.2, then pin vite to the exact beta in package.json:

{
  "devDependencies": {
    "vite": "8.0.0-beta.0"
  }
}

Then install, build and preview:

npm install --legacy-peer-deps
npx vite build
npx vite preview

The flag is there because a plain npm install stops with an ERESOLVE error. The current @vitejs/plugin-vue, 6.0.2, declares Vite 5 to 7 as the versions it works with (its peer range), and npm refuses rather than warns when the conflict involves a dependency in your own package.json. --legacy-peer-deps is one of the two ways past it that npm's error message offers. It ignores peer dependencies for every package, so keep it to this branch.

The peer range is a declaration, not a test result: the announcement says most Vite plugins work with Vite 8 out of the box, and the team runs key plugins and frameworks against the new bundler in CI. Judge by the build. Compare three things against your main branch: the build time, the sizes in dist/assets, and the application itself in vite preview, clicking through the routes that use dynamic imports and the heaviest pages. Report anything odd in the rolldown-vite issues, which is where the team asks for beta reports.

If Vite is not a direct dependency but arrives through a framework or tool, the beta has to be forced with a package manager override, which the announcement spells out for each manager. With pnpm:

{
  "pnpm": {
    "overrides": {
      "vite": "8.0.0-beta.0"
    }
  }
}

npm and Bun use a top-level "overrides" field, Yarn uses "resolutions". Reinstall afterwards.

For a Nuxt project this is a path to look at, not yet to take: the guide's list of items to fix before stable includes a Rolldown issue that affects Nuxt. If you want the gradual route now, Nuxt has had experimental support for the rolldown-vite override since 4.1. Do not force the beta into Vitest either. Vitest 4 depends on Vite 6 or 7 itself, so the direct upgrade above leaves its copy alone, and the same list notes a resolver cache problem that breaks minor cases in Vitest.