Vite双引擎架构——ESBuild

ESBuild在Vite中发挥了什么作用?

ESBuild有多种作用:

  • 作为打包器
  • 作为代码转译(Transfomer)的工具,比如将jsx文件转译成js
  • 作为代码压缩混淆的工具

依赖预构建—— ESBuild 作为打包工具

ESBuild是由Go开发的,通过并行等技术,任务执行效率非常之高

由Vite构建的项目中,在开发环境中Vite采用no-bundle的方式对源代码进行(不)打包,利用现代浏览器原生支持ESM的特性,实现开发服务器的快速启动。相对于 Webpack 一次性将所有代码进行打包后再启动开发服务器的方式快了100倍不止。

Vite双引擎架构——ESBuild

但Vite是完全不打包吗?显然不是的。在Vite的开发服务器里,项目中每一个import导入都是一个http请求,源代码中的import倒还不算多,但第三方依赖中的模块导入就非常之多了,甚至二次依赖都是非常普遍的。这就会导致出现请求瀑布,严重影响页面的首屏性能——打开页面动辄要发起上千个http请求,这对浏览器的压力是巨大的,要知道浏览器对同一个域名下最多只能维护 6 个 TCP连接。

Vite双引擎架构——ESBuild

Vite的方案是仅对第三方包进行打包,也就是所谓的预构建(Pre-Build) ,在预构建之前,ESBuild还会将那些仅支持 CommonJS 的第三方依赖转换为 ESM 模块格式,但是不用担心效率问题,ESBuild的执行效率非常之高。

ESBuild作为Bundle 工具速度这么快,但也存在一些缺点

  • 无法进行语法降级和polyfill
  • 无法操作打包后的产物。比如rollup就有renderChunk钩子来灵活操作打包后的chunk文件
  • 不支持 Code Splitting拆包策略,而webpack和rollup都能够自定义拆包策略

正是以上局限性的限制,导致即便ESBuild性能如此优秀,但Vite在生产环境仍然采用的是功能更加成熟的rollup进行代码打包。

总的来说,ESbuild作为打包器的作用就是对第三方包进行ESM格式转换,并进行预构建。当然,预构建也是可以通过配置进行手动控制的,比如通过include配置对动态导入的模块和虚拟模块进行提前预构建

单文件编译—— 作为 TS 和 JSX 的转译工具

过去 transform 的任务通常由 Babel 或 TSC 完成,但其效率远远比不上 ESBuild,为了提升转译效率,Vite采用ESBuild 进行代码转译,比如对 TS 或 JSX 代码转译。我们以一个巨大的,50 多 MB 的纯代码文件为例,来对比 Esbuild 、 Babel 、 TSC 包括 SWC 的编译性能 :

Vite双引擎架构——ESBuild

可以看到性能提升是非常之大了,但是ESBuild也有其缺点:不能进行类型检查,它仅仅能抹去TS中的类型标注。因此,在生产环境下,我们执行build命令时,会先执行tsc做类型检查再打包代码。

代码压缩——作为构建产物的压缩混淆工具

Vite双引擎架构——ESBuild

在Vite架构图的生产环境部分可以看到,Vite采用了ESBuild进行代码压缩。既然用rollup来构建的,拿为什么不用rollup的terser 插件呢?

原因是ESBuild是在是太快了,而 terser 的速度太慢了,原因是:

  • ESbuild内部共用同一个 AST,因此代码压缩时省去了许多重复的解析工作,比如将代码转换为 AST 的时间。而rollup各个插件中比如babel和terser之间就无法公用同一个AST
  • terser是JS所实现的,而JS作为解释性+JIT(即时编译)语言,对于代码压缩任务来说,其执行效率肯定是比不上golong这种编译型语言的,毕竟人家是提前就编译好二进制机器码的。

总结

总的来说,Vite为了将效率提升到极致,可以说是把ESBuild的各项能力(Transfomer,Bundle,Minify)长处发挥的淋漓尽致。

原文链接:https://juejin.cn/post/7337918042255392794 作者:应届切图仔

(0)
上一篇 2024年2月22日 上午10:11
下一篇 2024年2月22日 上午10:21

相关推荐

发表回复

登录后才能评论