webpack 拆包：SplitChunksPlugin

chunk是输出产物的基本组织单位，在生成阶段 WebPack 按规则将 entry 及其它 module 插入 chunk 中，之后再由 SplitChunksPlugin 插件根据优化规则与 ChunkGraph 对 chunk 做一系列的变化、拆解、合并操作，重新组织成一批性能(可能)更高的 chunks 。运行完毕之后 WebPack 继续将 chunk 一一写入物理文件中，完成编译工作。

本文将会介绍WebPack 基本的分包规则，以及如何通过配置SplitChunksPlugin、ChunkGraph优化分包。

默认分包规则

默认有以下规则：(默认规则集中在compilation.seal 函数实现)

​ ● 同一个entry下触达到的模块组织成一个 chunk（Initial chunk）

​ ● 异步模块单独组织为一个 chunk（Async Chunk）

​ ● entry.runtime单独组织成一个 chunk

1. Entry 分包处理

seal 阶段遍历 entry 对象，为每一个 entry 单独生成 chunk，之后再根据模块依赖图将 entry 触达到的所有模块打包进 chunk 中。

// 比如对于如下配置：
module.exports = {
  entry: {
    entry1: "./src/entry1",
    entry2: "./src/entry2",
  }
};

遍历 entry 对象属性并创建出 chunk[entry1] 、chunk[entry2] 两个对象，最后形成如下两个chunk：

生成的dist目录如下：(基于 entry 生成的 chunk 通常称之为「Initial chunk」)

2. 异步模块分包处理

遇到异步模块则创建单独的 Chunk 对象，单独打包异步模块，其子模块也都加入这个 chunk 中。

WebPack 4 之后，只需要用异步语句 require.ensure(‘./a.js’) 或 import(‘./a.js’) 方式引入模块，就可以实现模块的动态加载。

// entry1.js
require('a.js')
require('b.js')

// entry2.js
require('c.js')
require.ensure([], function(require){
  require('./async-d.js');
});

// async-d.js
require('e.js')

在 entry1 中，以同步方式引入 a.js、b.js；entry2以异步方式引入 async-d.js 模块；在async-d.js 中以同步方式引入 e.js 模块。对应的模块依赖如：

生成的dist目录如下：(基于异步模块的 chunk 通常称之为「Async chunk」)

异步生成的chunk ，chunk间会形成父子关系。引用者(上例 entry-2)需要在特定场景下使用被引用者(上例 async-d)，两者间存在单向依赖关系，在 WebPack 中称引用者为 parent、被引用者为 child。

运行时，WebPack 在 entry2 中使用 promise 及 WebPack_require.e 方法异步载入并运行文件 async-d-chunk.js ，从而实现动态加载。

3. Runtime 分包

WebPack 5 之后支持根据 entry.runtime 配置单独打包运行时代码。

除业务代码外，WebPack 编译产物中还需要包含一些用于支持 WebPack 模块化、异步加载等特性的支撑性代码，这类代码在 WebPack 中被统称为 runtime。举个例子，产物中通常会包含如下代码：

/******/ (() => { // webpackBootstrap
/******/var __webpack_modules__ = ({

  /***/"./src/entry1.js":
    /*!***********************!*\
!*** ./src/entry1.js ***!
\***********************/
    /***/(() => {

      eval("\n\n//# sourceURL=webpack://webpack-make/./src/entry1.js?");

      /***/ })

  /******/  });
/************************************************************************/
/******/
/******/// startup
/******/// Load entry module and return exports
/******/// This entry module can't be inlined because the eval devtool is used.
/******/var __webpack_exports__ = {};
/******/  __webpack_modules__["./src/entry1.js"]();
/******/
/******/ })()
;

编译时，WebPack 会根据业务代码决定输出那些支撑特性的运行时代码，例如：

需要 WebPack_require__.f 、__WebPack_require.r 等功能实现最起码的模块化支持

如果用到动态加载特性，则需要写入__WebPack_require__.e函数

如果用到 Module Federation 特性，则需要写入__WebPack_require__.o函数等等

虽然每段运行时代码可能都很小，但随着特性的增加，最终结果会越来越大，特别对于多 entry 应用，在每个入口都重复打包一份相似的运行时代码显得有点浪费，为此 WebPack 5 专门提供了 entry.runtime 配置项用于声明如何打包运行时代码。用法上只需在 entry 项中增加字符串形式的 runtime 值，例如：

module.exports = {
  entry: {
    entry1: { import: "./src/entry1", runtime: "solid-runtime" },
  }
};

WebPack 执行完 entry、异步模块分包后，开始遍历 entry 配置判断是否带有runtime属性，如果有则创建以runtime值为名的 chunk，生成的dist目录如下：

在多 entry 场景中，只要为每个 entry 都设定相同的 runtime 值，WebPack 运行时代码最终就会集中写入到同一个 chunk，例如对于如下配置：

module.exports = {
  entry: {
    entry1: { import: './src/entry1', runtime: 'solid-runtime' },
    entry2: { import: './src/entry2', runtime: 'solid-runtime' }
  }
};

生成的dist目录如下：

默认分包规则的问题

默认分包规则最大的问题是无法解决模块重复，如果多个 chunk 同时包含同一个 module，那么这个 module 会被不受限制地重复打包进这些 chunk。对最终产物可能造成不必要的性能损耗。

先来举个简单的栗子，wepack 设置中有 3 个入口文件：a.js、b.js 和 c.js，每个入口文件都同步 import 了 m1.js，不设置 splitChunks，使用 webpack-bundle-analyzer 插件用来查看输出文件的内容，打包输出是这样的：

从分析图中可以比较直观的看出，三个输出 bundle 文件中都包含了 m1.js 文件，这说明有重复的模块代码。

WebPack 会将所有代码构建成一个单独的包，这在小型项目通常不会有明显的性能问题，但伴随着项目的推进，包体积逐步增长可能会导致应用的响应耗时越来越长。归根结底这种将所有资源打包成一个文件的方式存在两个弊端：

​ ● 「资源冗余」：客户端必须等待整个应用的代码包都加载完毕才能启动运行，但可能用户当下访问的内容只需要使用其中一部分代码

​ ● 「缓存失效」：将所有资源达成一个包后，所有改动 —— 即使只是修改了一个字符，客户端都需要重新下载整个代码包，缓存命中率极低

这些问题都可以通过对产物做适当的分解拆包解决，例如 node_mopdules 中的资源通常变动较少，可以抽成一个独立的包，那么业务代码的频繁变动不会导致这部分第三方库资源被无意义地重复加载。为此，WebPack 专门提供了 SplitChunkslugin 插件，用于实现产物分包。

splitChunks 的目的就是用来把重复的模块代码分离到单独的文件，以异步加载的方式来节省输出文件的体积。splitChunks 的配置项很多而且感觉官方文档的一些描述不是很清楚，下面通过一些重点配置属性和场景解释来帮助大家理解和弄懂如何配置 splitChunks。为方便理解和简单演示，webpack 和 splitChunks 的初始设置如下：

const path = require('path');
const BundleAnalyzerPlugin =
  require('webpack-bundle-analyzer').BundleAnalyzerPlugin;

module.exports = {
  mode: 'development',
  entry: {
    a: './src/a.js',
    b: './src/b.js',
    c: './src/c.js',
  },
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: '[name].bundle.js',
    clean: true,
  },
  optimization: {
    splitChunks: {
      chunks: 'async',

      // 生成 chunk 的最小体积（以 bytes 为单位）。
      // 因为演示的模块比较小，需要设置这个。
      minSize: 0,
    },
  },
  plugins: [new BundleAnalyzerPlugin()],
};

chunks

splitChunks.chunks 的作用是指示采用什么样的方式来优化分离 chunks。SplitChunksPlugin 默认只对 Async Chunk 生效，开发者也可以通过 WebPack.config.js 调整作用范围，该配置项有三种常用的取值：async、initial 和 all，async 是默认值，接下来分别看下这三种设置的区别。

1. async

chunks: ‘async’ 只对 Async Chunk 生效，意思是只选择通过 import() 异步加载的模块来分离 chunks。举个例子，还是三个入口文件 a.js、b.js 和 c.js，有两个模块文件 m1.js 和 m2.js，三个入口文件的内容如下：

// a.js
import('./utils/m1');
import './utils/m2';

console.log('some code in a.js');

// b.js
import('./utils/m1');
import './utils/m2';

console.log('some code in b.js');

// c.js
import('./utils/m1');
import './utils/m2';

console.log('some code in c.js');

这三个入口文件对于 m1.js 都是异步导入，m2.js 都是同步导入。打包输出结果如下：

对于异步导入，splitChunks 分离出 chunks 形成单独文件来重用，而对于同步导入的相同模块没有处理，这就是 chunks: ‘async’ 的默认行为。

2. initial

只对 Async Chunk 生效，把 chunks 的值改为 initial 后，再来看下输出结果：

同步的导入也会分离出来了，效果挺好的。这就是 initial 与 async 的区别：同步导入的模块也会被选中分离出来。

3. all

我们加入一个模块文件 m3.js，并对入口文件作如下更改：

// a.js
import('./utils/m1');
import './utils/m2';
import './utils/m3'; // 新加的。

console.log('some code in a.js');

// b.js
import('./utils/m1');
import './utils/m2';
import('./utils/m3'); // 新加的。

console.log('some code in b.js');

// c.js
import('./utils/m1');
import './utils/m2';

console.log('some code in c.js');

有点不同的是 a.js 中是同步导入 m3.js，而 b.js 中是异步导入。保持 chunks 的值为 initial，输出如下：

可以看到 m3.js 单独输出的那个 chunks 是 b 中异步导入的，a 中同步导入的没有被分离出来。也就是在 initial 设置下，就算导入的是同一个模块，但是同步导入和异步导入是不能复用的。

把 chunks 设置为 all，再导出看看：

不管是同步导入还是异步导入，m3.js 都分离并重用了。所以 all 在 initial 的基础上，更优化了不同导入方式下的模块复用。

我们看到 async、initial 和 all 类似层层递进的模块复用分离优化，所以如果考虑体积最优化的输出，那就设 chunks 为 all。

根据 Module 使用频率分包

按 Module 被 Chunk 引用的次数决定是否进行分包，可通过以下方式设定最小引用次数，例如：

module.exports = {
  //...
  optimization: {
    splitChunks: {
      chunks： 'all',
      minChunks: 2, // 引用次数<=2的模块不进行分包
      },
    },
  }
};

生成的dist目录如下：

限定分包数量

在满足 minChunks 基础上，还可以通过 maxInitialRequests / maxAsyncRequests 配置项限定分包数量，配置项语义：

​ ● maxInitialRequests：用于设置 Initial Chunk 最大并行请求数

​ ● maxAsyncRequests：用于设置 Async Chunk 最大并行请求数

这里所说的“请求数”，是指加载一个 Chunk 时所需同步加载的分包数。例如对于一个 Chunk A，如果根据分包规则(如模块引用次数、第三方包)分离出了若干子 Chunk A¡，那么请求 A 时，浏览器需要同时请求所有的 A¡，此时并行请求数等于 ¡ 个分包加 A 主包，即 ¡+1。

1. maxInitialRequests

maxInitialRequests 表示入口的最大并行请求数。规则如下：

​ ● 入口文件本身算一个请求。

​ ● import() 异步加载不算在内。

​ ● 如果同时有多个模块满足拆分规则，但是按 maxInitialRequests 的当前值现在只允许再拆分一个，选择容量更大的 chunks。

举个栗子，webpack 设置如下：

const path = require('path');
const BundleAnalyzerPlugin =
  require('webpack-bundle-analyzer').BundleAnalyzerPlugin;

module.exports = {
  mode: 'development',
  entry: {
    a: './src/a.js',
  },
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: '[name].bundle.js',
    clean: true,
  },
  optimization: {
    splitChunks: {
      chunks: 'all',
      minSize: 0,
      maxInitialRequests: 2,
      cacheGroups: {
        vendors: {
          test: /[\\/]node_modules[\\/]/,
          priority: -10,
          reuseExistingChunk: true,
          name: 'vendors',
        },
        default: {
          test: /[\\/]utils[\\/]/,
          priority: -20,
          reuseExistingChunk: true,
          name: 'utils',
        },
      },
    },
  },
  plugins: [new BundleAnalyzerPlugin()],
};

入口文件内容如下：

// a.js
import React from 'react';
import './utils/m1';

console.log('some code in a.js');

打包输出结果如下：

按照 maxInitialRequests = 2 的拆分过程如下：

​ ● a.bundle.js 算一个文件。

​ ● vendors.bundle.js 和 utils.bundle.js 都可以拆分，但现在还剩一个位，所以选择拆分出 vendors.bundle.js。

把 maxInitialRequests 的值设为 3，结果如下：

再来考虑另外一种场景，入口依然是 a.js 文件，a.js 的内容作一下变化：

// a.js
import './b';

console.log('some code in a.js');

// b.js
import React from 'react';
import './utils/m1';

console.log('some code in b.js');

调整为 a.js 同步导入了 b.js，b.js 里再导入其他模块。这种情况下 maxInitialRequests 是否有作用呢？可以这样理解，maxInitialRequests 是描述的入口并行请求数，上面这个场景 b.js 会打包进 a.bundle.js，没有异步请求；b.js 里面的两个导入模块按照 cacheGroups 的设置都会拆分，那就会算进入口处的并行请求数了。

比如 maxInitialRequests 设置为 2 时，打包输出结果如下：

设置为 3 时，打包输出结果如下：

2. maxAsyncRequests

maxAsyncRequests 的意思是用来限制异步请求中的最大并发请求数。规则如下：

​ ● import() 本身算一个请求。

​ ● 如果同时有多个模块满足拆分规则，但是按 maxAsyncRequests 的当前值现在只允许再拆分一个，选择容量更大的 chunks。

还是举个栗子，webpack 配置如下：

const path = require('path');
const BundleAnalyzerPlugin =
  require('webpack-bundle-analyzer').BundleAnalyzerPlugin;

module.exports = {
  mode: 'development',
  entry: {
    a: './src/a.js',
  },
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: '[name].bundle.js',
    clean: true,
  },
  optimization: {
    splitChunks: {
      chunks: 'all',
      minSize: 0,
      maxAsyncRequests: 2,
      cacheGroups: {
        vendors: {
          test: /[\\/]node_modules[\\/]/,
          priority: -10,
          reuseExistingChunk: true,
          name: 'vendors',
        },
        default: {
          test: /[\\/]utils[\\/]/,
          priority: -20,
          reuseExistingChunk: true,
          name: 'utils',
        },
      },
    },
  },
  plugins: [new BundleAnalyzerPlugin()],
};

入口及相关文件内容如下：

// a.js
import ('./b');

console.log('some code in a.js');

// b.js
import React from 'react';
import './utils/m1';

console.log('some code in b.js');

这个时候是异步导入 b.js 的，在 maxAsyncRequests = 2 的设置下，打包输出结果如下：

按照规则：

​ ● import(‘.b’) 算一个请求。

​ ● 按 chunks 大小再拆分 vendors.bundle.js。

最后 import ‘./utils/m1’ 的内容留在了 b.bundle.js 中。如果将 maxAsyncRequests = 3 则输出如下：

这样 b.js 中导入的 m1.js 也被拆分出来了。实际情况中，我们可以根据需求来调整 maxInitialRequests 和 maxAsyncRequests，个人觉得默认设置已经够用了。

限制分包体积数

在满足 minChunks 与 maxAsyncRequests 的基础上，SplitChunksPlugin 还会进一步判断 Chunk 包大小决定是否分包，这一规则相关的配置项非常多：

​ ● minSize：超过这个尺寸的 Chunk 才会正式被分包

​ ● maxSize：超过这个尺寸的 Chunk 会尝试继续做分包

​ ● maxAsyncSize：与maxSize 功能类似，但只对异步引入的模块生效

​ ● maxInitialSize：与maxSize 类似，但只对entry 配置的入口模块生效

​ ● enforceSizeThreshold：超过这个尺寸的 Chunk 会被强制分包，忽略上述其它 size 限制

结合前面介绍的两种规则，SplitChunksPlugin 的主体流程如下：

​ \1. SplitChunksPlugin 尝试将命中 minChunks 规则的 Module 统一抽到一个额外的 Chunk 对象；

​ \2. 判断该 Chunk 是否满足 maxInitialRequests 阈值，若满足则进行下一步

​ \3. 判断该 Chunk 资源的体积是否大于上述配置项 minSize 声明的下限阈值；

​ \4. 如果体积「小于」 minSize 则取消这次分包，对应的 Module 依然会被合并入原来的 Chunk

​ \5. 如果 Chunk 体积「大于」minSize 则判断是否超过 maxSize、maxAsyncSize、maxInitialSize 声明的上限阈值，如果超过则尝试将该 Chunk 继续分割成更小的部分

虽然 maxSize 等上限阈值逻辑会产生更多的包体，但缓存粒度会更小，命中率相对也会更高，配合持久缓存与 HTTP 2 的多路复用能力，网络性能反而会有正向收益。

以上述模块为例

若此时 minChunks 大于 2，且 maxInitialRequests 也大于 2，如果 common 模块的体积大于上述说明的 minSize 配置项则分包成功，common 会被分离为单独的 Chunk，否则会被合并入原来的 3 个 Chunk。

优先级顺序：maxInitialRequests/maxAsyncSize < maxSize < minSize ，命中 enforceSizeThreshold 阈值的 Chunk 会直接跳过这些属性判断，强制进行分包。

cacheGroups

通过 cacheGroups，可以自定义 chunk 输出分组。设置 test 对模块进行过滤，符合条件的模块分配到相同的组。

1. splitChunks 默认分组

WebPack 提供了两个开箱即用的 cacheGroups ，分别命名为 default 与 defaultVendors ，默认配置：

module.exports = {
  //...
  optimization: {
    splitChunks: {
      cacheGroups: {
        default: {
          idHint: "",
          reuseExistingChunk: true,
          minChunks: 2,
          priority: -20
        },
        defaultVendors: {
          idHint: "vendors",
          reuseExistingChunk: true,
          test: /[\\/]node_modules[\\/]/i,
          priority: -10
        }
      },
    },
  },
};

这两个配置组能帮助我们：

​ ● defaultVendors将所有 node_modules 中的资源单独打包到 vendors-xxx-xxx.js 命名的产物

​ ● 对引用次数大于等于 2 的模块，也就是被多个 Chunk 引用的模块，单独打包

开发者也可以将默认分组设置为 false，关闭分组配置，例如：

module.exports = {
  //...
  optimization: {
    splitChunks: {
      cacheGroups: {
        default: false
      },
    },
  },
};

2. 自定义分组

我们改下配置，设置下将 node_modules 下的模块全部分离并输出到 vendors.bundle.js 文件中：

const path = require('path');
const BundleAnalyzerPlugin =
  require('webpack-bundle-analyzer').BundleAnalyzerPlugin;

module.exports = {
  mode: 'development',
  entry: {
    a: './src/a.js',
    b: './src/b.js',
    c: './src/c.js',
  },
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: '[name].bundle.js',
    clean: true,
  },
  optimization: {
    splitChunks: {
      chunks: 'all',
      minSize: 0,
      cacheGroups: {
        vendors: {
          test: /[\\/]node_modules[\\/]/,
          priority: -10,
          reuseExistingChunk: true,
          name: 'vendors',
        },
      },
    },
  },
  plugins: [new BundleAnalyzerPlugin()],
};

入口文件内容如下：

// a.js
import React from 'react';
import ReactDOM from 'react-dom';

console.log('some code in a.js');

// b.js
import React from 'react';

console.log('some code in b.js');

// c.js
import ReactDOM from 'react-dom';

console.log('some code in c.js');

输出结果如下：

所以根据实际的需求，我们可以利用 cacheGroups 把一些通用业务模块分成不同的分组，优化输出的拆分。

举个栗子，我们现在输出有两个要求：

​ \1. node_modules 下的模块全部分离并输出到 vendors.bundle.js 文件中。

​ \2. utils/ 目录下有一系列的工具模块文件，在打包的时候都打到一个 utils.bundle.js 文件中。

调整 webpack 中的设置如下：

const path = require('path');
const BundleAnalyzerPlugin =
  require('webpack-bundle-analyzer').BundleAnalyzerPlugin;

module.exports = {
  mode: 'development',
  entry: {
    a: './src/a.js',
    b: './src/b.js',
    c: './src/c.js',
  },
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: '[name].bundle.js',
    clean: true,
  },
  optimization: {
    splitChunks: {
      chunks: 'all',
      minSize: 0,
      cacheGroups: {
        vendors: {
          test: /[\\/]node_modules[\\/]/,
          priority: -10,
          reuseExistingChunk: true,
          name: 'vendors',
        },
        default: {
          test: /[\\/]utils[\\/]/,
          priority: -20,
          reuseExistingChunk: true,
          name: 'utils',
        },
      },
    },
  },
  plugins: [new BundleAnalyzerPlugin()],
};

入口文件调整如下：

// a.js
import React from 'react';
import ReactDOM from 'react-dom';
import('./utils/m1');
import './utils/m2';

console.log('some code in a.js');

// b.js
import React from 'react';
import './utils/m2';
import './utils/m3';

console.log('some code in b.js');

// c.js
import ReactDOM from 'react-dom';
import './utils/m3';

console.log('some code in c.js');

输出如下：

cacheGroups 还支持一些与分组逻辑强相关的属性，包括：

​ ● test：接受正则表达式、函数及字符串，所有符合 test 判断的 Module 或 Chunk 都会被分到该组

​ ● type：接受正则表达式、函数及字符串，与 test 类似均用于筛选分组命中的模块，区别是它判断的依据是文件类型而不是文件名，例如 type=’json’ 会命中所有 JSON 文件

​ ● idHint：字符串型，用于设置 Chunk ID，它还会被追加到最终产物文件名中，例如 idHint = ‘vendors’ 时，输出产物文件名形如 vendors-xxx-xxx.js

​ ● priority：数字型，用于设置该分组的优先级，若模块命中多个缓存组，则优先被分到 priority 更大的组

缓存组的作用在于能为不同类型的资源设置更具适用性的分包规则，一个典型场景是将所有 node_modules 下的模块统一打包到 vendors 产物，从而实现第三方库与业务代码的分离。

拆分运行时包

运行时代码的内容由业务代码所使用到的特性决定，例如当 WebPack 检测到业务代码中使用了异步加载能力，就会将异步加载相关的运行时注入到产物中，因此业务代码用到的特性越多，运行时就会越大，有时甚至可以超过 1M 之多。此时，可以将运行时代码拆分到一个独立的 Chunk，实现分包。配置如下：

module.exports = {
  //...
  optimization: {
    runtimeChunk: true,
  }
}

默认值为false，即每个条目块嵌入运行时。

这一配置用于优化持久化缓存, runtime 指的是 WebPack 的运行环境(具体作用就是模块解析, 加载) 和模块信息清单, 模块信息清单在每次有模块变更(hash 变更)时都会变更, 所以我们想把这部分代码单独打包出来, 配合后端缓存策略, 这样就不会因为某个模块的变更导致包含模块信息的模块(通常会被包含在最后一个 bundle 中)缓存失效。optimization.runtimeChunk 就是告诉 WebPack 是否要把这部分单独打包出来。

总结

本文介绍了WebPack中的分包机制。在WebPack中，chunk是输出产物的基本组织单位，根据默认规则，同一个entry下的模块组织成一个chunk，异步模块单独组织为一个chunk，而entry的runtime则单独组织成一个chunk。

然而，默认规则存在模块重复的问题，导致性能损耗。为了解决这个问题，WebPack提供了SplitChunksPlugin插件，通过配置该插件可以优化分包策略。可以根据模块使用频率、分包数量和分包体积等参数来进行分包优化，以提高性能并减少资源冗余和缓存失效问题。

合理配置SplitChunksPlugin插件可以帮助开发者更好地控制和优化WebPack的分包策略，从而提升应用的加载速度和性能表现。

splitChunks 的设置非常复杂。通过以上的规则讲解和举例，相信大家已经明白拆包中几个关键属性的使用，我个人觉得也是官方文档解释比较迷的几个，剩余的其他属性大家可以通过官方文档找到答案。