> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify.com/vitejs/vite/llms.txt
> Use this file to discover all available pages before exploring further.

# Migration from v7

> Guide to migrating from Vite 7 to Vite 8 with Rolldown

<Note>
  If you are migrating from `rolldown-vite`, the technical preview release for Rolldown integrated Vite for v6 & v7, only the sections with **NRV** badge in the title are applicable.
</Note>

## Default Browser Target Change

The default browser value of `build.target` and `'baseline-widely-available'`, is updated to newer browser version:

* Chrome 107 → 111
* Edge 107 → 111
* Firefox 104 → 114
* Safari 16.0 → 16.4

These browser versions align with [Baseline Widely Available](https://web-platform-dx.github.io/web-features/) feature sets as of 2026-01-01. In other words, they were all released about two and a half years ago.

## Rolldown

Vite 8 uses [Rolldown](https://rolldown.rs/) and [Oxc](https://oxc.rs/) based tools instead of [esbuild](https://esbuild.github.io/) and [Rollup](https://rollupjs.org/).

### Gradual Migration

The `rolldown-vite` package implements Vite 7 with Rolldown, without other Vite 8 changes. This can be used as a intermediate step to migrate to Vite 8. See [the Rolldown Integration guide](https://v7.vite.dev/guide/rolldown) in the Vite 7 docs to switch to `rolldown-vite` from Vite 7.

<Steps>
  <Step title="Update from rolldown-vite to Vite 8">
    For users migrating from `rolldown-vite` to Vite 8, you can undo the dependency changes in `package.json` and update to Vite 8:

    ```json package.json theme={null}
    {
      "devDependencies": {
        "vite": "npm:rolldown-vite@7.2.2", // [!code --]
        "vite": "^8.0.0" // [!code ++]
      }
    }
    ```
  </Step>
</Steps>

### Dependency Optimizer Now Uses Rolldown

Rolldown is now used for dependency optimization instead of esbuild. Vite still supports [`optimizeDeps.esbuildOptions`](/config/dep-optimization-options#optimizedeps-esbuildoptions) for backward compatibility by converting it to [`optimizeDeps.rolldownOptions`](/config/dep-optimization-options#optimizedeps-rolldownoptions) automatically. `optimizeDeps.esbuildOptions` is now deprecated and will be removed in the future and we encourage you to migrate to `optimizeDeps.rolldownOptions`.

<Accordion title="Automatically converted options">
  The following options are converted automatically:

  * `esbuildOptions.minify` → `rolldownOptions.output.minify`
  * `esbuildOptions.treeShaking` → `rolldownOptions.treeshake`
  * `esbuildOptions.define` → `rolldownOptions.transform.define`
  * `esbuildOptions.loader` → `rolldownOptions.moduleTypes`
  * `esbuildOptions.preserveSymlinks` → `!rolldownOptions.resolve.symlinks`
  * `esbuildOptions.resolveExtensions` → `rolldownOptions.resolve.extensions`
  * `esbuildOptions.mainFields` → `rolldownOptions.resolve.mainFields`
  * `esbuildOptions.conditions` → `rolldownOptions.resolve.conditionNames`
  * `esbuildOptions.keepNames` → `rolldownOptions.output.keepNames`
  * `esbuildOptions.platform` → `rolldownOptions.platform`
  * `esbuildOptions.plugins` → `rolldownOptions.plugins` (partial support)
</Accordion>

<Tip>
  You can get the options set by the compatibility layer from the `configResolved` hook:

  ```js theme={null}
  const plugin = {
    name: 'log-config',
    configResolved(config) {
      console.log('options', config.optimizeDeps.rolldownOptions)
    },
  }
  ```
</Tip>

### JavaScript Transforms by Oxc

Oxc is now used for JavaScript transformation instead of esbuild. Vite still supports the [`esbuild`](/config/shared-options#esbuild) option for backward compatibility by converting it to [`oxc`](/config/shared-options#oxc) automatically. `esbuild` is now deprecated and will be removed in the future and we encourage you to migrate to `oxc`.

<Accordion title="Automatically converted options">
  The following options are converted automatically:

  * `esbuild.jsxInject` → `oxc.jsxInject`
  * `esbuild.include` → `oxc.include`
  * `esbuild.exclude` → `oxc.exclude`
  * `esbuild.jsx` → `oxc.jsx`
    * `esbuild.jsx: 'preserve'` → `oxc.jsx: 'preserve'`
    * `esbuild.jsx: 'automatic'` → `oxc.jsx: { runtime: 'automatic' }`
      * `esbuild.jsxImportSource` → `oxc.jsx.importSource`
    * `esbuild.jsx: 'transform'` → `oxc.jsx: { runtime: 'classic' }`
      * `esbuild.jsxFactory` → `oxc.jsx.pragma`
      * `esbuild.jsxFragment` → `oxc.jsx.pragmaFrag`
    * `esbuild.jsxDev` → `oxc.jsx.development`
    * `esbuild.jsxSideEffects` → `oxc.jsx.pure`
  * `esbuild.define` → `oxc.define`
  * `esbuild.banner` → custom plugin using transform hook
  * `esbuild.footer` → custom plugin using transform hook
</Accordion>

<Warning>
  The `esbuild.supported` option is not supported by Oxc. If you need this option, please see [oxc-project/oxc#15373](https://github.com/oxc-project/oxc/issues/15373).
</Warning>

<Note>
  Currently, the Oxc transformer does not support lowering native decorators as we are waiting for the specification to progress, see ([oxc-project/oxc#9170](https://github.com/oxc-project/oxc/issues/9170)).
</Note>

<Accordion title="Workaround for lowering native decorators">
  You can use [Babel](https://babeljs.io/) or [SWC](https://swc.rs/) to lower native decorators for the time being. While SWC is faster than Babel, it does **not support the latest decorator spec** that esbuild supports.

  The decorator spec has been updated multiple times since it reached stage 3. The versions supported by each tool are:

  * `"2023-11"` (esbuild, TypeScript 5.4+ and Babel support this version)
  * `"2023-05"` (TypeScript 5.2+ supports this version)
  * `"2023-01"` (TypeScript 5.0+ supports this version)
  * `"2022-03"` (SWC supports this version)

  See the [Babel decorators versions guide](https://babeljs.io/docs/babel-plugin-proposal-decorators#version) for differences between each version.
</Accordion>

#### esbuild Fallbacks

`esbuild` is no longer directly used by Vite and is now an optional dependency. If you are using a plugin that uses the `transformWithEsbuild` function, you need to install `esbuild` as a `devDependency`. The `transformWithEsbuild` function is deprecated and will be removed in the future. We recommend migrating to the new `transformWithOxc` function instead.

### JavaScript Minification by Oxc

The Oxc Minifier is now used for JavaScript minification instead of esbuild. You can use the deprecated [`build.minify: 'esbuild'`](/config/build-options#build-minify) option to switch back to esbuild. This configuration option will be removed in the future and you need install `esbuild` as a `devDependency` as Vite no longer relies on esbuild directly.

If you were using the `esbuild.minify*` options to control minification behavior, you can now use `build.rolldownOptions.output.minify` instead. If you were using the `esbuild.drop` option, you can now use `build.rolldownOptions.output.minify.compress.drop*` options.

<Warning>
  Property mangling and its related options (`mangleProps`, `reserveProps`, `mangleQuoted`, `mangleCache`) are not supported by Oxc. If you need these options, please see [oxc-project/oxc#15375](https://github.com/oxc-project/oxc/issues/15375).
</Warning>

esbuild and Oxc Minifier make slightly different assumptions about source code. In case you suspect the minifier is causing breakage in your code, you can compare these assumptions here:

* [esbuild minify assumptions](https://esbuild.github.io/api/#minify-considerations)
* [Oxc Minifier assumptions](https://oxc.rs/docs/guide/usage/minifier.html#assumptions)

Please report any issues you find related to minification in your JavaScript apps.

### CSS Minification by Lightning CSS

[Lightning CSS](https://lightningcss.dev/) is now used for CSS minification by default. You can use the [`build.cssMinify: 'esbuild'`](/config/build-options#build-cssminify) option to switch back to esbuild. Note that you need to install `esbuild` as a `devDependency`.

Lightning CSS supports better syntax lowering and your CSS bundle size might increase slightly.

### Consistent CommonJS Interop

The `default` import from a CommonJS (CJS) module is now handled in a consistent way.

If it matches one of the following conditions, the `default` import is the `module.exports` value of the importee CJS module. Otherwise, the `default` import is the `module.exports.default` value of the importee CJS module:

* The importer is `.mjs` or `.mts`.
* The closest `package.json` for the importer has a `type` field set to `module`.
* The `module.exports.__esModule` value of the importee CJS module is not set to true.

<Tip>
  See Rolldown's docs about this problem for more details: [Ambiguous `default` import from CJS modules - Bundling CJS | Rolldown](https://rolldown.rs/in-depth/bundling-cjs#ambiguous-default-import-from-cjs-modules).
</Tip>

<Warning>
  This change may break some existing code importing CJS modules. You can use the deprecated `legacy.inconsistentCjsInterop: true` option to temporarily restore the previous behavior. If you find a package that is affected by this change, please report it to the package author or send them a pull request. Make sure to link to the Rolldown documentation above so that the author can understand the context.
</Warning>

### Removed Module Resolution Using Format Sniffing

When both `browser` and `module` fields are present in `package.json`, Vite used to resolve the field based on the content of the file and it used to pick the ESM file for browsers. This was introduced because some packages were using the `module` field to point to ESM files for Node.js and some other packages were using the `browser` field to point to UMD files for browsers. Given that the modern `exports` field solved this problem and is now adopted by many packages, Vite no longer uses this heuristic and always respects the order of the [`resolve.mainFields`](/config/shared-options#resolve-mainfields) option. If you were relying on this behavior, you can use the [`resolve.alias`](/config/shared-options#resolve-alias) option to map the field to the desired file or apply a patch with your package manager (e.g. `patch-package`, `pnpm patch`).

### Require Calls For Externalized Modules

`require` calls for externalized modules are now preserved as `require` calls and not converted to `import` statements. This is to preserve the semantics of `require` calls. If you want to convert them to `import` statements, you can use [Rolldown's built-in `esmExternalRequirePlugin`](https://rolldown.rs/builtin-plugins/esm-external-require), which is re-exported from `vite`.

```js vite.config.js theme={null}
import { defineConfig, esmExternalRequirePlugin } from 'vite'

export default defineConfig({
  plugins: [
    esmExternalRequirePlugin({
      external: ['react', 'vue', /^node:/],
    }),
  ],
})
```

See Rolldown's docs for more details: [`require` external modules - Bundling CJS | Rolldown](https://rolldown.rs/in-depth/bundling-cjs#require-external-modules).

### `import.meta.url` in UMD / IIFE

`import.meta.url` is no longer polyfilled in UMD / IIFE output formats. It will be replaced with `undefined` by default. If you prefer the previous behavior, you can use the [`define`](/config/shared-options#define) option with [`build.rolldownOptions.output.intro`](https://rolldown.rs/reference/OutputOptions.intro) option. See Rolldown's docs for more details: [Well-known `import.meta` properties - Non ESM Output Formats | Rolldown](https://rolldown.rs/in-depth/non-esm-output-formats#well-known-import-meta-properties).

### Removed `build.rollupOptions.watch.chokidar` option

The `build.rollupOptions.watch.chokidar` option was removed. Please migrate to the [`build.rolldownOptions.watch.notify`](https://rolldown.rs/reference/InputOptions.watch#notify) option.

### Removed object form `build.rollupOptions.output.manualChunks`

The object form `output.manualChunks` option is not supported anymore. The function form `output.manualChunks` is deprecated. Rolldown has the more flexible [`codeSplitting`](https://rolldown.rs/reference/OutputOptions.codeSplitting) option. See Rolldown's docs for more details about `codeSplitting`: [Manual Code Splitting - Rolldown](https://rolldown.rs/in-depth/manual-code-splitting).

### Module Type Support and Auto Detection

<Note>
  This change only affects plugin authors.
</Note>

Rolldown has experimental support for [Module types](https://rolldown.rs/guide/notable-features#module-types), similar to [esbuild's `loader` option](https://esbuild.github.io/api/#loader). Due to this, Rolldown automatically sets a module type based on the extension of the resolved id. If you are converting content from other module types to JavaScript in `load` or `transform` hooks, you may need to add `moduleType: 'js'` to the returned value:

```js theme={null}
const plugin = {
  name: 'txt-loader',
  load(id) {
    if (id.endsWith('.txt')) {
      const content = fs.readFile(id, 'utf-8')
      return {
        code: `export default ${JSON.stringify(content)}`,
        moduleType: 'js', // [!code ++]
      }
    }
  },
}
```

### Other Related Deprecations

The following options are deprecated and will be removed in the future:

* `build.rollupOptions`: renamed to `build.rolldownOptions`
* `worker.rollupOptions`: renamed to `worker.rolldownOptions`
* `build.commonjsOptions`: it is now no-op
* `build.dynamicImportVarsOptions.warnOnError`: it is now no-op
* `resolve.alias[].customResolver`: Use a custom plugin with `resolveId` hook and `enforce: 'pre'` instead

## Removed Deprecated Features

* Passing an URL to `import.meta.hot.accept` is no longer supported. Please pass an id instead. ([#21382](https://github.com/vitejs/vite/pull/21382))

## Advanced

<Warning>
  These breaking changes are expected to only affect a minority of use cases.
</Warning>

<AccordionGroup>
  <Accordion title="Extglobs not supported yet">
    [Extglobs](https://github.com/micromatch/picomatch/blob/master/README.md#extglobs) are not supported yet ([rolldown-vite#365](https://github.com/vitejs/rolldown-vite/issues/365))
  </Accordion>

  <Accordion title="TypeScript legacy namespace partial support">
    TypeScript legacy namespace is only supported partially. See [Oxc Transformer's related documentation](https://oxc.rs/docs/guide/usage/transformer/typescript.html#partial-namespace-support) for more details.
  </Accordion>

  <Accordion title="define does not share reference for objects">
    `define` does not share reference for objects: When you pass an object as a value to `define`, each variable will have a separate copy of the object. See [Oxc Transformer's related documentation](https://oxc.rs/docs/guide/usage/transformer/global-variable-replacement#define) for more details.
  </Accordion>

  <Accordion title="bundle object changes">
    `bundle` object changes (`bundle` is an object passed in `generateBundle` / `writeBundle` hooks, returned by `build` function):

    * Assigning to `bundle[foo]` is not supported. This is discouraged by Rollup as well. Please use `this.emitFile()` instead.
    * The reference is not shared across the hooks ([rolldown-vite#410](https://github.com/vitejs/rolldown-vite/issues/410))
    * `structuredClone(bundle)` errors with `DataCloneError: #<Object> could not be cloned`. This is not supported anymore. Please clone it with `structuredClone({ ...bundle })`. ([rolldown-vite#128](https://github.com/vitejs/rolldown-vite/issues/128))
  </Accordion>

  <Accordion title="Parallel hooks work as sequential hooks">
    All parallel hooks in Rollup works as sequential hooks. See [Rolldown's documentation](https://rolldown.rs/apis/plugin-api#sequential-hook-execution) for more details.
  </Accordion>

  <Accordion title="use strict not injected sometimes">
    `"use strict";` is not injected sometimes. See [Rolldown's documentation](https://rolldown.rs/in-depth/directives) for more details.
  </Accordion>

  <Accordion title="plugin-legacy ES5 support">
    Transforming to lower than ES5 with plugin-legacy is not supported ([rolldown-vite#452](https://github.com/vitejs/rolldown-vite/issues/452))
  </Accordion>

  <Accordion title="Multiple browser versions error">
    Passing the same browser with multiple versions of it to `build.target` option now errors: esbuild selects the latest version of it, which was probably not what you intended.
  </Accordion>

  <Accordion title="Missing support by Rolldown">
    The following features are not supported by Rolldown and is no longer supported by Vite:

    * `build.rollupOptions.output.format: 'system'` ([rolldown#2387](https://github.com/rolldown/rolldown/issues/2387))
    * `build.rollupOptions.output.format: 'amd'` ([rolldown#2387](https://github.com/rolldown/rolldown/issues/2528))
    * `shouldTransformCachedModule` hook ([rolldown#4389](https://github.com/rolldown/rolldown/issues/4389))
    * `resolveImportMeta` hook ([rolldown#1010](https://github.com/rolldown/rolldown/issues/1010))
    * `renderDynamicImport` hook ([rolldown#4532](https://github.com/rolldown/rolldown/issues/4532))
    * `resolveFileUrl` hook
  </Accordion>

  <Accordion title="parseAst deprecated">
    `parseAst` / `parseAstAsync` functions are now deprecated in favor of `parseSync` / `parse` functions which have more features.
  </Accordion>

  <Accordion title="@vite-ignore comment edge case">
    (bug) `@vite-ignore` comment edge case ([rolldown-vite#426](https://github.com/vitejs/rolldown-vite/issues/426))
  </Accordion>
</AccordionGroup>

## Migration from v6

<Tip>
  Check the [Migration from v6 Guide](https://v7.vite.dev/guide/migration) in the Vite v7 docs first to see the needed changes to port your app to Vite 7, and then proceed with the changes on this page.
</Tip>
