webpack 构建之 splitChunks 优化与 manifest

webpack 构建之 splitChunks 优化与 manifest已关闭评论

1 背景

相信对于每个刚接触构建的同学来说, webpack 都是难以跨越的一道坎,它凭着抽象的概念、“言简意赅” 的文档,难倒了一众英雄好汉。

由于自己平时从零手写 webpack 配置的机会比较少,所以对 webpack 里的一些配置不都是特别清楚。

最近的一个需求需要给页面资源增加 md5 版本号,我正好借着这个机会,把项目里的 webpack 配置都重新梳理了一遍。

本文对于基本的配置概念(如 entry 、 output 等)就不一一赘述了,着重介绍的是 splitChunks 和 manifest 两部分内容。

2 基本概念

要理解 splitChunks ,先要理解几个基本概念,module 、 chunk 和 bundle :

  • module:每个 import 引入的文件就是一个模块(也就是直接手写的代码)。

  • chunk:当 module 源文件传到 webpack 进行打包时,webpack 会根据文件引用关系生成 chunk(也就是 module 在 webpack 处理时是 chunk)。

  • bundle:是对 chunk 进行压缩等处理后的产出(也就是打包后可以直接运行的文件)。

网上有一张图对这几个概念解释的很好 :

chunk 有三种:

  1. 项目入口( entry );

  2. import 动态引入的代码;

  3. 通过 splitChunks 拆分出来的代码。

3 splitChunks 介绍

splitChunks 顾名思义就是用来拆分包的,将满足拆分规则的构建内容抽出来单独打包,从而达到抽离公共模块,减少重复打包的目的。

splitChunks 中的配置项用来确定具体的拆分规则,其中的 cacheGroups 配置项必须同时满足其下的所有条件才能生效。

webpack5 中 splictChunks 的默认配置为:


module.exports = {
//...optimization: {
splitChunks: {
chunks: 'async',
// 内容超过了minSize的值,才会进行打包
minSize: 20000,
// 确保拆分后剩余的最小 chunk 体积超过此项的值,防止出现大小为0的模块
minRemainingSize: 0,
minChunks: 1,
maxAsyncRequests: 30,
maxInitialRequests: 30,
// 超过这个值就会进行强制分包处理,无视minRemainingSize,maxAsyncRequests,maxInitialRequests
enforceSizeThreshold: 50000,
cacheGroups: {
vendors: {
test: /[\/]node_modules[\/]/,
priority: -10,
// 如果当前 chunk 包含已从主 bundle 中拆分出的模块,则它将被重用,而不是生成新的模块
reuseExistingChunk: true,
},
default: {
minChunks: 2,
priority: -20,
reuseExistingChunk: true,
},
},
},
},
};

容易理解的配置已经注释好了,下面将介绍没有注释部分的作用。

3.1 chunks

可配置值有 all、 async 、 initial ,默认值是 async 。

我们先看一个例子,再介绍不同值的作用。

下面是 entry1.js ,其中动态引入了 page1.js ,观察默认配置下的打包结果。(注意:需要自行配置 Babel 解析 React 语法)

entry1.js

import React from'react';
import ReactDom from'react-dom';

const App = () => {
let Page1 = null;
import('./page1.js').then(comp => {
Page1 = comp;
});
return (
<div>
<div>App</div>
<Page1></Page1>
</div>

)
}

ReactDOM.render(<App />, document.getElementById('root'))

page1.js

import _ from'lodash';
import React from'react';

const Page1 = () => {
return (
<div>
<div>Page1</div>
</div>

)
}

exportdefault Page1;

打包结果:

我们来分析一下打包结果:

main.js 为入口文件,上面提到入口文件会单独拆成一个 chunk ,没有问题。

page1_js.js ,为动态加载的文件,上面提到动态加载的文件会单独拆成一个 chunk ,也没有问题。

剩下的是 page1.js 引入的 loadsh 这个第三方库的抽离,与 cacheGroups 的配置有关,后面介绍到 cacheGroups 就明白了。

那么问题来了,为什么 page1.js 引入的 loadsh 被抽离出来了,而 page1.js 与 entry1.js 都引入的 react 却没有呢?

这就是 chunks: “async” 起的作用, async 代表异步,也就是异步加载进来的包才会校验分包规则,进行分包抽离。

  • lodash 是 page1.js 中引入的,而 page1.js 是动态加载的,所以 loadsh 就可以进入分包规则的校验,并抽离出来,生成 vendors-xxxlodash.js 包。

  • react 不是异步加载进来的,所以不能去校验分包规则,不能进行分包抽离。

现在明白了 chunks: “async” 的作用,那么相信 all 和 initial 也能很快理解。

initial 表示只从入口模块进行拆分

all 表示入口模块和异步加载的模块都要进行拆分

现在我们把 chunks 改为 initial 来验证一下:

果然,只有 entry1.js 处引入的 react-dom 被抽离出来,同理,all 的作用就不再展示了。

3.2 cacheGroups

cacheGroups 是 splitChunks 的核心配置,splitChunks 里的配置相当于是 cacheGroups 里每一项的默认值,而 splitChunks 会根据 cacheGroups 的配置去拆分模块。

cacheGroups 里可以定义每种类型包的抽离规则,比如默认的 vendor 包,test 值为 node_modules,意为只匹配 node_modules 的内容,即只打包第三方库,所以 vendor 包就是抽离的第三方库。

这里就可以解释上面打包出来的 vendors-loadsh ,满足了 vendors 的默认配置,属于第三方库,且至少被引用一次。

同理,default 则是抽离用户自定义的公共模块。

下面我们来看下 cacheGroups 里重要的配置项。

3.2.1 minChunks

模块的重复调用次数大于等于 minChunks 值时,就会满足这项拆包条件,但只看入口模块导入的,不看动态加载模块中导入的,即使设置 chunks 为 all 。

下面我们来看个例子:

分别在 entry1.js 和 entry2.js 中都引入本地的 jquery.js 文件,page1.js 不变。

entry1.js

import React from'react';
import ReactDom from'react-dom';
import $ from'./jquery';

console.log($);

const App = () => {
let Page1 = null;
import('./page1.js').then(comp => {
Page1 = comp;
});
return (
<div>
<div>App</div>
<Page1></Page1>
</div>

)
}

ReactDOM.render(<App />, document.getElementById('root'))

entry2.js

import React from'react';
import ReactDOM from'react-dom';
import $ from'./jquery';

const App = () => {
console.log($)
return (
<div>
<div>entry2</div>
</div>

)
}

ReactDOM.render(<App />, document.getElementById('root'))

打包后的结果:

entry1.js 和 entry2.js 都引入了 jquery,所以 jquery 引用次数为 2,满足 default 分包项的 minChunks 值,所以 jquery 被抽离出来了。

为了排除 page1.js 中引入的 jquery 影响,现在入口文件只留下 entry1.js,单独打包 entry1.js 看看。

打包结果:

可以看到,虽然 entry1.js 和其动态加载的 page1.js 都引入了 jquery ,但是并没有分离出 jquery 的 chunk 包,所以 minChunks 不会将动态加载模块中引入的模块算进来。

3.2.2 priority

从上面一个打包结果来看,为什么 react-dom 也满足 default 的规则,却生成的是 vendors-node_modules_react-dom 而不是 default-react_dom 呢?

其实就是这个 priority 属性的作用,用于规定拆包规则的优先级,当某个 chunk 都满足几个拆包规则时,就会根据优先级判断,当优先级相同时,就进最先定义的规则。

3.3 maxInitialRequests

表示为入口文件的最大并行请求数,用于限制分包数量,当分包数量过多时,发起的请求过多反而得不偿失。

请求的定义:

  • 入口文件本身算一个请求;

  • 入口文件动态加载的模块不算在内;

  • 通过 runtimeChunk 拆分出来的 runtime 文件不算在内;

  • 只算 js 文件,css 文件不算在内;

  • 如果同时有两个模块满足 cacheGroups 的拆分规则,但 maxInitialRequests 只允许再拆分一个,那么会拆出体积更大的那个模块。

下面通过三个入口文件来举例(maxInitialRequests 设置为 3注意默认配置项 enforceSizeThreshold,当包的体积超过其值,就会无视 maxInitialRequests 等项,把它配大点进行测试)。

entry1.js

import React from'react';
import ReactDom from'react-dom';
import $ from'./jquery';
import Orgchart from'./orgchart';

console.log($);

const App = () => {
let Page1 = null;
import('./page1.js').then(comp => {
Page1 = comp;
});
return (
<div>
<div>App</div>
<Page1></Page1>
</div>

)
}

ReactDOM.render(<App />, document.getElementById('root'))

entry2.js

import React from'react';
import ReactDom from'react-dom';
import $ from'./jquery';
const App = () => {

console.log($)
return (
<div>
<div>entry2</div>
</div>

)
}

ReactDOM.render(<App />, document.getElementById('root'))

entry3.js

import React from'react';
import ReactDom from'react-dom';
import Orgchart from'./orgchart';
const App = () => {

return (
<div>
<div>App</div>
</div>

)
}

ReactDOM.render(<App />, document.getElementById('root'))

打包结果:

下面来分析一下打包结果:

entry1.js、entry2.js、entry3.js 和 page1.js,作为单独的 chunk 没有问题。

vendors-loadsh 和 vendors-react-dom 作为第三方库,满足 minChunks=1,作为单独的 chunk 也没有问题。

我们的 orgchart 也是被引入了两次的,应该在 default 规则中被抽离出来,但是只有 jquery 被 default 抽离出来了,其中就是 maxInitialRequests 的作用。

分析一下 entry1.js 的并发请求数量:

  1. 请求自身文件;

  2. 请求 react-dom;

  3. 请求 jquery;

  4. 请求 orgchart;

4 个请求,超过了 maxInitialRequests 的限制,所以需要砍掉一个请求,而 react-dom 的优先级高于 jquery 和 orgchart,则只从 jquery 和 orgchart 中考虑。

因为 jquery 体积更大,所以 webpack 抽离了 jquery,把 orgchart.js 放入自己的文件里。

包依赖关系图如下,可以看到 orgchart.js 分别存在于 entry1.js 和 entry3.js 中,并没有被抽离出来:

把 maxInitialRequests 设置为 4 后,可以看到打包结果中出现了 orgchart 的单独 chunk 包:

3.4 maxAsyncRequests

类似 3.3 的 maxInitialRequests,用于限制拆分数量。

maxInitialRequests 是用于限制入口处的并发请求,而 maxAsyncRequests 则是用于限制异步模块内部的并行最大请求数

并发请求的定义:

  • import 文件本身算一个请求;

  • 只算 js 文件、css 文件不算在内;

  • 如果同时有两个模块满足 cacheGroups 的规则需要拆分,但 maxAsyncRequests 只允许拆分一个时,那么会拆出体积更大的那个模块。

比如 3.3 中的例子,只会看 page1.js 里 import 的并发请求数,这里就不重复举例子了。

4. manifest

在一次需求中,由于缓存问题,新修改的页面发布后,用户不清除缓存的话,无法获得新页面,所以需要给其页面资源增加 md5 版本号。

乍一看,挺简单的嘛,不就是打包时 filename 增加一个 contenthash 嘛,但仔细一看项目结构,项目 A 自己并不生成页面资源,它的页面资源是引用项目 B 打包出来的 js 文件。

也就是说要在一个项目中,导入另一个项目带有 hash 值的文件,那每次打包的 hash 值都不同,我们怎么知道要请求的文件的 hash 值呢?

这时候就需要 manifest 了,它能记录原文件名与其加了 hash 值后的映射,利用它就可以准确请求加了 hash 值后的文件啦。

可以使用 webpack-manifest-plugin 来生成 manifest.json 文件,文件内容如下:

5. 总结

通过亲手去试验一个个 demo,即使难如 webpack 也熟悉了很多,之后再接触到 webpack 的配置也不会那么恐惧了。

当害怕使用某一项技术的时候,正说明自己对它不熟悉,不了解,更需要付出更多的时间去熟悉、理解它。等再次遇见这个难点时,如果你不再害怕,反而因为可以大展身手而兴奋的话,那么恭喜你已经克服它了。





紧追技术前沿,深挖专业领域

扫码关注我们吧!

来源: 腾讯IMWeb前端团队