Webpack SplitChunksPlugin插件研究

柠檬豆腐脑
5,222 阅读10分钟

SplitChunksPlugin初见

自Webpack4以后，代码拆分的插件由CommonsChunkPlugin变成了SplitChunksPlugin，并且不必单独引用，集成到了Webpack之中，通过配置下的optimization.splitChunks和optimization.runtimeChunk就可以控制了。

研究插件经验

前两天研究了一下CommonsChunkPlugin插件，总结出来一条经验，就是要理解这个插件，单纯看如何配置它，是不会懂它的。

先知道它的设计思路，再学习如何配置它。

CommonsChunkPlugin的不足

Webpack4的代码拆分方案，完全换了一个插件，想必设计思路和使用上差别会比较大，实际上也的确如此。

如果是一些简单的重复代码的拆分，CommonsChunkPlugin是可以胜任的。但一些复杂的场景，CommonsChunkPlugin就不行了。

复杂场景举例

我们的项目结构是这样的：

  • 有一个入口文件: index.js
  • 三个用于异步加载的文件：Greeter1.js、Greeter2.js、Greeter3.js
  • Greeter1.js、Greeter2.js引用了React.js，Greeter3.js 引用了Vue.js

使用CommonsChunkPlugin的情况

这时候用Webpack打包此项目，使用CommonsChunkPlugin的话，会将React.js Vue.js这些库打包到vendor.js中。

这样做的问题：

  1. 我们得到了一个非常大的公共Chunk。浏览器加载我们的项目首屏时，会加载入口Chunk index.js和公共Chunk vendor.js。这样对首屏加载速度是不利的。
  2. 某用户只是看Greeter1.js和Greeter2.js这两个Chunk的内容，那么对于他来说，加载Vue.js这样根本用不到的库，只是浪费流量。

理想的拆分和使用情况

不是将React.js、Vue.js打包到同一个vendor Chunk中，而是Webpack通过分析，将React.js打包到一个vendor～Greeter1~Greeter2.js中，将Vue.js打包到一个vendor～Greeter3.js中，这样分别打包公共代码。

然后首屏加载的时候，只加载入口Chunk index.js。等用户查看Greeter1.js的时候，再并行加载Chunk Greeter1.js和Chunk vendor～Greeter1~Greeter2.js。查看Greeter3.js的时候，再并行加载Chunk Greeter3.js和Chunk vendor～Greeter3.js。

这样，解决了上面提到的两个问题，首屏速度和流量浪费。

使用SplitChunksPlugin解决

SplitChunksPlugin就是可以应付上面描述的复杂的拆分情况，比较理想的拆分代码。

搭建实验项目

按照上面描述的，我们新建文件，目录结构如下：

image

文件内容如下：

// index.js 
// 这样就是异步加载Greeter1、2、3 三个Chunk

import(/* webpackChunkName: "Greeter1" */'./Greeter1').then(module => {
  const greeter = module.default
  document.querySelector("#root").appendChild(greeter());
})

import(/* webpackChunkName: "Greeter2" */'./Greeter2').then(module => {
  const greeter = module.default
  document.querySelector("#root").appendChild(greeter());
})

import(/* webpackChunkName: "Greeter3" */'./Greeter3').then(module => {
  const greeter = module.default
  document.querySelector("#root").appendChild(greeter());
})

// Greeter1.js / Greeter2.js
// 我们就这样模拟引用了React。Greeter2.js和Greeter1.js长得一样。

import React from 'react';
console.log(React);

export const greeter = function () {
  var greet = document.createElement('div');
  greet.textContent = "Hi there and greetings!";
  return greet;
};

// Greeter3.js
// Greeter3中引用的是Vue

import Vue from 'vue';
console.log(Vue);

export const greeter = function () {
  var greet = document.createElement('div');
  greet.textContent = "Hi there and greetings!";
  return greet;
};

再来看看关键的Webpack配置

module.exports = {
  entry: {
    index: __dirname + "/app/index.js",
  },
  output: {
    path: __dirname + "/public",//打包后的文件存放的地方
    filename: "[name].js", //打包后输出文件的文件名
    chunkFilename: '[name].js',
  },
  mode: 'development',
  devtool: false,

  optimization: {
    splitChunks: {
      cacheGroups: {
        vendors: {
          test: /[\\/]node_modules[\\/]/,
        },
      }
    }
  },
}

关键的就是optimization下的配置，我们先只关注cacheGroups下的vendors配置。其中的test是分割代码的规则，代表node_modules文件夹下的代码都要被抽离出来。我们运行一下Webpack，看看输出结果：

image

我查看了一下vendor～Greeter1~Greeter2.js文件，里面是React打包后的代码。 我查看了一下vendor～Greeter3.js文件，里面是Vue库打包后的代码。

再利用打包分析，看到：

image

这不就是我们设想的那种理想情况。如果是CommonsChunkPlugin，配置后，只会帮我们打包出一个vendor.js的公共Chunk，而SplitChunksPlugin，我们只是告诉它node_modules下的文件要抽离出来，Webpack就根据项目的引用情况，自动分理处两个公共Chunk vendor～Greeter1~Greeter2.js 和 vendor～Greeter3.js

SplitChunksPlugin设计思路总结

解决复杂场景下的代码拆分问题。针对异步加载中公共模块的拆分，我们只需设置需要被公共打包的代码，SplitChunksPlugin就会自动帮我们按照各异步模块的需求，将公共的Chunk拆分成一些小的公共Chunks。供各异步模块使用。并且这些公共Chunks不会首屏加载，会随着使用使用它们的异步模块，使用时再一同并行加载。

核心思路：根据我们给的规则拆分代码，然后针对拆分的公共Chunk，再次拆分。

拆分出来的Chunk过多，怎么办

到这里，还需一种极端情况，就是被拆分出来的公共Chunk，太多了。Webpack的初衷是合并代码啊，这又给拆碎了。

过多Chunk导致的问题就是浏览器同时需要并发请求太多的js。

同样的SplitChunksPlugin也替我们想到了。

我们再来做一个实验。

复杂场景举例：

  • 有一个入口文件: index.js
  • 有四个用于异步加载的文件：Greeter1.js、Greeter2.js、Greeter3.js、Greeter4.js。
  • 有三个给上四个文件引用的文件：helper1.js、helper2.js、helper3.js（注意这里helper*.js都要大于30k，太小了Webpack不会将其抽离出一个Chunk）。
  • Greeter1.js引用helper1.js，Greeter2.js引用helper2.js，Greeter3.js引用helper3.js，，Greeter4.js同时引用helper1.js、helper2.js、helper3.js。

我画一个图说明情况：

image
G1代表Greeter1.js，h1代表helper.js。依此类推。这样的引用，形成了helper1～3都成了公共模块。需要我们将其提取出Chunk。使用Wepback编译，查看结果：

image

是否跟你预想的一样，出现了三个公共Chunk，也就是我们上图画的公共部分，分别包含了header1~3的代码。再看更直观的效果图：

image

Greeter4.js的问题

浏览器加载Greeter4.js的时候，需要同时加载default~Greeter1~Greeter4.js、default~Greeter2~Greeter4.js、default~Greeter3~Greeter4.js三个Chunk。也就是用户看Greeter4.js时，需并行请求4个js文件。

问题就在于我们把公共包拆的过于细，有可能会出现，加载一个异步Chunk的时候，需要同时并且请求很多的公共Chunk，这不是我们想看到的，为此，SplitChunksPlugin提供给我们一个属性maxAsyncRequests，限制最大并行请求数。

目前的最大的并行请求数是加载Greeter4.js时的4，我们设置成3，看看什么效果：

optimization: {
    splitChunks: {
      maxAsyncRequests: 3, // 在此设置
      cacheGroups: {
        vendors: {
          test: /[\\/]node_modules[\\/]/,
          priority: -10,
        },
        default: {
          minChunks: 2,
          priority: -20,
          reuseExistingChunk: true
        }
      }
    }
  },

运行webpack，效果如下:

image

Greeter4将helper3.js打到一个Chunk里，然后helper1、helper2单独打包，这样Greeter4的并行请求数等于3，符合预期。

同样的将helper3.js同样被Greeter3.js引用，所以也打包到了Greeter3中，造成了重复打包helper3。为了减少并且请求数，就会导致一定程度的重复打包，我们要做的，就是通过配置在平衡并且请求数和重复打包率上做一个平衡。

总的来说SplitChunksPlugin还是很智能啊，我们只是提出要求（并行请求数要小于等于3），它就会基于此条件为我们的进行拆包和组合包。

SplitChunksPlugin默认配置

即使我们不写optimization，Webpack也会帮助我们进行代码拆分，相当于我们写了如下的配置：

splitChunks: {
    chunks: "async", // 默认只处理异步chunk的配置
    minSize: 30000, // 如果模块的最小体积小于30，就不拆分它
    minChunks: 1, // 模块的最小被引用次数
    maxAsyncRequests: 5, // 异步加载Chunk时的最大并行请求数
    maxInitialRequests: 3, // 入口Chunk的最大并行请求数
    automaticNameDelimiter: '~', // 文件名的连接符
    name: true, // 此处写成false，公共块就不会是default~Greeter1~Greeter4.js了，而是0.js这样命名Chunk。
    cacheGroups: { // 缓存组，拆分Chunk的规则
        vendors: {
            test: /[\\/]node_modules[\\/]/,
            priority: -10, // 此数越大，越优先匹配
        },
        default: {
            minChunks: 2, // CommonsChunkPlugin的minChunks既可以传方法，也可以传数字，现在只可以传数字了，如果你想传方法，用test属性
            priority: -20,
            reuseExistingChunk: true //  配置项允许重用已经存在的代码块而不是创建一个新的代码块。这句我不懂，有知道的小伙伴麻烦告诉我一下
        }
    }
}

可以看到默认配置只对异步加载的Chunk有效，原因是配置了 chunks: "async"。

以下是默认配置的描述：

  • 被共享的代码块或者来自node_modules文件夹
  • 被分割的代码块要大于30kb(在min+giz之前)
  • 按需加载代码块的请求数量应该<=5
  • 页面初始化时加载代码块的请求数量应该<=3

这些描述分别对应了上面哪条配置，相信大家都清楚了。如果没有经过分析，这些描述真是让人摸不着头脑。

maxInitialRequests

maxInitialRequests字段我们还没有解释，看字段名字应该是初始化时，也就是针对入口Chunk的分割吧，于是我做了如下配置：

module.exports = {
  entry: {
    Greeter1: __dirname + "/app/Greeter1.js",
    Greeter2: __dirname + "/app/Greeter2.js",
    Greeter3: __dirname + "/app/Greeter3.js",
    Greeter4: __dirname + "/app/Greeter4.js",
  },
  output: {
    path: __dirname + "/public",//打包后的文件存放的地方
    filename: "[name].js", //打包后输出文件的文件名
    chunkFilename: '[name].js',
  },
  mode: 'development',
  devtool: false,

  optimization: {
    splitChunks: {
      chunks: "initial", // 默认只处理异步chunk的配置
      maxInitialRequests: 3, // 一个入口最大并行请求数
      cacheGroups: { // 缓存组
        vendors: {
          test: /[\\/]node_modules[\\/]/,
          priority: -10
        },
        default: {
          minChunks: 2,
          priority: -20,
          reuseExistingChunk: true
        }
      }
    }
  },
}

我们来看打包效果：

image

我将maxInitialRequests调成5，再来看打包效果：

image

打包的结果，和我们分析异步Chunk的提取策略一致，限制为5的时候，即使是Greeter4.js的最大并且请求数才是4，所以可以尽情的拆包。但限制为3的时候，Webpack就不把helper3.js单独拆成一个公共Chunk了，而是分别打包到引用了它的Greeter4.js和Greeter3.js里，以此来限制Greeter4这个入口Chunk被加载时，并行请求为3。可以说maxInitialRequests就是 针对多入口限制拆包数量的maxAsyncRequests。

拆分runtime的代码

说了这么多，还没有提到拆分runtime呢。SplitChunksPlugin拆分runtime只需配置一个属性，如下：

 optimization: {
    runtimeChunk: true,
    splitChunks: {
      chunks: "initial", // 默认只处理异步chunk的配置
      minSize: 30000, // 如果模块的最小体积小于30，就不拆分它
      minChunks: 1, // 模块的最小被引用次数
      maxAsyncRequests: 5, // 按需加载的最大并行请求数
      maxInitialRequests: 5, // 一个入口最大并行请求数
      automaticNameDelimiter: '~', // 文件名的连接符
      name: true,
      cacheGroups: { // 缓存组
        vendors: {
          test: /[\\/]node_modules[\\/]/,
          priority: -10
        },
        default: {
          minChunks: 2,
          priority: -20,
          reuseExistingChunk: true
        }
      }
    }
  },

我这里还是沿用上一个例子，打包结果如下：

image

很有意思，针对我们四个入口文件，分别生成了四个文件，runtime~Greeter1到4。这也符合预期，使用哪个入口的代码，就也加载它对应的runtime文件。

让我们回到最初

现在，我们还是回到最初的一个简单的例子，结束我们今天的研究。

基本场景

不考虑异步加载模块，只是分离业务代码，第三方库代码和runtime代码。

配置

入口文件index.js，里面只引用了react。 配置如下：


module.exports = {
  entry: {
    index: __dirname + "/app/index.js",
  },
  output: {
    path: __dirname + "/public",//打包后的文件存放的地方
    filename: "[name].js", //打包后输出文件的文件名
    chunkFilename: '[name].js',
  },
  mode: 'development',
  devtool: false,

  optimization: {
    runtimeChunk: true,
    splitChunks: {
      chunks: "initial", 
      automaticNameDelimiter: '~',  
      name: true,
      cacheGroups: { // 缓存组
        vendors: {
          test: /[\\/]node_modules[\\/]/,
        },
      }
    }
  },
}

打包结果

image

我们看到react是第三方库，提取到了vendors~index.js中，runtime代码，提取到了runtime-index.js，业务代码，就是index.js。

结束语

Webpack的官方文档，没有解释的那么清楚，对于Webpack的学习，需要多多动手，在实践中，帮助我们学习体会Webpack。

SplitChunksPlugin要理解起来还是稍微复杂一点的，它的设计就是为了搞定复杂的拆分情况。但摸清它的原理后，发现它还是很强大的，通过几项配置，就可以完成复杂情况下的代码拆分。

avatar
文章
阅读
粉丝