没有了CommonsChunkPlugin，咱拿什么来分包

最新推荐文章于 2023-09-21 16:27:40 发布

songluyi

最新推荐文章于 2023-09-21 16:27:40 发布

阅读量8.3k

点赞数

介绍了Webpack 4中取代CommonsChunkPlugin的新配置项optimization.splitChunks和optimization.runtimeChunk的使用方法及机制。详细解释了如何通过配置实现代码块的分割与优化。

webpack 4 移除 CommonsChunkPlugin，取而代之的是两个新的配置项（optimization.splitChunks 和 optimization.runtimeChunk），下面介绍一下用法和机制。

默认方式

webpack模式模式现在已经做了一些通用性优化，适用于多数使用者。

需要注意的是：默认模式只影响按需(on-demand)加载的代码块(chunk)，因为改变初始代码块会影响声明在HTML的script标签。如果可以处理好这些（比如，从打包状态里面读取并动态生成script标签到HTML），你可以通过设置optimization.splitChunks.chunks: "all"，应用这些优化模式到初始代码块(initial chunk)。

webpack根据下述条件自动进行代码块分割：

新代码块可以被共享引用，OR这些模块都是来自node_modules文件夹里面
新代码块大于30kb（min+gziped之前的体积）
按需加载的代码块，最大数量应该小于或者等于5
初始加载的代码块，最大数量应该小于或等于3

为了满足后面两个条件，webpack有可能受限于包的最大数量值，生成的代码体积往上增加。

我们来看一下一些例子：

Example 1

// entry.js
import("./a");

// a.js
import "react-dom";
// ...

结果：webpack会创建一个包含react-dom的分离代码块。当import调用时候，这个代码块就会与./a代码被并行加载。

为什么会这样打包：

条件1：这个代码块是从node_modules来的
条件2：react-dom大于30kb
条件3：按需请求的数量是2（小于5）
条件4：不会影响初始代码请求数量

这样打包有什么好处呢？

对比起你的应用代码，react-dom可能不会经常变动。通过将它分割至另外一个代码块，这个代码块可以被独立缓存起来（假设你在用的是长期缓存策略：chunkhash，records，Cache-Control）

Example 2

// entry.js
import("./a");
import("./b");

// a.js
import "./helpers"; // helpers is 40kb in size
// ...

// b.js
import "./helpers";
import "./more-helpers"; // more-helpers is also 40kb in size
// ...

结果：webpack会创建一个包含./helpers的独立代码块，其他模块会依赖于它。在import被调用时候，这个代码块会跟原始的代码并行加载（译注：它会跟a.js和b.js并行加载）。

为什么会这样打包：

条件1：这个代码块会被两个导入(import)调用依赖（指的是a.js和b.js）
条件2：helpers体积大于30kb
条件3：按需请求的数量是2（小于5）
条件4：不会影响初始代码请求数量

这样打包有什么好处呢？

将helpers代码放在每一个依赖的块里，可能就意味着，用户重复会下载它两次。通过用一个独立的代码块分割，它只需要被下载一次。实际上，这只是一种折衷方案，因为我们为此需要付出额外的一次请求的代价。这就是为什么默认webpack将最小代码块分割体积设置成30kb（译注：太小体积的代码块被分割，可能还会因为额外的请求，拖慢加载性能）。

通过optimizations.splitChunks.chunks: "all"，上面的策略也可以应用到初始代码块上(inital chunks)。代码代码块也会被多个入口共享&按需加载（译注：以往我们使用CommonsChunkPlugin最通常的目的）。

配置

如果想要更深入控制这个按需分块的功能，这里提供很多选项来满足你的需求。

Disclaimer：不要在没有实践测量的情况下，尝试手动优化这些参数。默认模式是经过千挑万选的，可以用于满足最佳web性能的策略。

缓存组（Cache Group）

这项优化可以用于将模块分配到对应的Cache group。

默认模式会将所有来自node_modules的模块分配到一个叫vendors的缓存组；所有重复引用至少两次的代码，会被分配到default的缓存组。

一个模块可以被分配到多个缓存组，优化策略会将模块分配至跟高优先级别（priority）的缓存组，或者会分配至可以形成更大体积代码块的组里。

Conditions

在满足下述所有条件时，那些从相同代码块和缓存组来的模块，会形成一个新的代码块（译注：比如，在满足条件下，一个vendoer可能会被分割成两个，以充分利用并行请求性能）。

有四个选项可以用于配置这些条件：

minSize(默认是30000)：形成一个新代码块最小的体积
minChunks（默认是1）：在分割之前，这个代码块最小应该被引用的次数（译注：保证代码块复用性，默认配置的策略是不需要多次引用也可以被分割）
maxInitialRequests（默认是3）：一个入口最大的并行请求数
maxAsyncRequests（默认是5）：按需加载时候最大的并行请求数。

Naming

要控制代码块的命名，可以用name参数来配置。

注意：当不同分割代码块被赋予相同名称时候，他们会被合并在一起。这个可以用于在：比如将那些多个入口/分割点的共享模块(vendor)合并在一起，不过不推荐这样做。这可能会导致加载额外的代码。

如果赋予一个神奇的值true，webpack会基于代码块和缓存组的key自动选择一个名称。除此之外，可以使用字符串或者函数作为参数值。

当一个名称匹配到相应的入口名称，这个入口会被移除。

Select chunks

通过chunks选项，可以配置控制webpack选择哪些代码块用于分割（译注：其他类型代码块按默认方式打包）。有3个可选的值：initial、async和all。webpack将会只对配置所对应的代码块应用这些策略。

reuseExistingChunk选项允许复用已经存在的代码块，而不是新建一个新的，需要在精确匹配到对应模块时候才会生效。

这个选项可以在每个缓存组（Cache Group）里面做配置。

Select modules

test选项用于控制哪些模块被这个缓存组匹配到。原封不动传递出去的话，它默认会选择所有的模块。可以传递的值类型：RegExp、String和Function

通过这个选项，可以通过绝对资源路径（absolute modules resource path）或者代码块名称(chunk names)来匹配对应模块。当一个代码块名称(chunk name)被匹配到，这个代码块的所有模块都会被选中。

配置缓存组(Configurate cache group)

这是默认的配置：

splitChunks: {
    chunks: "async",
    minSize: 30000,
    minChunks: 1,
    maxAsyncRequests: 5,
    maxInitialRequests: 3,
    name: true,
    cacheGroups: {
        default: {
            minChunks: 2,
            priority: -20,
            reuseExistingChunk: true,
        },
        vendors: {
            test: /[\\/]node_modules[\\/]/,
            priority: -10
        }
    }
}

默认来说，缓存组会继承splitChunks的配置，但是test、priorty和reuseExistingChunk只能用于配置缓存组。

cacheGroups是一个对象，按上述介绍的键值对方式来配置即可，值代表对应的选项：

除此之外，所有上面列出的选择都是可以用在缓存组里的：chunks, minSize, minChunks, maxAsyncRequests, maxInitialRequests, name。

可以通过optimization.splitChunks.cacheGroups.default: false禁用default缓存组。

default缓存组的优先级(priotity)是负数，因此所有自定义缓存组都可以有比它更高优先级（译注：更高优先级的缓存组可以优先打包所选择的模块）（默认自定义缓存组优先级为0）

可以用一些例子来说明：

Example 1

splitChunks: {
    cacheGroups: {
        commons: {
            name: "commons",
            chunks: "initial",
            minChunks: 2
        }
    }
}

这会创建一个commons代码块，这个代码块包含所有被其他入口(entrypoints)共享的代码。

注意：这可能会导致下载额外的代码。

Example 2

splitChunks: {
    cacheGroups: {
        commons: {
            test: /[\\/]node_modules[\\/]/,
            name: "vendors",
            chunks: "all"
        }
    }
}

这会创建一个名为vendors的代码块，它会包含整个应用所有来自node_modules的代码。

注意：这可能会导致下载额外的代码。