Webpack4的缓存方案

在使用Webpack4以及之前的版本时，我们都会注意到这样的现象：

代码热更新很快
npm run start慢
npm run build慢

这种现象的本质是：Webpack4在运行时是有缓存的，只不过缓存只存在于内存中。所以，一旦Webpack的运行程序被关闭，这些缓存就丢失了。这就导致我们npm run start/build的时候根本无缓存可用。

所以，解决问题的办法就是把这些Webpack编译过程中的产生的缓存持久化到本地磁盘、数据库或者云端。这里面涉及到两点：要持久化什么，持久化到哪里。

Webpack本身就已经有一套缓存方案，只是不够完善，不支持持久化。站在现在的角度来看，我们应该直接去完善Webpack核心代码，补充上持久化缓存的功能，使用一套缓存方案解决所有问题，这是显而易见的。

然而，当时社区好像没搞清楚“要持久化什么”这个问题， 他们没有在Webpack核心代码上发力，而是选择了从外部解决。于是就出现了cache-loader、dll等技术，虽然在一定程度上解决了问题，但却引入了过多的复杂性。

Webpack5的缓存方案

实际上，“要持久化什么”这个问题从一开始就是显而易见的：是Webpack运行时存在于内存中的那些缓存，不是loader的产物，更不是dll。因此，Webpack5提供了一套持久化抽象，将数据存放在文件系统中

Webpack5直接从内部核心代码的层面，统一了持久化缓存的方案，有效降低了缓存配置的复杂性。除此之外，由于所有被webpack处理的模块都会被缓存，我们npm run start/build的二次编译速度会远超cache-loader，同时dll也可以退出历史舞台了。

Webpack4时之所以要有dll，是因为cache-loader并不能覆盖所有模块，只能对个别被loader处理的模块进行缓存。而那些通用的库是没法被cache-loader处理的，所以只能通过dll的方式来预编译。

实际上，Webpack5的内置缓存方案无论从性能上还是安全性上都要好于cache-loader。

性能上：由于所以被webpack处理的模块都会被缓存，缓存的覆盖率要高的多。

安全上：由于cache-loader使用了基于mtime的缓存验证机制，导致在CI环境中缓存经常会失效，但是Webpack5改用了基于文件内容etag的缓存验证机制，解决了这个问题。

Webpack5的缓存使用

const path = require("path");
const HtmlWebpackPlugin = require("html-webpack-plugin");
module.exports = {mode: "development",entry: "./src/index.js",cache: {type: "filesystem", // 'memory' | 'filesystem'cacheDirectory: path.resolve(__dirname, "node_modules/.cache/webpack"), // 保存目录},output: {filename: "bundle.js",path: path.resolve(__dirname, "dist"),},devtool: false,module: {rules: [{test: /\.js$/,use: [{loader: "babel-loader",options: {presets: ["@babel/preset-react"],},},],exclude: /node_modules/,},],},devServer: {},plugins: [new HtmlWebpackPlugin({template: "./public/index.html",}),],
};

cache: true 与 cache: { type: 'memory' } 配置作用一致，表示缓存在内存中。cache.type 设置为 'filesystem' 时，表示缓存在文件系统中。