Migration from v7 | Vite

Dependency Pre-Bundling
Static Asset Handling
Building for Production
Deploying a Static Site
Env Variables and Modes
Server-Side Rendering (SSR)
Environment Instances
If you are migrating from rolldown-vite, the technical preview release for Rolldown integrated Vite for v6 & v7, only the sections with NRV in the title are applicable.
The default browser values of build.target and 'baseline-widely-available' are updated to newer browser versions:
These browser versions align with Baseline Widely Available feature sets as of 2026-01-01. In other words, they were all released about two and a half years ago.
Vite 8 uses Rolldown and Oxc based tools instead of esbuild and Rollup.
The rolldown-vite package implements Vite 7 with Rolldown, without other Vite 8 changes. This can be used as an intermediate step to migrate to Vite 8. See the Rolldown Integration guide in the Vite 7 docs to switch to rolldown-vite from Vite 7.
For users migrating from rolldown-vite to Vite 8, you can undo the dependency changes in package.json and update to Vite 8:
Rolldown is now used for dependency optimization instead of esbuild. Vite still supports optimizeDeps.esbuildOptions for backward compatibility by converting it to optimizeDeps.rolldownOptions automatically. optimizeDeps.esbuildOptions is now deprecated and will be removed in the future and we encourage you to migrate to optimizeDeps.rolldownOptions.
The following options are converted automatically:
You can get the options set by the compatibility layer from the configResolved hook:
Oxc is now used for JavaScript transformation instead of esbuild. Vite still supports the esbuild option for backward compatibility by converting it to oxc automatically. esbuild is now deprecated and will be removed in the future and we encourage you to migrate to oxc.
The following options are converted automatically:
The esbuild.supported option is not supported by Oxc. If you need this option, please see oxc-project/oxc#15373.
You can get the options set by the compatibility layer from the configResolved hook:
Currently, the Oxc transformer does not support lowering native decorators as we are waiting for the specification to progress, see (oxc-project/oxc#9170).
You can use Babel or SWC to lower native decorators for the time being.
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.
The Oxc Minifier is now used for JavaScript minification instead of esbuild. You can use the deprecated build.minify: 'esbuild' 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.
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.
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:
Please report any issues you find related to minification in your JavaScript apps.
Lightning CSS is now used for CSS minification by default. You can use the build.cssMinify: 'esbuild' 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.
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:
In development, 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:
In build, the conditions were:
(assuming build.commonjsOptions.defaultIsModuleExports is not changed from the default 'auto')
See Rolldown's docs about this problem for more details: Ambiguous default import from CJS modules - Bundling CJS | Rolldown.
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.
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 option. If you were relying on this behavior, you can use the 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 are now preserved as require calls and not converted to import sta