双引擎架构：Vite 是如何站在巨人的肩膀上实现的？

所谓的 巨人 ，指的就是 Vite 底层所深度使用的两个构建引擎—— Esbuild 和 Rollup 。

Vite 架构图

很多人对 Vite 的双引擎架构仅仅停留在 开发阶段使用 Esbuild，生产环境用 Rollup 的阶段，殊不知，Vite 真正的架构远没有这么简单。一图胜千言，这里放一张 Vite 架构图：

性能利器 - Esbuild

必须要承认的是，Esbuild 的确是 Vite 高性能的得力助手，在很多关键的构建阶段让 Vite 获得了相当优异的性能，如果这些阶段用传统的打包器/编译器来完成的话，开发体验要下降一大截。

那么，Esbuild 到底在 Vite 的构建体系中发挥了哪些作用？

一、依赖预构建——作为 Bundle 工具

首先是开发阶段的依赖预构建阶段。

一般来说， node_modules 依赖的大小动辄几百 MB 甚至上 GB ，会远超项目源代码，相信大家都深有体会。如果这些依赖直接在 Vite 中使用，会出现一系列的问题，这些问题我们在依赖预构建的小节已经详细分析过，主要是 ESM 格式的兼容性问题和海量请求的问题，不再赘述。总而言之，对于第三方依赖，需要在应用启动前进行打包并且转换为 ESM 格式。

Vite 1.x 版本中使用Rollup 来做这件事情，但 Esbuild 的性能实在是太恐怖了，Vite 2.x 果断采用 Esbuild 来完成第三方依赖的预构建，至于性能到底有多强，大家可以參照它与传统打包工具的性能对比图：

当然，Esbuild 作为打包工具也有一些缺点。

• 不支持降级到 ES5 的代码。这意味着在低端浏览器代码会跑不起来。
• 不支持 const enum 等语法。这意味着单独使用这些语法在 esbuild 中会直接抛错。
• 不提供操作打包产物的接口，像 Rollup 中灵活处理打包产物的能力(如 renderChunk 钩子)在 Esbuild 当中完全没有。
• 不支持自定义 Code Splitting 策略。传统的 Webpack 和 Rollup 都提供了自定义拆包策略的 API，而 Esbuild 并未提供，从而降级了拆包优化的灵活性。

尽管 Esbuild 作为一个社区新兴的明星项目，有如此多的局限性，但依然不妨碍 Vite 在开发阶段使用它成功启动项目并获得极致的性能提升，生产环境处于稳定性考虑当然是采用功能更加丰富、生态更加成熟的 Rollup 作为依赖打包工具了。