Migración de v7
Si estás migrando desde rolldown-vite, la versión de vista técnica para Vite integrado con Rolldown para v6 & v7, solo las secciones con NRV en el título son aplicables.
Cambio en los Navegadores de Destino Predeterminados NRV
El valor de los navegadores predeterminados de build.target y 'baseline-widely-available' se actualiza a versiones más recientes del navegador:
- Chrome 107 → 111
- Edge 107 → 111
- Firefox 104 → 114
- Safari 16.0 → 16.4
Estas versiones de navegador se alinean con los conjuntos de características Baseline Widely Available a partir de 2026-01-01. En otras palabras, fueron lanzadas hace aproximadamente dos años y medio.
Rolldown
Vite 8 utiliza Rolldown y herramientas basadas en Oxc en lugar de esbuild y Rollup.
Migración Gradual
El paquete rolldown-vite implementa Vite 7 con Rolldown, sin otros cambios de Vite 8. Esto puede ser utilizado como un paso intermedio para migrar a Vite 8. Véase la guía de integración de Rolldown en los documentos de Vite 7 para cambiar a rolldown-vite desde Vite 7.
Para los usuarios que migran de rolldown-vite a Vite 8, puedes deshacer los cambios de dependencia en package.json y actualizar a Vite 8:
{
"devDependencies": {
"vite": "npm:rolldown-vite@7.2.2"
"vite": "^8.0.0"
}
}El optimizador de dependencias ahora usa Rolldown
Rolldown ahora se utiliza para la optimización de dependencias en lugar de esbuild. Vite todavía soporta optimizeDeps.esbuildOptions para compatibilidad con versiones anteriores, convirtiéndolo automáticamente a optimizeDeps.rolldownOptions. optimizeDeps.esbuildOptions ahora está obsoleto y se eliminará en el futuro, y te animamos a migrar a optimizeDeps.rolldownOptions.
Las siguientes opciones se convierten automáticamente:
esbuildOptions.minify->rolldownOptions.output.minifyesbuildOptions.treeShaking->rolldownOptions.treeshakeesbuildOptions.define->rolldownOptions.transform.defineesbuildOptions.loader->rolldownOptions.moduleTypesesbuildOptions.preserveSymlinks->!rolldownOptions.resolve.symlinksesbuildOptions.resolveExtensions->rolldownOptions.resolve.extensionsesbuildOptions.mainFields->rolldownOptions.resolve.mainFieldsesbuildOptions.conditions->rolldownOptions.resolve.conditionNamesesbuildOptions.keepNames->rolldownOptions.output.keepNamesesbuildOptions.platform->rolldownOptions.platformesbuildOptions.plugins->rolldownOptions.plugins(soporte parcial)
Puedes obtener las opciones establecidas por la capa de compatibilidad desde el hook configResolved:
const plugin = {
name: 'log-config',
configResolved(config) {
console.log('options', config.optimizeDeps.rolldownOptions)
},
},Transformaciones de JavaScript por Oxc
Oxc ahora se utiliza para la transformación de JavaScript en lugar de esbuild. Vite todavía soporta la opción esbuild para compatibilidad con versiones anteriores, convirtiéndola automáticamente a oxc. esbuild ahora está obsoleto y se eliminará en el futuro, por lo que te animamos a migrar a oxc.
Las siguientes opciones se convierten automáticamente:
esbuild.jsxInject->oxc.jsxInjectesbuild.include->oxc.includeesbuild.exclude->oxc.excludeesbuild.jsx->oxc.jsxesbuild.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.pragmaesbuild.jsxFragment->oxc.jsx.pragmaFrag
esbuild.jsxDev->oxc.jsx.developmentesbuild.jsxSideEffects->oxc.jsx.pure
esbuild.define->oxc.defineesbuild.banner-> plugin personalizado usando el hook transformesbuild.footer-> plugin personalizado usando el hook transform
La opción esbuild.supported no es soportada por Oxc. Si necesitas esta opción, por favor consulta oxc-project/oxc#15373.
Puedes obtener las opciones establecidas por la capa de compatibilidad desde el hook configResolved:
const plugin = {
name: 'log-config',
configResolved(config) {
console.log('options', config.oxc)
},
},Actualmente, el transformador Oxc no admite la reducción de decoradores nativos mientras esperamos que la especificación avance, vea (oxc-project/oxc#9170).
Solución alternativa para reducir decoradores nativos
Puedes usar Babel o SWC para reducir decoradores nativos por el momento. Aunque SWC es más rápido que Babel, no soporta la última especificación de decoradores que esbuild admite.
La especificación de decoradores se ha actualizado varias veces desde que alcanzó la etapa 3. Las versiones admitidas por cada herramienta son:
"2023-11"(esbuild, TypeScript 5.4+ y Babel soportan esta versión)"2023-05"(TypeScript 5.2+ admite esta versión)"2023-01"(TypeScript 5.0+ admite esta versión)"2022-03"(SWC admite esta versión)
Ve a la guía de versiones de decoradores de Babel para ver las diferencias entre cada versión.
Usando Babel:
$ npm install -D @rollup/plugin-babel @babel/plugin-proposal-decorators$ yarn add -D @rollup/plugin-babel @babel/plugin-proposal-decorators$ pnpm add -D @rollup/plugin-babel @babel/plugin-proposal-decorators$ bun add -D @rollup/plugin-babel @babel/plugin-proposal-decorators$ deno add -D npm:@rollup/plugin-babel npm:@babel/plugin-proposal-decoratorsimport { defineConfig, withFilter } from 'vite'
import { babel } from '@rollup/plugin-babel'
export default defineConfig({
plugins: [
withFilter(
babel({
configFile: false,
plugins: [
['@babel/plugin-proposal-decorators', { version: '2023-11' }],
],
}),
// Ejecuta esta transformación solo si el archivo contiene un decorador.
{ transform: { code: '@' } },
),
],
})Usando SWC:
$ npm install -D @rollup/plugin-swc @swc/core$ yarn add -D @rollup/plugin-swc @swc/core$ pnpm add -D @rollup/plugin-swc @swc/core$ bun add -D @rollup/plugin-swc @swc/core$ deno add -D npm:@rollup/plugin-swc npm:@swc/coreimport { defineConfig, withFilter } from 'vite'
export default defineConfig({
// ...
plugins: [
withFilter(
swc({
swc: {
jsc: {
parser: { decorators: true, decoratorsBeforeExport: true },
// NOTA: SWC no soporta la versión '2023-11' todavía.
transform: { decoratorVersion: '2022-03' },
},
},
}),
// Ejecuta esta transformación solo si el archivo contiene un decorador.
{ transform: { code: '@' } },
),
],
})Alternativas a esbuild
esbuild ya no es utilizado directamente por Vite y ahora es una dependencia opcional. Si estás usando un plugin que utiliza la función transformWithEsbuild, necesitas instalar esbuild como una devDependency. La función transformWithEsbuild está obsoleta y será eliminada en el futuro. Recomendamos migrar a la nueva función transformWithOxc.
Minificación de JavaScript por Oxc
El Minificador de Oxc ahora se utiliza para la minificación de JavaScript en lugar de esbuild. Puedes usar la opción obsoleta build.minify: 'esbuild' para volver a esbuild. Esta opción de configuración será eliminada en el futuro y necesitas instalar esbuild como una devDependency ya que Vite ya no depende directamente de esbuild.
Si estabas usando las opciones esbuild.minify* para controlar el comportamiento de la minificación, ahora puedes usar build.rolldownOptions.output.minify en su lugar. Si estabas usando la opción esbuild.drop, ahora puedes usar las opciones build.rolldownOptions.output.minify.compress.drop*.
El obfuscado de propiedades y sus opciones relacionadas (mangleProps, reserveProps, mangleQuoted, mangleCache) no son compatibles con Oxc. Si necesitas estas opciones, consulta oxc-project/oxc#15375.
esbuild y el Minificador de Oxc hacen suposiciones ligeramente diferentes sobre el código fuente. En caso de que sospeches que el minificador está causando problemas en tu código, puedes comparar estas suposiciones aquí:
Por favor, informa cualquier problema que encuentres relacionado con la minificación en tus aplicaciones JavaScript.
Minificación de CSS con Lightning CSS
Lightning CSS ahora se utiliza para la minificación de CSS por defecto. Puedes usar la opción build.cssMinify: 'esbuild' para volver a esbuild. Ten en cuenta que necesitas instalar esbuild como una devDependency.
Lightning CSS admite una mejor sintaxis de lowering y el tamaño de tu paquete CSS podría aumentar ligeramente.
Interoperabilidad consistente de CommonJS
La importación default de un módulo CommonJS (CJS) ahora se maneja de manera consistente.
Si coincide con una de las siguientes condiciones, la importación default es el valor module.exports del módulo CJS importado. De lo contrario, la importación default es el valor module.exports.default del módulo CJS importado:
- El importador es
.mjso.mts. - El
package.jsonmás cercano para el importador tiene un campotypeestablecido enmodule. - El valor
module.exports.__esModuledel módulo CJS importado no está establecido en true.
El comportamiento anterior
En desarrollo, si coincidía con una de las siguientes condiciones, la importación default era el valor module.exports del módulo CJS importado. De lo contrario, la importación default era el valor module.exports.default del módulo CJS importado:
- El importador está incluido en la optimización de dependencias y
.mjso.mts. - El importador está incluido en la optimización de dependencias y el
package.jsonmás cercano para el importador tiene un campotypeestablecido enmodule. - El valor
module.exports.__esModuledel módulo CJS importado no está establecido en true.
En build, las condiciones eran:
- El valor
module.exports.__esModuledel módulo CJS importado no está establecido en true. - La propiedad
defaultdemodule.exportsno existe.
(asumiendo que build.commonjsOptions.defaultIsModuleExports no se ha cambiado del valor predeterminado 'auto')
Consulta la documentación de Rolldown sobre este problema para obtener más detalles: Importación default ambigua de módulos CJS - Bundling CJS | Rolldown.
Este cambio puede romper algún código existente que importe módulos CJS. Puedes usar la opción obsoleta legacy.inconsistentCjsInterop: true para restaurar temporalmente el comportamiento anterior. Si encuentras un paquete que se ve afectado por este cambio, por favor infórmalo al autor del paquete o envíale un pull request. Asegúrate de enlazar al documento de Rolldown anterior para que el autor pueda entender el contexto.
Eliminación de la Resolución de Módulos Utilizando la Inferencia de Formato
Cuando tanto los campos browser como module están presentes en package.json, Vite solía resolver el campo basándose en el contenido del archivo y solía elegir el archivo ESM para los navegadores. Esto se introdujo porque algunos paquetes estaban usando el campo module para apuntar a archivos ESM para Node.js y otros paquetes estaban usando el campo browser para apuntar a archivos UMD para navegadores. Dado que el campo moderno exports solucionó este problema y ahora es adoptado por muchos paquetes, Vite ya no usa esta heurística y siempre respeta el orden de la opción resolve.mainFields. Si estabas confiando en este comportamiento, puedes usar la opción resolve.alias para mapear el campo al archivo deseado o aplicar un parche con tu gestor de paquetes (ej. patch-package, pnpm patch).
Llamadas Require Para Módulos Externalizados
Las llamadas require para módulos externalizados ahora se preservan como llamadas require y no se convierten en declaraciones import. Esto es para preservar la semántica de las llamadas require. Si quieres convertirlas en declaraciones import, puedes usar el plugin incorporado de Rolldown esmExternalRequirePlugin, que se reexporta desde vite.
import { defineConfig, esmExternalRequirePlugin } from 'vite'
export default defineConfig({
// ...
plugins: [
esmExternalRequirePlugin({
external: ['react', 'vue', /^node:/],
}),
],
})Consulta la documentación de Rolldown para obtener más detalles: require módulos externos - Bundling CJS | Rolldown.
import.meta.url en UMD / IIFE
import.meta.url ya no se polifiliza en los formatos de salida UMD / IIFE. Se reemplazará con undefined por defecto. Si prefieres el comportamiento anterior, puedes usar la opción define con la opción build.rolldownOptions.output.intro. Consulta la documentación de Rolldown para más detalles: Propiedades import.meta conocidas - Formatos de salida no ESM | Rolldown.
Eliminación de la opción build.rollupOptions.watch.chokidar
La opción build.rollupOptions.watch.chokidar se eliminó. Por favor, migra a la opción build.rolldownOptions.watch.notify.
Deprecación de build.rollupOptions.output.manualChunks
La opción build.rollupOptions.output.manualChunks se ha desechado. Rolldown tiene la opción advancedChunks más flexible. Consulta la documentación de Rolldown para más detalles sobre advancedChunks: Advanced Chunks - Rolldown.
Soporte y Detección Automática de Tipos de Módulo
Este cambio solo afecta a los autores de plugins.
Rolldown tiene soporte experimental para Tipos de módulo, similar a la opción loader de esbuild. Debido a esto, Rolldown establece automáticamente un tipo de módulo basado en la extensión del id resuelto. Si estás convirtiendo contenido de otros tipos de módulo a JavaScript en los hooks load o transform, es posible que necesites agregar moduleType: 'js' al valor devuelto:
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',
}
}
},
}Otras Deprecaciones Relacionadas
Las siguientes opciones están obsoletas y se eliminarán en el futuro:
build.rollupOptions: renombrado abuild.rolldownOptionsworker.rollupOptions: renombrado aworker.rolldownOptionsbuild.commonjsOptions: ahora es una operación no operativa
Cambios Generales NRV
Características obsoletas eliminadas NRV
POR HACER: Este cambio aún no está implementado, pero se implementará antes de la versión estable.
Avanzado
Estos cambios rotóricos se espera que afecten solo a una minoría de casos de uso:
- [POR HACER: esto se corregirá antes de la versión estable] https://github.com/rolldown/rolldown/issues/5726 (afecta a nuxt, qwik)
- [POR HACER: esto se corregirá antes de la versión estable] https://github.com/rolldown/rolldown/issues/3403 (afecta a sveltekit)
- [POR HACER: esto se corregirá antes de la versión estable] Los fragmentos heredados se emiten como un archivo de activo en lugar de un archivo de fragmento debido a la falta de la función de emisión de fragmento preconstruido (rolldown#4304). Esto significa que las opciones relacionadas con los fragmentos no se aplican a los fragmentos heredados y el archivo de manifiesto no incluirá los fragmentos heredados como un archivo de fragmento.
- [POR HACER: esto se corregirá antes de la versión estable] La memoria caché del resolutor rompe casos menores en Vitest (rolldown-vite#466, vitest#8754)
- [POR HACER: esto se corregirá antes de la versión estable] El resolutor no funciona con yarn pnp (rolldown-vite#324, rolldown-vite#392)
- [POR HACER: esto se corregirá antes de la versión estable] Problema de ordenamiento de plugins nativos (rolldown-vite#373)
- [POR HACER: esto se corregirá antes de la versión estable] Caso límite del comentario
@vite-ignore(rolldown-vite#426) - [POR HACER: esto se corregirá antes de la versión estable] https://github.com/rolldown/rolldown/issues/3403
- Extglobs aún no son compatibles (rolldown-vite#365)
defineno comparte referencias para objetos: Cuando pasas un objeto como valor adefine, cada variable tendrá una copia separada del objeto. Consulta el documento del Transformador Oxc para más detalles.- Cambios en el objeto
bundle(bundlees un objeto pasado en los hooksgenerateBundle/writeBundle, devuelto por la funciónbuild):- Asignar a
bundle[foo]no es compatible. Rollup tampoco recomienda esto. Por favor, usathis.emitFile()en su lugar. - La referencia no se comparte entre los hooks (rolldown-vite#410)
structuredClone(bundle)produce errores conDataCloneError: #<Object> no se pudo clonar. Esto ya no es compatible. Por favor, clónalo constructuredClone({ ...bundle }). (rolldown-vite#128)
- Asignar a
- Todos los hooks paralelos en Rollup funcionan como hooks secuenciales. Consulta la documentación de Rolldown para más detalles.
"use strict";no se inyecta a veces. Consulta la documentación de Rolldown para más detalles.- La transformación a ES5 inferior con plugin-legacy no es compatible (rolldown-vite#452)
- Pasar el mismo navegador con múltiples versiones a la opción
build.targetahora produce un error: esbuild selecciona la última versión de este, lo que probablemente no era lo que pretendías. - Falta de compatibilidad por parte de Rolldown: Las siguientes características no son compatibles con Rolldown y ya no son compatibles con Vite.
build.rollupOptions.output.format: 'system'(rolldown#2387)build.rollupOptions.output.format: 'amd'(rolldown#2387)- Compatibilidad completa con el espacio de nombres heredado de TypeScript (oxc-project/oxc#14227)
- Hook
shouldTransformCachedModule(rolldown#4389) - Hook
resolveImportMeta(rolldown#1010) - Hook
renderDynamicImport(rolldown#4532) - Hook
resolveFileUrl
- Las funciones
parseAst/parseAstAsyncahora están obsoletas en favor de las funcionesparseSync/parseque tienen más características.
Migración desde v6
Ver el Guía de Migración desde v6 para ver los cambios necesarios para portar tu aplicación a Vite 7, y luego proceder con los cambios en esta página.