打工人，打工魂，打工不懂工具忙死人，教你如何优雅使用webpack5.0

• v4以前附带了许多node.js核心模块的polyfill，在构建时给 bundle附加了庞大的polyfills，在大部分情况下，polyfills并不是必须。

• 现在v5将要停止这一切，在模块的应用中不再自动引入Polyfills，明显的减小了打包体积。

举个栗子：

v5 vs v4：

• 在v4中，crypto模块会主动添加 polyfill，也就是crypto-browserify，我们运行的代码是不需要的，反而会使最后的包变大，影响编译速度。v4的编译结果: (1.56MiB)

如何迁移/strong>

• 尽量尝试使用前端兼容的模块，从而减小打包后的js体积

• 根据错误提示 手动为Node.js 核心模块添加 polyfill

3 长期缓存优化

对比原来的chunkId和moduleId

在v4之前, chunkId和moduleId默认值是自增id，这样的配置下，如果有新的entry增加，chunkId也会递增

注意： 虽然chuckId不变，但更改chunk内容时，chunkhash还是会改变的。

如何迁移/strong>

• 直接使用chunkIds、moduleIds的默认值 (deterministic) 便可平滑迁移

• 也可以使用旧的默认值chunkIds: “size”，moduleIds: “size”，这将会生成更小的包，但为了缓存，会更频繁地将其失效 (不建议使用)

4 性能优化 — 持久化缓存

饱受诟病的编译速度

Webpack的编译速度相信是很多同学比较头痛的问题，在 CI持续性集成或者构建线上应用包的阶段时，要对Webpack配置加入代码优化、代码压缩等插件，当然也有很多伟大的方法来进行优化，例如HappyPack、Cache-loader等方法，来缩减构建时间、减小成本。

存在问题：

• 这些方案在使用上需要一定的学习成本

• 这些方法大多是以牺牲部分文件体积和后续优化空间为代价的。

webpack5的持久化缓存方案

v5性能优化可以总结为：

• 第一次构建是一次全量构建，它会利用磁盘模块缓存(以空间换时间)，使得后续的构建从中获利。

• 后续构建具体流程是：读取磁盘缓存 -> 校验模块 -> 解封模块内容。

默认情况下，缓存配置是memory，目前项目编译的时间为3298ms

4 Module Federation

如果说上面的优化都是常规套路，那么本次升级的模块联邦，有点让人出乎意料~

什么是模块联邦/h3>

• Module Federation是为了解决独立应用之间代码共享问题。可以在项目内动态加载其他项目的代码，同步可以共享依赖。

• 通过细化功能模块、组件复用、共享第三方库、runtime dependencies线上加载npm包等，可以更好的服务于多页应用、微前端等开发模式。

以前我们共享代码是如何做的/h3>

NPM
维护一个CommonComponents的NPM包，在不同项目中安装、使用。如果 NPM 包升级，对应项目都需要重新安装新版本，本地编译，打包到 bundle 中。

v5中模块共享方式 — 模块联邦

比如设置了remotes: { app_two: “app_two_remote” }，在代码中就可以直接利用以下方式直接从对方应用调用模块

app_two/Search来自于app_two 的配置:

正是因为 Search在exposes被导出，我们因此可以使用 [name]/[exposes_name] 这个模块，这个模块对于被引用应用来说是一个本地模块。

5 其他特性

• 构建优化 — 更好的Tree Shacking

• 支持崭新的web平台功能

• 开发体验的提升

• …

6 思考

总体来说webpack5在打包体积、编译速度上都有了不错的提升，在很多功能的配置、迁移上也较灵活便。在升级中，一些细节和插件的兼容性是主要的问题，还有待继续完善。抛砖引玉，欢迎大家一起来吐槽~

参考

[1]. webpack5官网 https://webpack.docschina.org/blog/2020-10-10-webpack-5-release/
[2]. 模块联邦官网
https://module-federation.github.io/blog/get-started
[3]. webpack5优化和工作原理 https://www.jianshu.com/p/b26c5253c455
[4]. webpack新特-模块联邦 https://zhuanlan.zhihu.com/p/115403616

来源：大转转FE