前言

Webpack 5 相关教程

使用最新版本：始终使用最新 Webpack 版本，这算的上是性价比最高的优化手段之一了
开启缓存：Webpack 5 自带持久化缓存、性能开销大的 loader 进行持久缓存（例如 babel-loader 自带缓存、cache-loader）、external with umd 等等
多线程/多进程打包：例如 HappyPack、Thread-loader、TerserWebpackPlugin 启用 parallel: true、ESLintWebpackPlugin 启用 threads: true、ForkTsCheckerWebpackPlugin 在单独的进程中进行类型检查
使用原生编译工具：例如 Next.js 的做法，swc transform（或者 esbuild）替代 babel transform，swc minify 替代 terser minify，参考 Vite 4.4，Lightning CSS 替代 PostCSS tranform，Lightning CSS 替代 cssnano minify
懒编译/按需编译：基于请求的按需编译，例如 Webpack 5 Lazy Compilation
配置优化：例如寻址优化、跳过文件编译、最小化 loader 作用范围、跳过 TS 类型检查、选择更加快速的 hash 函数
依赖预打包：在 Next.js、UmiJS 等元框架中对 Webpack 核心库、各种插件、loader 进行预打包，可以提升 Node 应用启动性能（避免运行时 require JIT 加载性能开销），同时还能解决第三方库间接依赖版本不受控问题，缺点是依赖升级比较麻烦

Webpack 如何使用原生编译工具：

直接把 Webpack 替换为 esbuild、rspack，但是 Webpack 产物优化仍然是做得最好
- 做地好的 Tree Shaking 可能比不好的 Tree Shaking 在尺寸上少几倍，比如 import { Button } from 'antd' 的例子，之前测试时，webpack 265K、rspack 289K、farm 321K；
- 复杂场景的处理比如对于 Side Effects 的处理，CJS 通常是被判定为有 Side Effects 不走 Tree Shaking 的，但有些工具比如 Webpack 还可以做 CJS 的局部优化；
保留 Webpack，替换一些工具链
- 模块构建，swc transform 替代 babel transform，Lightning CSS 替代 PostCSS transform；
- 混淆压缩，swc minify 替代 terser minify，Lightning CSS 替代 cssnano minify；
- 模块解析，选用更快的解析库，比如用 enhanced-resolve 替代 Node 自带 require.resolve，Vite 4.3 的性能提升都做了啥，不用 resolve 库，改成自己实现，更简单、严格、准确，同时利用缓存。这是大头，应该占了提升了 80%。是否可以用 esbuild resolver，个人觉得没有必要，由于依赖解析调用非常频繁，进程间通信反而会增加开销。