Vite 8 全面解析Rolldown 统一构建工具链、新增特性与迁移实践【免费下载链接】viteNext generation frontend tooling. Its fast!项目地址: https://gitcode.com/GitHub_Trending/vi/vite本文基于 Vite 官方博客的 Vite 8.0 发布公告docs/blog/announcing-vite8.md结合本仓库中 Vite 8 的实际源码与迁移文档系统讲解 Vite 8 最核心的架构变化——以 Rolldown 作为唯一 Rust 打包器取代 esbuild Rollup 双打包器体系——并覆盖 Node.js 支持范围、内置 Devtools、tsconfig paths、Wasm SSR、浏览器控制台转发等新增特性、安装体积变化以及面向普通项目与插件作者的完整迁移实践。从双打包器到 RolldownVite 8 的核心架构变化双打包器时代的背景与痛点Vite 诞生之初做了一个务实的技术押注开发阶段用 esbuild 做依赖预构建与 TypeScript/JSX 转换以获得即时感生产构建用 Rollup 做打包、分块与优化并借由其插件 API 撑起整个 Vite 插件生态。这一双打包器架构支撑了 Vite 多年发展让团队可以专注于开发体验与编排层而不必从零实现解析和打包。但代价也逐渐显现如公告所述两条独立的转换流水线意味着两套插件体系需要大量“胶水代码”保持两者同步围绕不一致的模块处理的边界情况随时间不断累积对其中一条流水线的任何对齐修复都有可能在另一条流水线引入新的差异。Vite 8 将这一体系收敛为单一打包器Rolldown一个 Rust 编写的打包器官方给出的定位是在保持完整插件兼容性的同时带来最高 10-30 倍更快的构建速度这是自 Vite 2 以来最重大的架构变化。Rolldown 的设计目标Rolldown 由 VoidZero 团队构建公告中明确了它的三个设计目标性能PerformanceRust 原生速度。在 Rolldown 的基准测试中比 Rollup 快 10-30 倍达到 esbuild 的性能水平。兼容性Compatibility支持 Rollup 与 Vite 相同的插件 API绝大多数现有 Vite 插件在 Vite 8 上开箱即用。高级特性Advanced features单一统一打包器解锁了双打包器架构下难以实现的能力包括全量打包模式full bundle mode、更灵活的 chunk 拆分、模块级持久化缓存以及 Module Federation 支持。在本仓库中可以印证这一“单一打包器”的事实packages/vite/package.json 中运行时依赖dependencies只有rolldown~1.2.6、lightningcss^1.33.0、postcss、picomatch、tinyglobby——esbuild 与 Rollup 均不再出现在运行时依赖中。Vite 自身的构建脚本也已切换到 Rolldown 构建build-bundle即rolldown --config rolldown.config.ts可以说 Vite 8 是“用 Rolldown 构建的 Vite”。从预览到稳定的路径Rolldown 迁移是一个刻意、由社区驱动的渐进过程独立预览包先以独立的rolldown-vite包作为技术预览发布让早期采用者在不影响稳定版 Vite 的前提下验证集成。这些用户的真实项目覆盖了各种形态与规模的代码库暴露了大量边界情况与兼容性问题。同时官方建立了专门的 CI 套件验证关键 Vite 插件与框架在新打包器下的表现尽早捕获回归。Vite 8 beta2025 年 12 月发布带完整 Rolldown 集成的 Vite 8 beta。beta 期间Rolldown 本身也从 beta 推进到 release candidate改进由 Vite 社区的测试与反馈持续驱动。稳定版2026 年 3 月 12 日正式发布 Vite 8.0。当前仓库中 packages/vite/CHANGELOG.md 显示版本已迭代至 8.2.22026-08-20后续修复大量集中在 bundled-dev全量打包模式、CSS/lightningcss、module-runner 等方向可见稳定后的持续打磨仍在快速进行。真实项目的构建提速在rolldown-vite预览与 beta 阶段多家企业报告了可量化的生产构建提速公告原文数据项目构建耗时变化Linear生产构建从 46s 降至 6sRamp构建时间减少 57%Mercedes-Benz.io最多减少 38%Beehiiv构建时间减少 64%对于大型项目这种收益尤为明显且官方预期随着 Rolldown 继续演进还会有进一步改善。统一工具链Vite Rolldown OxcVite 8 使 Vite 成为一个端到端工具链的入口由三个紧密协作的团队组成构建工具Vite、打包器Rolldown与编译器Oxc。公告指出这带来三方面收益一致行为从解析、解析模块到转换与压缩整个技术栈行为一致快速跟进语言规范JavaScript 演进而新出的规范能被迅速采纳跨层优化例如利用 Oxc 的语义分析能力改进 Rolldown 的 tree-shaking——这类在双打包器时代“够不着”的优化成为可能。一个直接的体现是Vite 7 中esbuild配置项承担的转换职责在 Vite 8 中由 Oxc 承接且官方做了配置映射——这一点在 packages/vite/src/node/config.ts 中可以清楚看到// 源码节选esbuild 配置自动转换为 Oxc 配置 let oxc: OxcOptions | false | undefined config.oxc if (config.esbuild) { if (config.oxc) { logger.warn( Both esbuild and oxc options were set. oxc options will be used and esbuild options will be ignored., ) } else { oxc convertEsbuildConfigToOxcConfig(config.esbuild, logger) } }即如果你仍在使用旧的esbuild选项Vite 8 会自动将其转换convertEsbuildConfigToOxcConfig为等价的 Oxc 配置同时设置两者时 Oxc 优先生效并给出警告。Node.js 支持Vite 8 要求Node.js 20.19 或 22.12与 Vite 7 的要求相同。公告解释了版本区间的用意确保 Node.js 支持无需 flag 的require(esm)从而允许 Vite 以 ESM-only 方式分发。这一点在仓库中得到确认packages/vite/package.json 中engines为node: ^20.19.0 || 22.12.0且包本身声明type: module。Vite 8 的其他重要特性除 Rolldown 集成外Vite 8 还有几个值得注意的新特性均可在官方文档中查到对应配置项内置 DevtoolsdevtoolsVite 8 内置了devtools配置项用于启用 Vite Devtools——一个用于调试与分析的开发工具可以直接从 dev server 中获得对 Vite 项目的更深入洞察。从依赖结构看packages/vite/package.json 中vitejs/devtools被列为可选 peer 依赖^0.4.0 || ^0.5.0安装后即可通过devtools: true启用。内置 tsconfigpaths支持将resolve.tsconfigPaths设为true后Vite 可以解析 TypeScript 路径别名tsconfig 中的paths。公告明确提示该特性有少量性能开销因此默认不启用。仓库中该配置在 packages/vite/src/node/nodeResolve.ts、packages/vite/src/node/plugins/resolve.ts 等多处参与解析逻辑。emitDecoratorMetadata支持Vite 8 内置了对 TypeScriptemitDecoratorMetadata选项的自动支持不再需要外部插件。细节见 Features 文档。Wasm SSR 支持.wasm?init导入 现在可以在 SSR 环境中使用将 Vite 的 WebAssembly 能力扩展到服务端渲染场景。仓库中 playground/ssr-wasm 目录即为该特性的端到端测试。浏览器控制台转发server.forwardConsoleVite 8 可以将浏览器控制台的日志与错误转发到 dev server 终端。公告特别指出它对“与编码 Agent 协作”的场景非常有用——客户端运行时错误会直接出现在 CLI 输出中。通过server.forwardConsole开启并且检测到编码 Agent 时会自动激活。源码实现位于 packages/vite/src/node/plugins/forwardConsole.ts该插件仅作用于serve阶段通过环境的热更新通道监听vite:forward-console事件按log/warn/error分级转发到终端对于error与unhandled-rejection还会结合源码映射source map解析出可读的堆栈与 code frame 再输出——这意味着终端里看到的错误位置可以直接对应到源代码文件。// 源码节选 environment.hot.on(vite:forward-console, (payload) { if (payload.type error || payload.type unhandled-rejection) { const output formatError(payload, environment, sourceMapCache) environment.config.logger.error(output, { timestamp: true }) } else { // 按 console.log/warn/error 级别转发 } })配套发布的 vitejs/plugin-react v6与 Vite 8 同步官方发布了vitejs/plugin-reactv6使用 Oxc 做 React Refresh 转换Babel 不再是该插件的依赖安装体积更小React Compiler 支持v6 提供了reactCompilerPreset辅助函数与rolldown/plugin-babel配合使用为需要 React Compiler 的项目提供显式的 opt-in 路径而不给默认配置增加负担。公告特别强调v5 版本仍然兼容 Vite 8因此可以先升级 Vite、再择机升级插件两条升级路径解耦。安装体积变化官方对安装体积的变化保持透明Vite 8 单独安装比 Vite 7 大约15 MB来源有两处约 10 MB 来自 lightningcss此前它是可选 peer 依赖现在成为普通依赖以便开箱即用地提供更好的 CSS 压缩。仓库中 packages/vite/package.json 的 dependencies 里确实列有lightningcss: ^1.33.0印证了这一点约 5 MB 来自 RolldownRolldown 二进制比 esbuild Rollup 之和更大主要是做了偏向速度而非二进制体积的性能优化。官方表示会继续监控并随 Rolldown 成熟而压缩安装体积。迁移到 Vite 8兼容性层配置自动转换对多数项目升级到 Vite 8 应当是平滑的。Vite 8 内置了兼容性层会自动将现有的esbuild与rollupOptions配置转换为 Rolldown 与 Oxc 的等价配置很多项目无需任何配置改动即可工作。仓库中两处源码可以直接印证esbuild→ Oxc 的自动转换见上文 config.tsworker.rollupOptions→worker.rolldownOptions的兼容处理config.ts 中 worker 选项解析会调用setupRollupOptionCompat当用户未设置rolldownOptions时用旧的rollupOptions填充。需要注意的一个行为变化esbuild: false不再能禁用默认转换转换现在由 Oxc 负责源码中对此有明确警告提示改用oxc: false// Vite 8 配置示例 export default { // 旧写法会收到警告 // esbuild: false // 正确写法禁用现在由 Oxc 承担的默认转换 oxc: false, }推荐的渐进迁移路径对较大或较复杂的项目公告推荐“两步走”的渐进式迁移先在 Vite 7 上把入口从vite切换到rolldown-vite包把 Rolldown 特有问题隔离出来确认无误后再升级到 Vite 8。这样能清晰区分问题究竟来自打包器变化还是来自 Vite 8 的其他改动。升级前请查阅完整的 Migration Guide完整变更清单见 Vite 8 Changelog。配置改名与不再支持的项速查结合 迁移文档以下要点值得在升级时逐一核对选项改名/弃用build.rollupOptions→ 更名为build.rolldownOptions旧名弃用worker.rollupOptions→ 更名为worker.rolldownOptions旧名弃用build.commonjsOptions变为 no-opbuild.dynamicImportVarsOptions.warnOnError变为 no-opresolve.alias[].customResolver移除改用带resolveId钩子和enforce: pre的自定义插件替代build.rollupOptions.watch.chokidar移除迁移到 Rolldown 的build.rolldownOptions.watch.watcher。API 行为变化build()现在抛出带类型的BundleErrorError { errors?: RolldownError[] }需要遍历e.errors获取单个错误try { await build() } catch (e) { if (e.errors) { for (const error of e.errors) { console.log(error.code) } } }向import.meta.hot.accept传 URL 不再支持请改传 id。高级/少数场景限制迁移文档“Advanced”部分主要影响插件作者与特定用法Extglobs 暂不支持TypeScript legacy namespace 仅部分支持define对对象值不再共享引用每个变量拿到独立副本generateBundle/writeBundle中bundle对象不再跨钩子共享引用、不支持bundle[foo] ...请用this.emitFile()Rollup 中的并行钩子在 Rolldown 中均按顺序钩子执行build.target同时传同一浏览器的多个版本会直接报错Rollup 时代 esbuild 会选最新版这通常不是预期行为Rolldown 缺失而因此不再支持的特性output.format: system/amd、shouldTransformCachedModule、resolveImportMeta、renderDynamicImport、resolveFileUrl等钩子parseAst/parseAstAsync弃用改用功能更强的parseSync/parseplugin-legacy 不支持转换到 ES5 及以下。面向插件作者Rolldown 会基于解析到的扩展名自动设置模块类型类似 esbuild 的loader如果你在load/transform钩子中把其他模块类型转换为 JavaScript需要在返回值中显式带上moduleType: js。未来方向公告列出了 Rolldown 集成打开的下一步方向Full Bundle Mode实验性开发阶段像生产构建一样打包模块。初步结果显示 dev server 启动快 3 倍、全量 reload 快 40%、网络请求减少 10 倍对模块数庞大、未打包开发模式触及扩展极限的大型项目收益尤其明显。仓库 Changelog 中大量bundled-dev相关条目正是该实验模式持续完善的体现。Raw AST transfer允许 JS 插件以最小序列化开销访问 Rust 生成的 AST弥合 Rust 内核与 JS 插件代码之间的性能差距。Native MagicString transforms转换逻辑写在 JavaScript但字符串操作计算在 Rust 侧运行。稳定 Environment API正在推进稳定化生态方已开始定期会议协作。致谢 Rollup 与 esbuildVite 8 是 sapphi-red 与 Vite 团队在广泛社区协作下完成的工作官方特别感谢 Rolldown 团队在合作中的贡献以及所有参与rolldown-vite预览与 Vite 8 beta 的开发者。同时官方向 Rollup 与 esbuild 表达了明确谢意Rollup 的插件 API 设计如此成功以至于 Rolldown 直接将其采纳为自己的 APIVite 整个插件生态建立在 Rollup 打下的基础之上esbuild 则从早期就为 Vite 提供了毫秒级的依赖预构建与 TS/JSX 转换证明了构建工具可以快几个数量级并为整个 Rust/Go 工具链世代立下了标杆。更多依赖项目与人物可以查看 Acknowledgements 页面参与贡献请参考 CONTRIBUTING。【免费下载链接】viteNext generation frontend tooling. Its fast!项目地址: https://gitcode.com/GitHub_Trending/vi/vite创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Vite 8 全面解析：Rolldown 统一构建工具链、新增特性与迁移实践
Vite 8 全面解析Rolldown 统一构建工具链、新增特性与迁移实践【免费下载链接】viteNext generation frontend tooling. Its fast!项目地址: https://gitcode.com/GitHub_Trending/vi/vite本文基于 Vite 官方博客的 Vite 8.0 发布公告docs/blog/announcing-vite8.md结合本仓库中 Vite 8 的实际源码与迁移文档系统讲解 Vite 8 最核心的架构变化——以 Rolldown 作为唯一 Rust 打包器取代 esbuild Rollup 双打包器体系——并覆盖 Node.js 支持范围、内置 Devtools、tsconfig paths、Wasm SSR、浏览器控制台转发等新增特性、安装体积变化以及面向普通项目与插件作者的完整迁移实践。从双打包器到 RolldownVite 8 的核心架构变化双打包器时代的背景与痛点Vite 诞生之初做了一个务实的技术押注开发阶段用 esbuild 做依赖预构建与 TypeScript/JSX 转换以获得即时感生产构建用 Rollup 做打包、分块与优化并借由其插件 API 撑起整个 Vite 插件生态。这一双打包器架构支撑了 Vite 多年发展让团队可以专注于开发体验与编排层而不必从零实现解析和打包。但代价也逐渐显现如公告所述两条独立的转换流水线意味着两套插件体系需要大量“胶水代码”保持两者同步围绕不一致的模块处理的边界情况随时间不断累积对其中一条流水线的任何对齐修复都有可能在另一条流水线引入新的差异。Vite 8 将这一体系收敛为单一打包器Rolldown一个 Rust 编写的打包器官方给出的定位是在保持完整插件兼容性的同时带来最高 10-30 倍更快的构建速度这是自 Vite 2 以来最重大的架构变化。Rolldown 的设计目标Rolldown 由 VoidZero 团队构建公告中明确了它的三个设计目标性能PerformanceRust 原生速度。在 Rolldown 的基准测试中比 Rollup 快 10-30 倍达到 esbuild 的性能水平。兼容性Compatibility支持 Rollup 与 Vite 相同的插件 API绝大多数现有 Vite 插件在 Vite 8 上开箱即用。高级特性Advanced features单一统一打包器解锁了双打包器架构下难以实现的能力包括全量打包模式full bundle mode、更灵活的 chunk 拆分、模块级持久化缓存以及 Module Federation 支持。在本仓库中可以印证这一“单一打包器”的事实packages/vite/package.json 中运行时依赖dependencies只有rolldown~1.2.6、lightningcss^1.33.0、postcss、picomatch、tinyglobby——esbuild 与 Rollup 均不再出现在运行时依赖中。Vite 自身的构建脚本也已切换到 Rolldown 构建build-bundle即rolldown --config rolldown.config.ts可以说 Vite 8 是“用 Rolldown 构建的 Vite”。从预览到稳定的路径Rolldown 迁移是一个刻意、由社区驱动的渐进过程独立预览包先以独立的rolldown-vite包作为技术预览发布让早期采用者在不影响稳定版 Vite 的前提下验证集成。这些用户的真实项目覆盖了各种形态与规模的代码库暴露了大量边界情况与兼容性问题。同时官方建立了专门的 CI 套件验证关键 Vite 插件与框架在新打包器下的表现尽早捕获回归。Vite 8 beta2025 年 12 月发布带完整 Rolldown 集成的 Vite 8 beta。beta 期间Rolldown 本身也从 beta 推进到 release candidate改进由 Vite 社区的测试与反馈持续驱动。稳定版2026 年 3 月 12 日正式发布 Vite 8.0。当前仓库中 packages/vite/CHANGELOG.md 显示版本已迭代至 8.2.22026-08-20后续修复大量集中在 bundled-dev全量打包模式、CSS/lightningcss、module-runner 等方向可见稳定后的持续打磨仍在快速进行。真实项目的构建提速在rolldown-vite预览与 beta 阶段多家企业报告了可量化的生产构建提速公告原文数据项目构建耗时变化Linear生产构建从 46s 降至 6sRamp构建时间减少 57%Mercedes-Benz.io最多减少 38%Beehiiv构建时间减少 64%对于大型项目这种收益尤为明显且官方预期随着 Rolldown 继续演进还会有进一步改善。统一工具链Vite Rolldown OxcVite 8 使 Vite 成为一个端到端工具链的入口由三个紧密协作的团队组成构建工具Vite、打包器Rolldown与编译器Oxc。公告指出这带来三方面收益一致行为从解析、解析模块到转换与压缩整个技术栈行为一致快速跟进语言规范JavaScript 演进而新出的规范能被迅速采纳跨层优化例如利用 Oxc 的语义分析能力改进 Rolldown 的 tree-shaking——这类在双打包器时代“够不着”的优化成为可能。一个直接的体现是Vite 7 中esbuild配置项承担的转换职责在 Vite 8 中由 Oxc 承接且官方做了配置映射——这一点在 packages/vite/src/node/config.ts 中可以清楚看到// 源码节选esbuild 配置自动转换为 Oxc 配置 let oxc: OxcOptions | false | undefined config.oxc if (config.esbuild) { if (config.oxc) { logger.warn( Both esbuild and oxc options were set. oxc options will be used and esbuild options will be ignored., ) } else { oxc convertEsbuildConfigToOxcConfig(config.esbuild, logger) } }即如果你仍在使用旧的esbuild选项Vite 8 会自动将其转换convertEsbuildConfigToOxcConfig为等价的 Oxc 配置同时设置两者时 Oxc 优先生效并给出警告。Node.js 支持Vite 8 要求Node.js 20.19 或 22.12与 Vite 7 的要求相同。公告解释了版本区间的用意确保 Node.js 支持无需 flag 的require(esm)从而允许 Vite 以 ESM-only 方式分发。这一点在仓库中得到确认packages/vite/package.json 中engines为node: ^20.19.0 || 22.12.0且包本身声明type: module。Vite 8 的其他重要特性除 Rolldown 集成外Vite 8 还有几个值得注意的新特性均可在官方文档中查到对应配置项内置 DevtoolsdevtoolsVite 8 内置了devtools配置项用于启用 Vite Devtools——一个用于调试与分析的开发工具可以直接从 dev server 中获得对 Vite 项目的更深入洞察。从依赖结构看packages/vite/package.json 中vitejs/devtools被列为可选 peer 依赖^0.4.0 || ^0.5.0安装后即可通过devtools: true启用。内置 tsconfigpaths支持将resolve.tsconfigPaths设为true后Vite 可以解析 TypeScript 路径别名tsconfig 中的paths。公告明确提示该特性有少量性能开销因此默认不启用。仓库中该配置在 packages/vite/src/node/nodeResolve.ts、packages/vite/src/node/plugins/resolve.ts 等多处参与解析逻辑。emitDecoratorMetadata支持Vite 8 内置了对 TypeScriptemitDecoratorMetadata选项的自动支持不再需要外部插件。细节见 Features 文档。Wasm SSR 支持.wasm?init导入 现在可以在 SSR 环境中使用将 Vite 的 WebAssembly 能力扩展到服务端渲染场景。仓库中 playground/ssr-wasm 目录即为该特性的端到端测试。浏览器控制台转发server.forwardConsoleVite 8 可以将浏览器控制台的日志与错误转发到 dev server 终端。公告特别指出它对“与编码 Agent 协作”的场景非常有用——客户端运行时错误会直接出现在 CLI 输出中。通过server.forwardConsole开启并且检测到编码 Agent 时会自动激活。源码实现位于 packages/vite/src/node/plugins/forwardConsole.ts该插件仅作用于serve阶段通过环境的热更新通道监听vite:forward-console事件按log/warn/error分级转发到终端对于error与unhandled-rejection还会结合源码映射source map解析出可读的堆栈与 code frame 再输出——这意味着终端里看到的错误位置可以直接对应到源代码文件。// 源码节选 environment.hot.on(vite:forward-console, (payload) { if (payload.type error || payload.type unhandled-rejection) { const output formatError(payload, environment, sourceMapCache) environment.config.logger.error(output, { timestamp: true }) } else { // 按 console.log/warn/error 级别转发 } })配套发布的 vitejs/plugin-react v6与 Vite 8 同步官方发布了vitejs/plugin-reactv6使用 Oxc 做 React Refresh 转换Babel 不再是该插件的依赖安装体积更小React Compiler 支持v6 提供了reactCompilerPreset辅助函数与rolldown/plugin-babel配合使用为需要 React Compiler 的项目提供显式的 opt-in 路径而不给默认配置增加负担。公告特别强调v5 版本仍然兼容 Vite 8因此可以先升级 Vite、再择机升级插件两条升级路径解耦。安装体积变化官方对安装体积的变化保持透明Vite 8 单独安装比 Vite 7 大约15 MB来源有两处约 10 MB 来自 lightningcss此前它是可选 peer 依赖现在成为普通依赖以便开箱即用地提供更好的 CSS 压缩。仓库中 packages/vite/package.json 的 dependencies 里确实列有lightningcss: ^1.33.0印证了这一点约 5 MB 来自 RolldownRolldown 二进制比 esbuild Rollup 之和更大主要是做了偏向速度而非二进制体积的性能优化。官方表示会继续监控并随 Rolldown 成熟而压缩安装体积。迁移到 Vite 8兼容性层配置自动转换对多数项目升级到 Vite 8 应当是平滑的。Vite 8 内置了兼容性层会自动将现有的esbuild与rollupOptions配置转换为 Rolldown 与 Oxc 的等价配置很多项目无需任何配置改动即可工作。仓库中两处源码可以直接印证esbuild→ Oxc 的自动转换见上文 config.tsworker.rollupOptions→worker.rolldownOptions的兼容处理config.ts 中 worker 选项解析会调用setupRollupOptionCompat当用户未设置rolldownOptions时用旧的rollupOptions填充。需要注意的一个行为变化esbuild: false不再能禁用默认转换转换现在由 Oxc 负责源码中对此有明确警告提示改用oxc: false// Vite 8 配置示例 export default { // 旧写法会收到警告 // esbuild: false // 正确写法禁用现在由 Oxc 承担的默认转换 oxc: false, }推荐的渐进迁移路径对较大或较复杂的项目公告推荐“两步走”的渐进式迁移先在 Vite 7 上把入口从vite切换到rolldown-vite包把 Rolldown 特有问题隔离出来确认无误后再升级到 Vite 8。这样能清晰区分问题究竟来自打包器变化还是来自 Vite 8 的其他改动。升级前请查阅完整的 Migration Guide完整变更清单见 Vite 8 Changelog。配置改名与不再支持的项速查结合 迁移文档以下要点值得在升级时逐一核对选项改名/弃用build.rollupOptions→ 更名为build.rolldownOptions旧名弃用worker.rollupOptions→ 更名为worker.rolldownOptions旧名弃用build.commonjsOptions变为 no-opbuild.dynamicImportVarsOptions.warnOnError变为 no-opresolve.alias[].customResolver移除改用带resolveId钩子和enforce: pre的自定义插件替代build.rollupOptions.watch.chokidar移除迁移到 Rolldown 的build.rolldownOptions.watch.watcher。API 行为变化build()现在抛出带类型的BundleErrorError { errors?: RolldownError[] }需要遍历e.errors获取单个错误try { await build() } catch (e) { if (e.errors) { for (const error of e.errors) { console.log(error.code) } } }向import.meta.hot.accept传 URL 不再支持请改传 id。高级/少数场景限制迁移文档“Advanced”部分主要影响插件作者与特定用法Extglobs 暂不支持TypeScript legacy namespace 仅部分支持define对对象值不再共享引用每个变量拿到独立副本generateBundle/writeBundle中bundle对象不再跨钩子共享引用、不支持bundle[foo] ...请用this.emitFile()Rollup 中的并行钩子在 Rolldown 中均按顺序钩子执行build.target同时传同一浏览器的多个版本会直接报错Rollup 时代 esbuild 会选最新版这通常不是预期行为Rolldown 缺失而因此不再支持的特性output.format: system/amd、shouldTransformCachedModule、resolveImportMeta、renderDynamicImport、resolveFileUrl等钩子parseAst/parseAstAsync弃用改用功能更强的parseSync/parseplugin-legacy 不支持转换到 ES5 及以下。面向插件作者Rolldown 会基于解析到的扩展名自动设置模块类型类似 esbuild 的loader如果你在load/transform钩子中把其他模块类型转换为 JavaScript需要在返回值中显式带上moduleType: js。未来方向公告列出了 Rolldown 集成打开的下一步方向Full Bundle Mode实验性开发阶段像生产构建一样打包模块。初步结果显示 dev server 启动快 3 倍、全量 reload 快 40%、网络请求减少 10 倍对模块数庞大、未打包开发模式触及扩展极限的大型项目收益尤其明显。仓库 Changelog 中大量bundled-dev相关条目正是该实验模式持续完善的体现。Raw AST transfer允许 JS 插件以最小序列化开销访问 Rust 生成的 AST弥合 Rust 内核与 JS 插件代码之间的性能差距。Native MagicString transforms转换逻辑写在 JavaScript但字符串操作计算在 Rust 侧运行。稳定 Environment API正在推进稳定化生态方已开始定期会议协作。致谢 Rollup 与 esbuildVite 8 是 sapphi-red 与 Vite 团队在广泛社区协作下完成的工作官方特别感谢 Rolldown 团队在合作中的贡献以及所有参与rolldown-vite预览与 Vite 8 beta 的开发者。同时官方向 Rollup 与 esbuild 表达了明确谢意Rollup 的插件 API 设计如此成功以至于 Rolldown 直接将其采纳为自己的 APIVite 整个插件生态建立在 Rollup 打下的基础之上esbuild 则从早期就为 Vite 提供了毫秒级的依赖预构建与 TS/JSX 转换证明了构建工具可以快几个数量级并为整个 Rust/Go 工具链世代立下了标杆。更多依赖项目与人物可以查看 Acknowledgements 页面参与贡献请参考 CONTRIBUTING。【免费下载链接】viteNext generation frontend tooling. Its fast!项目地址: https://gitcode.com/GitHub_Trending/vi/vite创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考