打工人打工魂，不懂工具忙死人，教你如何用webpack5.0（打工人打工魂）

1 前言

相信大家肯定看过很多产品的开箱测评，今天来跑一个软件新版的上手测评 — webpack5.0。自从2018年2月，webpack4 发布以来，webpack 就暂时没有更进一步的重大更新，阔别 2 年多后，webpack5正式发布！通过本文也希望为我们的项目是否值得升级v5提供一些参考。

本次介绍的升级重点：

功能清除
长期缓存优化
性能优化 — 持久化缓存
Module Federation
其他特性

2 功能清除不再为Node.js模块自动引用 Polyfills

时过境迁，webpack模块应用的思想也发生了变化

v4以前附带了许多node.js核心模块的polyfill，在构建时给 bundle附加了庞大的polyfills，在大部分情况下，polyfills并不是必须。
现在v5将要停止这一切，在模块的应用中不再自动引入Polyfills，明显的减小了打包体积。

举个栗子：

// index.jsimport CryptoJS from 'crypto-js';const md5Password = CryptoJS.MD5('123123');console.log(md5Password);

v5 vs v4：

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

v5编译中，会出现polyfill添加提示，如果不需要node polyfille,按照提示 alias 设置为 false 即可，下面v5中的配置以及编译结果: (244KiB)

// webpack.config.js resolve: { // 1.不需要node polyfilss alias: { crypto: false }, // 2.手动添加polyfills // fallback: { // "crypto": require.resolve('crypto-browserify') // } },

如何迁移？

尽量尝试使用前端兼容的模块，从而减小打包后的js体积
根据错误提示手动为Node.js 核心模块添加 polyfill

3 长期缓存优化对比原来的chunkId和moduleId

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

缺点：当删除或者暂时不使用1.js这个文件后，那么2.js->1.js，3.js->2.js，这样就会造成原本线上的2.js请求时会造成缓存失效.

解决缓存失效：引用外部插件

chunkId，可安装NamedChunksPlugin插件来稳定chunkId；或者配置optimization.chunkIds='named'；

moduleId，可安装HashedModuleIdsPlugin插件覆盖默认的moduleId规则，使用模块路径生成的hash作为moduleId。

webpack5新增了长期缓存的算法:

算法策略：对moduleId和chunkId的生成策略进行了优化。

moduleId改为根据上下文模块路径计算，chunkId根据chunk内容计算
以确定性的方式为模块和分块分配短的（3或5位）数字ID，这是包大小和长期缓存之间的一种权衡，因此webpack5将不需要引入任何的外力，便可实现长期缓存。

再举个栗子来验证一下：

// webpack.config.jsmodule.exports = { entry: { a: "./src/a.js", b: "./src/b.js", main: "./src/index.js" }, // 长期缓存优化配置 optimization: { chunkIds: 'deterministic', moduleIds: 'deterministic' },}

编译后，会发现相应的模块和分块，分别被分配了确定的数字ID和名称，当项目中删除或者不使用某个模块时，对其他文件并不会产生影响。

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

如何迁移？

直接使用chunkIds、moduleIds的默认值 (deterministic) 便可平滑迁移
也可以使用旧的默认值chunkIds: "size"，moduleIds: "size"，这将会生成更小的包，但为了缓存，会更频繁地将其失效 (不建议使用)

4 性能优化 — 持久化缓存

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

存在问题：

这些方案在使用上需要一定的学习成本
这些方法大多是以牺牲部分文件体积和后续优化空间为代价的。

webpack5的持久化缓存方案

v5性能优化可以总结为：

第一次构建是一次全量构建，它会利用磁盘模块缓存(以空间换时间)，使得后续的构建从中获利。
后续构建具体流程是：读取磁盘缓存 -> 校验模块 -> 解封模块内容。

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

v5中，可以修改设置为filesystem, 将缓存写入硬盘，不在需要cache-loader等性能优化的方法。

// webpack.config.jsmodule.exports = { cache: { // 1. 将缓存类型设置为文件系统 type: 'filesystem', // 默认是memory // 2. 将缓存文件夹命名为 .temp_cache, // 默认路径是 node_modules/.cache/webpack cacheDirectory: path.resolve(__dirname, '.temp_cache') }};

配置后的编译时间为776ms, 相比之前的默认配置，大大缩减了编译时间。

4 Module Federation

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

什么是模块联邦？

Module Federation是为了解决独立应用之间代码共享问题。可以在项目内动态加载其他项目的代码，同步可以共享依赖。
通过细化功能模块、组件复用、共享第三方库、runtime dependencies线上加载npm包等，可以更好的服务于多页应用、微前端等开发模式。

以前我们共享代码是如何做的？

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

UMD
即Universal Module Definition（通用模块规范），基本原理是利用设计模式中的工厂函数来统一不同的模块定义规范。

类似于我们开发的时候，经常会把某些功能封装成可复用的模块。并且对外暴露一个API，比如jquery、lodash等这类第三方插件，也可以通过CND的方式直接应用。后续这个公共函数的升级改造，我们更新CND引用链接地址，应用就自然也更新了。

UMD优点在 runtime。缺点也明显，体积优化不方便，容易有版本冲突.

微前端
微前端也是一种模块共享的方式，主要解决多项目并存问题，多项目并存的最大问题就是模块共享，不能有冲突。

在资源加载方式上，一般有两种打包方式：

子应用独立打包，模块解耦了，但公共的依赖不易维护处理
整体应用一起打包，能解决公共依赖；但庞大的多个项目又使打包变慢，后续也不好扩展

微前端架构如下：

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

从图中可以看到，这个方案是直接将一个应用的 bundle，应用于另一个应用。
应用可以模块化输出，就是说它本身可以自我消费，也可以动态分发 runtime 子模块给其他应用。

模块联邦的使用方式如下

module.exports = { // other webpack configs... plugins: [ new ModuleFederationPlugin({ // 1. name 当前应用名称，需要全局唯一 name: "app_one_remote", // 2. remotes 可以将其他项目的 name 映射到当前项目中 remotes: { app_two: "app_two_remote", app_three: "app_three_remote" }, // 3. exposes 表示导出的模块，只有在此申明的模块才可以作为远程依赖被使用 exposes: { AppContainer: "./src/App" }, // 4. shared可以让远程加载的模块对应依赖改为使用本地项目的 React或ReactDOM。 shared: ["react", "react-dom", "react-router-dom"] }), new HtmlWebpackPlugin({ template: "./public/index.html", chunks: ["main"] }) ]};

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

import { Search } from "app_two/Search";

app_two/Search来自于app_two 的配置:

// app_two的webpack 配置export default { plugins: [ new ModuleFederationPlugin({ name: "app_two", library: { type: "var", name: "app_two" }, filename: "remoteEntry.js", exposes: { Search: "./src/Search" }, shared: ["react", "react-dom"] }) ]};

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

5 其他特性