🙋🏻‍♀️编者按：本文是蚂蚁集团前端工程师云谦关于 Umi 4 新特性系列分享的第四篇 - build 阶段的构建提速，欢迎享用～

第一篇👉🏻 Umi 4 特性 01：MFSU V3，比 Vite 还要快

第二篇👉🏻 Umi 4 特性 02：React Router 6 和新路由

第三篇👉🏻 Umi 4 特性 03：默认最快的请求

构建提速不只是 dev 阶段的 MFSU，还要考虑流程上 build 阶段的构建。build 阶段的构建相比 dev 阶段，会做很多额外的事，比如 js 压缩和 css 压缩、tree-shaking、code-splitting，同时对于依赖编译和缓存的利用方式也会不同。所以优化手段也会大不同。

esbuild

虽然构建提速没有银弹，但 esbuild 是这个时期的大杀器。

JS 压缩之前默认是 terser，Umi 4 之后默认是 esbuild。原因在《彻底告别编译 OOM，用 esbuild 做压缩器》有过介绍，除了快，还可彻底解压缩导致的 OOM 问题，缺点是相比 terser 尺寸会增加 10%。同时压缩方式还支持 terser、uglifyJs、swc，支持不同场景，比如针对不支持 es6 的场景，选 uglifyJs 可以在遇到高级语法时主动抛错。

export default {  jsMinifier: 'uglifyJs',  jsMinifierOptions: {},}

CSS 压缩之前默认是 cssnano，Umi 4 之后默认也是 esbuild。相比 cssnano，用 esbuild 压缩 CSS 速度提升 6 倍，而尺寸仅增加约 1%。同时也可通过配置切换回 cssnano，以及尝试我们试验性支持的 parcelCSS。

export default {  cssMinifier: 'parcelCSS',  cssMinifierOptions: {},}

esbuild 不仅用于压缩，还被用到 JS/TS 文件实时编译、import/export 分析、测试等环节。JS/TS 文件实时编译是为了让配置、MOCK 等文件支持 TypeScript 语法，所以会通过 require hook 的方式，在遇到 .ts 文件时自动用 esbuild 编译；import / export 分析通常用 es-module-lexer 分析，但由于他不支持 jsx，所以会用 esbuild 先编译到 esm 格式再给 es-module-lexer 使用；Umi 4的测试默认用 esbuild 作为 js transformer，相比 ts-jest 快非常多，支持通过配置切换到 swc 或 ts-jest。

依赖编译

通常一个包含 600 文件的项目，会有 6000 文件的依赖。这也是为啥依赖编译速度很大程度上决定了项目构建速度。webpack 的依赖编译是个绕不开的点，因为就算我们什么都不配，webpack 也会通过 ast 的方式分析 import/export 等信息。

Umi 4 删除了 nodeModulesTransform，不会再做 node_modules 的全量 babel 编译，开发者需要手动找出使用了高级语法的依赖，手动配置。之前开启的项目通常是出于支持 es5 的考虑，而全量开启是比较偷懒的做法，但带来的问题是后续持续的构建时间消耗。

externals 是绕过 webpack 依赖编译的好办法，所以之前 yuyan 有推出 bmwAutoExternals 配置，但缺点是本地无法验证。dev 跑完没问题而流程上 build 完出问题的场景，一线开发者完全无法定位问题。Umi 4 会解这个问题，让本地也可做 bmwAutoExternals 的验证。

Umi 4 默认 webpack 5，而 webpack 5 是具备物理缓存功能的，这是相比 Vite 等其他工具非常大的优势，流程上也值得好好利用。Smallfish 之前就接入了基于迭代的构建物理缓存功能，Umi 4 也会跟上，在流程上做缓存的校验、下载和上传，让流程 build 进一步提速。注：这个 Remote Caching 的机制之后还会用到 MFSU 上，让依赖缓存的 invalidate 更精确。

参考：
https://zhuanlan.zhihu.com/p/139219361  

彻底告别编译 OOM，用 esbuild 做压缩器
https://github.com/vitejs/vite/pull/4371  

Vite 使用 esbuild 压缩 CSS 的 PR