Esbuild

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

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

主要是 ESM 格式的兼容性问题和海量请求的问题，对于第三方依赖，需要在应用启动前进行打包并且转换为ESM 格式。vite1.x中使用rollup（js实现）实现，性能远不如Golang编写的Esbuild。

但也不能完全使用Esbuild实现，因为Esbuild有如下缺点：

不支持ES5降级，意味着不支持低版本浏览器；
不支持 const enum 等语法。这意味着单独使用这些语法在 esbuild 中会直接抛错；
不提供操作打包产物的接口，无法灵活处理打包产物；
不支持自定义Code splitting（拆包）策略，降低了拆包优化的灵活性。

单文件编译-作为ts和jsx的编译工具

将 Esbuild 作为 Transformer 来用，原因在于原来的babel或者tsc性能不如esbuild，但esbuild未实现类型系统，所以还需要tsc 进行类型检查。

代码压缩——作为压缩工具

传统压缩工具譬如 Terser使用js开发后在webpack或者rollup中作为plugin完成代码打包后的压缩混淆工作，但流程中涉及大量AST操作，而各个AST工具之间无法实现共享，比如terser无法与babel共享同一个AST，使得出现很多重复的解析过程。再者js作为解释性+JIT语言，对于压缩这种CPU密集型工作，性能远不如golang。

Rollup

生产环境 Bundle

虽然 ESM 已经得到众多浏览器的原生支持，但生产环境做到完全 no-bundle 也不行，会有网络性能问题。为了在生产环境中也能取得优秀的产物性能，Vite 默认选择在生产环境中利用 Rollup 打包，并基于 Rollup 本身成熟的打包能力进行扩展和优化，主要包含 3 个方面:

css代码分割
自动预加载： Vite 会自动为入口 chunk 的依赖自动生成预加载标签
异步 Chunk 加载优化

兼容插件机制

无论是开发阶段还是生产环境，Vite 都根植于 Rollup 的插件机制和生态。