ESBuild在Vite中发挥了什么作用?
ESBuild有多种作用:
- 作为打包器
- 作为代码转译(Transfomer)的工具,比如将jsx文件转译成js
- 作为代码压缩混淆的工具
依赖预构建—— ESBuild 作为打包工具
ESBuild是由Go开发的,通过并行等技术,任务执行效率非常之高
由Vite构建的项目中,在开发环境中Vite采用no-bundle
的方式对源代码进行(不)打包,利用现代浏览器原生支持ESM的特性,实现开发服务器的快速启动。相对于 Webpack 一次性将所有代码进行打包后再启动开发服务器的方式快了100倍不止。
但Vite是完全不打包吗?显然不是的。在Vite的开发服务器里,项目中每一个import
导入都是一个http请求,源代码中的import
倒还不算多,但第三方依赖中的模块导入就非常之多了,甚至二次依赖都是非常普遍的。这就会导致出现请求瀑布,严重影响页面的首屏性能——打开页面动辄要发起上千个http请求,这对浏览器的压力是巨大的,要知道浏览器对同一个域名下最多只能维护 6 个 TCP连接。
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 的编译性能 :
可以看到性能提升是非常之大了,但是ESBuild也有其缺点:不能进行类型检查,它仅仅能抹去TS中的类型标注。因此,在生产环境下,我们执行build
命令时,会先执行tsc
做类型检查再打包代码。
代码压缩——作为构建产物的压缩混淆工具
在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 作者:应届切图仔