共计 4323 个字符，预计需要花费 11 分钟才能阅读完成。
所谓的伟人，指的就是 Vite 底层所深度应用的两个构建引擎——Esbuild 和 Rollup。这两个构建引擎对于 Vite 来说到底有多重要呢？在 Vite 的架构中，这两者各自表演了什么样的角色？接下来，咱们一起拆解 Vite 的双引擎架构，深入分析 Esbuild 和 Rollup 在 Vite 中的作用。
一、Vite 架构
很多人对 Vite 的双引擎架构仅仅停留在开发阶段应用 Esbuild，生产环境用 Rollup 的阶段，殊不知，Vite 真正的架构远没有这么简略，上面是一张 Vite 的架构图。
对于 Vite 的双引擎架构，从图中能够略窥一二。
二、Esbuild
必须要抵赖的是，Esbuild 确实是 Vite 高性能的得力助手。在很多要害的构建阶段让 Vite 取得了相当优异的性能，如果这些阶段应用传统的打包器 / 编译器来实现的话，开发体验要降落一大截。那么，Esbuild 到底在 Vite 的构建体系中施展了哪些作用？
2.1 依赖预构建
首先，在开发阶段的依赖预构建阶段，Esbuild 将提供 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 作为依赖打包工具了。
2.2 单文件编译
在依赖预构建阶段，Esbuild 作为 Bundler 的角色存在。而在 TS(X)/JS(X) 单文件编译下面，Vite 也应用 Esbuild 进行语法转译，也就是将 Esbuild 作为 Transformer 来用。大家能够在架构图中 Vite Plugin Pipeline 局部找到。
也就是说，Esbuild 转译 TS 或者 JSX 的能力通过 Vite 插件提供，这个 Vite 插件在开发环境和生产环境都会执行，因而，咱们能够得出上面这个论断。
Vite 曾经将 Esbuild 的 Transformer 能力用到了生产环境。尽管如此，对于低端浏览器场景，Vite 依然能够做到语法和 Polyfill 平安。
这部分能力用来替换原先 Babel 或者 TSC 的性能，因为无论是 Babel 还是 TSC 都有性能问题，大家对这两个工具广泛的认知都是: 慢，太慢了。
当 Vite 应用 Esbuild 做单文件编译之后，晋升能够说相当大了，咱们以一个微小的、50 多 MB 的纯代码文件为例，来比照 Esbuild、Babel、TSC 包含 SWC 的编译性能。
能够看到，尽管 Esbuild Transfomer 能带来微小的性能晋升，但其本身也有局限性，最大的局限性就在于 TS 中的类型查看问题。这是因为 Esbuild 并没有实现 TS 的类型零碎，在编译 TS(或者 TSX) 文件时仅仅抹掉了类型相干的代码，临时没有能力实现类型查看。
也因而，疾速上手这一节，我让大家留神初始化工程的构建脚本，vite build 之前会先执行 tsc 命令，也就是借助 TS 官网的编译器进行类型查看。
当然，要解决类型问题，我更举荐大家应用 TS 的编辑器插件。在开发阶段就能早早把问题裸露进去并解决，不至于等到我的项目要打包上线的时候。
2.3 代码压缩
Vite 从 2.6 版本开始，就默认应用 Esbuild 来进行生产环境的代码压缩，包含 JS 代码和 CSS 代码。下图演示了在生产环境中 Esbuild 压缩器通过插件的模式融入到了 Rollup 的打包流程中。
那为什么 Vite 要将 Esbuild 作为生产环境下默认的压缩工具呢？因为压缩效率切实太高了。传统的形式都是应用 Terser 这种 JS 开发的压缩器来实现，在 Webpack 或者 Rollup 中作为一个 Plugin 来实现代码打包后的压缩混同的工作。但 Terser 其实很慢，次要有 2 个起因。
- 压缩这项工作波及大量 AST 操作，并且在传统的构建流程中，AST 在各个工具之间无奈共享，比方 Terser 就无奈与 Babel 共享同一个 AST，造成了很多反复解析的过程。
- JS 自身属于解释性 + JIT（即时编译）的语言，对于压缩这种 CPU 密集型的工作，其性能远远比不上 Golang 这种原生语言。
因而，Esbuild 这种从头到尾共享 AST 以及原生语言编写的 Minifier 在性能上可能甩开传统工具的好几十倍。举个例子，咱们能够看上面这个理论大型库 (echarts) 的压缩性能测试项目:
压缩一个大小为 3.2 MB 的库，Terser 须要消耗 8798 ms，而 Esbuild 仅仅须要 361 ms，压缩效率较 Terser 晋升了二三十倍，并且产物的体积简直没有劣化，因而 Vite 果决将其内置为默认的压缩计划。
总的来说，Vite 将 Esbuild 作为本人的性能利器，将 Esbuild 各个垂直方向的能力 (Bundler、Transformer、Minifier) 利用的酣畅淋漓，给 Vite 的高性能提供了无利的保障。
三、Rollup
Rollup 在 Vite 中的重要性一点也不亚于 Esbuild，它既是 Vite 用作生产环境打包的外围工具，也间接决定了 Vite 插件机制的设计。那么，Vite 到底基于 Rollup 做了哪些事件？
3.1 生产环境 Bundle
尽管 ESM 曾经失去泛滥浏览器的原生反对，但生产环境做到齐全 no-bundle 也不行，会有网络性能问题。为了在生产环境中也能获得优良的产物性能，Vite 默认抉择在生产环境中利用 Rollup 打包，并基于 Rollup 自身成熟的打包能力进行扩大和优化，次要蕴含 3 个方面:
- CSS 代码宰割。如果某个异步模块中引入了一些 CSS 代码，Vite 就会主动将这些 CSS 抽取进去生成独自的文件，进步线上产物的缓存复用率。
- 主动预加载。Vite 会主动为入口 chunk 的依赖主动生成预加载标签 <link rel=”modulepreload”>，如:
<head>
<!-- 省略其它内容 -->
<!-- 入口 chunk -->
<script type="module" crossorigin src="/assets/index.250e0340.js"></script>
<!-- 主动预加载入口 chunk 所依赖的 chunk-->
<link rel="modulepreload" href="/assets/vendor.293dca09.js">
</head>这种适当预加载的做法会让浏览器提前下载好资源，优化页面性能。
- 异步 Chunk 加载优化。在异步引入的 Chunk 中，通常会有一些专用的模块，如现有两个异步引入的 Chunk: A 和 B，而且两者有一个公共依赖 C，如下图:
个别状况下，Rollup 打包之后，会先申请 A，而后浏览器在加载 A 的过程中才决定申请和加载 C，但 Vite 进行优化之后，申请 A 的同时会主动预加载 C，通过优化 Rollup 产物依赖加载形式节俭了不必要的网络开销。
3.2 兼容插件机制
无论是开发阶段还是生产环境，Vite 都根植于 Rollup 的插件机制和生态，如上面的架构图所示。
在开发阶段，Vite 借鉴了 WMR 的思路，本人实现了一个 Plugin Container，用来模仿 Rollup 调度各个 Vite 插件的执行逻辑，而 Vite 的插件写法齐全兼容 Rollup，因而在生产环境中将所有的 Vite 插件传入 Rollup 也没有问题。
反过来说，Rollup 插件却不肯定能齐全兼容 Vite。不过，目前依然有不少 Rollup 插件能够间接复用到 Vite 中，你能够通过这个站点查看所有兼容 Vite 的 Rollup 插件: vite-rollup-plugins.patak.dev/。
狼叔在《以框架定位论前端的先进性》提到古代前端框架的几大分类，Vite 属于人有我优的类型，因为相似的工具之前有 Snowpack，Vite 诞生之后补齐了作为一个 no-bundle 构建工具的 Dev Server 能力(如 HMR)，的确比现有的工具能力更优。但更重要的是，Vite 在社区生态方面比 Snowpack 更占先天劣势。
Snowpack 自研了一套插件机制，相似 Rollup 的 Hook 机制，能够看出借鉴了 Rollup 的插件机制，但并不能兼容任何现有的打包工具。如果须要打包，只能调用其它打包工具的 API，本身不提供打包能力。
而 Vite 的做法是从头到尾根植于的 Rollup 的生态，设计了和 Rollup 十分吻合的插件机制，而 Rollup 作为一个十分成熟的打包计划，从诞生至今曾经迭代了六年多的工夫，npm 年下载量达到上亿次，产物品质和稳定性都经验过大规模的验证。某种程度上说，这种根植于已有成熟工具的思路也能打消或者升高用户心田的疑虑，更有利于工具的推广和倒退。
四、总结
首先，Esbuild 作为构建的性能利器，Vite 利用其 Bundler 的性能进行依赖预构建，用其 Transformer 的能力进行 TS 和 JSX 文件的转译，也用到它的压缩能力进行 JS 和 CSS 代码的压缩。
接着，我给你介绍了 Vite 和 Rollup 的关系。在 Vite 当中，无论是插件机制、还是底层的打包伎俩，都基于 Rollup 来实现，能够说 Vite 是对于 Rollup 一种场景化的深度扩大，将 Rollup 从传统的 JS 库打包场景扩大至残缺 Web 利用打包，而后联合开发阶段 no-bundle 的外围竞争力，打造出了本人独具一格的技术品牌。
因而，你能够看出双引擎对于 Vite 的重要性，如果要深刻学习和利用 Vite，那么把握 Esbuild 和 Rollup 的根底应用和插件开发是十分有必要的。在前面的解说中，咱们将一起进入双引擎自身的学习。
