webpack文件系统缓存
共 2012字,需浏览 5分钟
·
2021-05-22 01:38
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' 时,表示缓存在文件系统中。