2025 尤雨溪最新演讲：围绕 Vite 的前端统一工具链

我们拥有一个庞大且不断发展的生态系统。Vite 现在已经成为大多数框架构建单页应用（SPA）时的默认工具，并且驱动着几乎所有 JavaScript 元框架（除了 Next.js）。

基于 Vite 的框架现在正为世界上一些最知名的应用程序和网站提供支持，从 OpenAI 的 ChatGPT，到 Shopify、Reddit、保时捷、Linear 等等。

Vite 还与 Storybook 等工具以及 Laravel 等后端框架进行了一流的集成。在我看来，这种融合的意义在于，基于 Vite 构建的框架共享一个强大的互操作性故事——它们不仅可以避免在组装构建流程时重复造轮子，还可以共享插件、测试运行器，甚至部署适配器，从而使每个框架都能专注于真正重要的领域的创新。

去年说这话可能还有些为时过早，但如今，我认为可以肯定地说，Vite 已经成为了下一代 Web 应用的共享基建层。

我们之所以能够隐藏所有这些复杂性，要归功于 Vite 构建所依赖的底层工具：esbuild、Rollup 和 SWC。

• esbuild 用于依赖项的预打包、转换和压缩。

• Rollup 用于生产环境的打包，并且我们使用了一个与 Rollup 兼容的插件系统。

• SWC 默认情况下不是必需的，但是如果您正在构建一个 React 应用，并且希望获得比 Babel 更快的 React Refresh 转换，您应该使用基于 SWC 的 React 插件。在这种情况下，您实际上将通过 Vite 使用所有这三个依赖项。

至于 SWC——我们默认情况下不将其包含在转换中的原因之一是它庞大的二进制文件大小——它有 37MB，是 Vite 及其所有当前依赖项大小的两倍多。

虽然 SWC 拥有全面的转换功能和高质量的压缩器，但它并没有真正提供一个可用的打包器。

因此，我们不幸地陷入了这种多依赖的局面。

这导致的第一个问题是行为不一致：

esbuild 和 Rollup 在处理混合的 ESM/CJS 模块图时可能存在差异，有时这会导致一些细微的错误，这些错误只有在生产构建上线后才能被发现。这可不好。

对于 Oxc，我们已经完成了 Parser（解析器）、Linter（代码检查器）和 Resolver（解析器）。

对于 Transformer（转换器），我们已经完成了 TypeScript、JSX、React Refresh 转换以及 isolatedDeclarations DTS emit（隔离声明的 DTS 文件生成）。

我们目前的重点是通过语法降级转换来完成 Transformer。Minifier（压缩器）和 Formatter（格式化器）处于可工作的原型状态，将在 Transformer 完成后进行开发。

这是当前的 Vite，展示了即将推出的 v6 的架构。它仍然同时依赖 esbuild、Rollup 和 SWC。

这将是 Vite 的下一个迭代版本。它将由 Rolldown 和 Oxc 驱动，提高开发/生产环境的一致性，减少内部开销，并提高生产构建性能。

在更远的将来，我们可能会发布一个版本的 Vite，它将更多地依赖 Rolldown，并为开发环境、模块运行器和生产环境重用相同的打包能力。

这使我们能够摆脱未打包的网络瓶颈，确保所有环境之间的最大一致性，并在所有场景中提供最佳性能。