使用Webpack的splitChunks功能来拆分代码 (九)

使用Webpack的splitChunks功能来拆分代码

Webpack 代码拆分方式

在Webpack中，总共提供了三种方式来实现代码拆分（Code Splitting）：

Entry配置：通过配置多个entry文件来实现；

动态加载（按需加载）：通过写代码时主动使用import()或者require.ensure来动态加载；

抽取公共代码：使用splitChunks配置来提取公共代码。

这里我们主要讲的是通过splitChunks提取公共代码，在讲解之前，再来复习下webpack中三个重要的概念：module/chunks/bundle

Module:就是javascript的模块，简单来说就是你通过Import/require语句引入的代码，也包括css/图片等资源

chunk：chunk 是 webpack 根据功能拆分出来的，chunk 包含着 module，可能是一对多也可能是一对一，chunk 包含三种情况，就是上面介绍的三种实现代码拆分的情况。

bundle：bundle 是 webpack 打包之后的各个文件，一般就是和 chunk 是一对一的关系，bundle 就是对 chunk 进行编译压缩打包等处理之后的产出。

记住这些，后面会用到，下面开始 splitChunks 配置。

splitChunks 默认配置

由于 Webpack 做到了开箱即用，所以splitChunks是有默认配置的：

module.exports = {

    // ...

    optimization: {

        splitChunks: {

            chunks: 'async', // 三选一： "initial" | "all" | "async" (默认)  all同步和异步都可以 async异步加载

            minSize: 30000, // 最小尺寸，30K，development 下是10k，越大那么单个文件越大，chunk 数就会变少（针对于提取公共 chunk 的时候，不管再大也不会把动态加载的模块合并到初始化模块中）当这个值很大的时候就不会做公共部分的抽取了

            maxSize: 0, // 文件的最大尺寸，0为不限制，优先级：maxInitialRequest/maxAsyncRequests < maxSize < minSize

            minChunks: 1, // 默认1，被提取的一个模块至少需要在几个 chunk 中被引用，这个值越大，抽取出来的文件就越小

            maxAsyncRequests: 5, // 在做一次按需加载的时候最多有多少个异步请求，为 1 的时候就不会抽取公共 chunk 了

            maxInitialRequests: 3, // 针对一个 entry 做初始化模块分隔的时候的最大文件数，优先级高于 cacheGroup，所以为 1 的时候就不会抽取 initial common 了

            automaticNameDelimiter: '~', // 打包文件名分隔符

            name: true, // 拆分出来文件的名字，默认为 true，表示自动生成文件名，如果设置为固定的字符串那么所有的 chunk 都会被合并成一个

            cacheGroups: {

                vendors: {

                    test: /[\\/]node_modules[\\/]/, // 正则规则，如果符合就提取 chunk

                    priority: -10 // 缓存组优先级，当一个模块可能属于多个 chunkGroup，这里是优先级

                },

                default: {

                    minChunks: 2,

                    priority: -20, // 优先级

                    reuseExistingChunk: true // 如果该chunk包含的modules都已经另一个被分割的chunk中存在，那么直接引用已存在的chunk，不会再重新产生一个

                }

            }

        }

    }

};

 

Tips：上面的默认配置都添加了注释，一些很简单的配置就不再详细介绍，下面主要介绍一些比较难理解并且重要的配置项。

splitChunks默认配置对应的就是 chunk 生成的第二种情况：通过写代码时主动使用import()或者require.ensure来动态加载。

下面来看下使用import()或者require.ensure来写代码，在 Webpack 打包的时候有什么不同。

创建index.js，使用import()动态加载react模块，同时为了方便跟踪产出物，在这里使用了 webpack 的魔法注释，保证输出的 bundle 名称，后面也使用这种方式。内容如下：

import(/* webpackChunkName: "react" */ 'react');

添加webpack.config.js，内容如下：

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

module.exports = {

    mode: 'production',

    entry: {

        main: './default/index.js'

    },

    plugins: [new BundleAnalyzerPlugin()]

};

 

splitChunks中的chunks是一个很重要的配置项，表示从哪些 chunks 里面抽取代码，chunks的三个值有："initial"、 "all"、 "async"，默认就是是async。

为了理解splitChunks.chunks三个值的差异，下面通过实例来帮助我们理解。首先创建两个文件a.js和b.js：

// a.js

import react from 'react';

import $ from 'jquery';

import(/* webpackChunkName: "a-lodash" */ 'lodash');

const a = 'I am a.js';

export default a;

// b.js

import $ from 'jquery';

import(/* webpackChunkName: "b-react" */ 'react');

import(/* webpackChunkName: "b-lodash" */ 'lodash');

 

const b = 'I am b.js';

export default b;

Tips：为了方便判断打包出来的 bundle 文件是谁生产的，所以统一使用了魔法注释（magic comments）。

这两个文件的特点是：

react模块被两个文件都引入了，不同的是a.js是同步引入，b.js是动态引入；

jquery模块在两个文件中都被引入，并且都是同步引入；

lodash模块都被两个文件引入，并且都是动态引入。

下面是我们的webpack.config.js文件内容，我们主要修改是chunks的三个值：

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

module.exports = {

    mode: 'development',

    entry: {

        a: './default/a.js',

        b: './default/b.js'

    },

    plugins: [new BundleAnalyzerPlugin()],

    optimization: {

        splitChunks: {

            cacheGroups: {

                vendors: {

                    chunks: 'async', // 这里是我们修改的地方，async|initial|all

                    test: /[\\/]node_modules[\\/]/

                }

            }

        }

    }

};

chunks='async'

当chunks='async'配置下，Webpack 打包 log 和 bundle 分析结果如下：

通过实践观察，在这种模式下：

在a.js和b.js 都同步引入的 jquery 被打包进了各自的 bundle 中没有拆分出来共用，说明在这种配置下只会针对动态引入的的代码进行拆分；

react在a.js和b.js表现不同：

在a.js因为是同步引入的，设置的chunks='async'，所以不被拆分出去；

在b.js是动态引入的，符合chunks='async'的设置，所以被单独拆到vendors~b-react.js;

lodash因为在两个文件都是动态加载的，所以被拆到了vendors~a-lodash.js。

Tips：b.js中的react拆出来的文件名是vendors~b-react.js含有vendors，说明中了名字为vendors的cacheGroups规则。

chunks='initial'

在chunks='initial'配置下，Webpack 打包 log 和 bundle 分析结果如下：

 

initial 即原始的最初的意思，原则就是有共用的情况即发生拆分。首先，动态引入的模块不受影响，它是无论如何都会被拆分出去的。而对于同步引入的代码，如果有多处都在使用，则拆分出来共用，至于共同引用多次会被拆分，是通过minChunks单独配置的，针对这个原则，我们再来看下上面的代码拆分的结果：

因为jquery模块是a.js和b.js共用的代码，所以单独拆除来放到vendors~a~b.js中，vendors~a~b.js文件名来自我们配置的cacheGroups的 key，即vendors和分隔符（automaticNameDelimiter）以及实际被共用的 bundle 的名称，即：a 和 b；

react在b.js因为用的是动态引入，所以被拆成了b-react.js（名字来自于设置的魔法注释）；a.js的react则被拆到了vendors~a.js；

lodash因为在两个文件都是动态加载的，所以被拆到了a-lodash.js（名字来自魔法注释）。

进一步解释：react在b.js拆出来为b-react.js名称，说明中了默认配置（默认配置是chunks='async'），名字来自魔法注释；a.js的react文件名是vendors~a.js，这是因为中了vendors规则，本身a.js的react是同步引入，在这里被拆出来是因为react在 development 模式用的是 dev 版本，体积超过minSize的默认设置30K，所以被拆出来了，观察对应的 webpack 打包 log：Entrypoint a = vendors~a~b.js vendors~a.js a.js 也说明这一点。如果我们把对应的配置，加大minSize到 80K（超过 dev 版本 react 大小），则vendors~a.js 和 a.js会合并在一起了，具体看下图效果：

// 忽略其他，只看cacheGroups

vendors: {

    minSize: 80000,

    chunks: 'initial',

    test: /[\\/]node_modules[\\/]/

}

 

 

chunks='all'

在 chunks='initial' 配置下，虽然a.js和b.js都引入了react，但是因为引入方式不同，而没有拆分在一起，而是各自单独拆封成一个 chunk，要想把react放到一个文件中，就要使用chunks='all'了。下面是chunks='all'的配置结果：

 

通过执行打包结果，跟我们的预期一致，chunks='all'的配置下能够最大程度的生成复用代码，复用代码在 http cache 环境下，多页应用由一个页面跳转到另外一个共用代码的页面，会节省 http 请求，所以一般来说chunks='all'是推荐的方式，但是async和initial也有其存在的必要，理解三者差异，根据项目实际代码拆分需求来配置即可。

Tips：拆分出来的文件名称可以通过output.chunkFilename来指定规则，例如chunkFilename='[name].js'，然后在对应的配置中配置name的具体值，比如 vendors 的 name 指定为foo：vendors.name='foo'

使用 cacheGroups

cacheGroups（缓存组）是 Webpack splitChunks 最核心的配置，splitChunks的配置项都是作用于cacheGroup上的，默认有两个cacheGroup：vendors和default（本文一开始默认配置部分已经贴出），如果将cacheGroup的默认两个分组vendor和default设置为 false，则splitChunks就不会起作用，我们也可以重写这两个默认的配置。

cacheGroups除了拥有默认配置所有的配置项目（例如 minSize、minChunks、name 等）之外，还有三个独有的配置项：test、priority和reuseExistingChunk。 splitChunks.cacheGroup必须同时满足各个配置项的条件才能生效

reuseExistingChunk表示是否使用已有的 chunk，如果为 true 则表示如果当前的 chunk 包含的模块已经被抽取出去了，那么将不会重新生成新的。下面重点说下test和priority

Tips：除了 JavaScript，splitChunks也适用于使用mini-css-extract-plugin插件的 css 配置。

priority

priority配置项的意义就是权重。如果有一个模块满足了多个缓存组的条件就会去按照权重划分，谁的权重高就优先按照谁的规则处理。

在下面的配置中：

optimization: {

    splitChunks: {

        cacheGroups: {

            vendors: {

                chunks: 'initial',

                test: /[\\/]node_modules[\\/]/,

                priority: -10

            },

            default: {

                test: /[\\/]node_modules[\\/]/,

                chunks: 'initial',

                priority: -20

            }

        }

    }

}

虽然给vendors和default除 priority 配置外，其他配置都相同，打包的结果如下：

共用的代码文件名为vendors~cachegroup1~cachegroup2.js，说明中了vendors配置，虽然default和vendors两个都能满足需求，但是 default 的 priority 是 -20 明显小于 vendors 的-10，所以会优先按照 vendors 这个缓存组拆分。

test

cacheGroup.test表示满足这个条件的才会被缓存组命中，取值可以是正则、字符串和函数。正则和字符串很好理解，当test为函数时，比如返回true/false，并且接收两个参数：module和chunks

module：每个模块打包的时候，都会执行test函数，并且传入模块 module 对象，module 对象包含了模块的基本信息，例如类型、路径、文件 hash 等；

chunks：是当前模块被分到哪些chunks使用，module 跟 chunks 关系可能是一对一，也可能是多对一，所以一旦我们使用 chunks 做匹配，那么符合条件的 chunk 内包含的模块都会被匹配到。

module.exports = {

    //...

    optimization: {

        splitChunks: {

            cacheGroups: {

                vendors: {

                    test(module, chunks) {

                        //...

                        return module.type === 'javascript/auto';

                    }

                }

            }

        }

    }

};

举个实际应用场景来说明，前面提到过splitChunks不仅作用于 JavaScript，还可以作用于 CSS，所以类似test=/[\\/]node_modules[\\/]/的写法，实际也会匹配出node_modules中的 CSS，如果我们用到的一个 npm 包引入了自己的 css 文件，那么也会中了拆分逻辑，这时候如果要排除这部分 CSS 或者单独给这部分 CSS 设置自己的

使用test函数针对类型为 js 和 css 分别设置各自的cacheGroup。

另外我们还可以使用test函数实现更细化的匹配，例如：忽略一部分文件等。

cacheGroup规则，有两种方式：

设置更高权重的cacheGroup；

本章节一直在回答一个问题：Webpack 怎么优化。本小节主要介绍 Webpack splitChunks 来拆分代码。