关于javascript:webpack40各个击破4-Javascript-splitChunk

javascript之所以须要打包合并，是因为模块化开发的存在。开发阶段咱们须要将 js 文件离开写在很多系统的文件中，不便调试和批改，但如果就这样上线，那首页的 http 申请数量将间接爆炸。同一个我的项目，他人 2 - 3 个申请就拿到了须要的文件，而你的可能须要 20-30 个，后果就不必多说了。

然而合并脚本可不是 “把所有的碎片文件都拷贝到一个js 文件里”这样就能解决的，不仅要解决命名空间抵触的问题，还须要兼容不同的模块化计划，更别提依据模块之间简单的依赖关系来手动确定模块的加载程序了，所以利用自动化工具来将开发阶段的 js 脚本碎片进行合并和优化是十分有必要的。

代码编译（TS或 ES6 代码的编译）
脚本合并
公共模块辨认
代码宰割
代码压缩混同

babel是 ES6 语法的转换工具，对 babel 不理解的读者能够先浏览《大前端的自动化工厂（3）——Babel》一文进行理解，babel与 webpack 联合应用的办法也在其中做了介绍，此处仅提供根本配置：

webpack.config.js:

...  
module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: [
          {loader: 'babel-loader'}
        ]
      }
    ]
  },
 ...

.babelrc:

{
    "presets":[
        ["env",{
            "targets":{"browsers":"last 2 versions"}
        }
        ]],
    "plugins": ["babel-plugin-transform-runtime"]
}

应用 webpack 对脚本进行合并是十分不便的，毕竟 模块治理 和文件合并 这两个性能是 webpack 最后设计的主要用途，直到波及到分包和懒加载的话题时才会变得复杂。webpack应用起来很不便，是因为实现了对各种不同模块标准的兼容解决，对前端开发者来说，了解这种兼容性实现的形式比学习如何配置 webpack 更为重要。webpack默认反对的是 CommonJs 标准，但同时为了扩大其应用场景，webpack在后续的版本迭代中也退出了对 ES harmony 等其余标准定义模块的兼容解决，具体的解决形式将在下一章 《webpack4.0 各个击破（5）—— Module 篇》 详细分析。

webpack的输入的文件中能够看到如下的局部：

/******/     function __webpack_require__(moduleId) {
/******/
/******/         // Check if module is in cache
/******/         if(installedModules[moduleId]) {/******/             return installedModules[moduleId].exports;
/******/         }
/******/         // Create a new module (and put it into the cache)
/******/         var module = installedModules[moduleId] = {
/******/             i: moduleId,
/******/             l: false,
/******/             exports: {}
/******/         };
/******/
/******/         // Execute the module function
/******/         modules[moduleId].call(module.exports, module, module.exports, __webpack_require__);
/******/
/******/         // Flag the module as loaded
/******/         module.l = true;
/******/
/******/         // Return the exports of the module
/******/         return module.exports;
/******/     }

下面的 __webpack_require__() 办法就是 webpack 的模块加载器，很容易看出其中对于已加载的模块是有对立的 installedModules 对象来治理的，这样就防止了模块反复加载的问题。而公共模块个别也须要从 bundle.js 文件中提取进去，这波及到下一节的“代码宰割”的内容。

1. 为什么要进行代码宰割？

代码宰割最根本的工作是拆散出第三方依赖库，因为第三方库的内容可能很久都不会变动，所以用来标记变动的摘要哈希 contentHash 也很久不变，这也就意味着咱们能够利用本地缓存来防止没有必要的反复打包，并利用浏览器缓存防止冗余的客户端加载。另外当我的项目公布新版本时，如果第三方依赖的 contentHash 没有变动，就能够应用客户端原来的缓存文件（通用的做法个别是给动态资源申请设置一个很大的max-age），晋升访问速度。另外一些场景中，代码宰割也能够提供对脚本在整个加载周期内的加载机会的控制能力。

2. 代码宰割的应用场景

举个很常见的例子，比方你在做一个数据可视化类型的网站，援用到了百度的 Echarts 作为第三方库来渲染图表，如果你将本人的代码和 Echarts 打包在一起生成一个 main.bundle.js 文件，这样的后果就是在一个网速欠佳的环境下关上你的网站时，用户可能须要面对很长时间的白屏，你很快就会想到将 Echarts 从主文件中剥离进去，让体积较小的主文件先在界面上渲染出一些动画或是提示信息，而后再去加载 Echarts，而拆散出的Echarts 也能够从速度更快的 CDN 节点获取，如果加载某个体积宏大的库，你也能够抉择应用懒加载的计划，将脚本的下载机会提早到用户真正应用对应的性能之前。这就是一种人工的代码宰割。

从下面的例子整个的生命周期来看，咱们将本来一次就能够加载完的脚本拆分为了两次，这无疑会减轻服务端的性能开销，毕竟建设 TCP 连贯是一种开销很大的操作，但这样做却能够换来 对渲染节奏的管制和用户体验的晋升 ， 异步模块 和懒加载模块 从宏观上来讲实际上都属于 代码宰割 的领域。code splitting最极其的情况其实就是拆分成打包前的原貌，也就是 源码间接上线。

3. 代码宰割的实质

代码宰割的实质，就是在 “源码间接上线” 和“打包为惟一的脚本 main.bundle.js”这两种极其计划之间寻找一种更符合实际场景的中间状态，用可承受的服务器性能压力减少来换取更好的用户体验。

4. 配置代码宰割

code-splitting技术的配置和应用办法将在下一大节详细描述。

5. 更粗疏的代码宰割

感兴趣的读者能够参考来自 google 开发者社区的文章《Reduce JavaScript Payloads with Code Splitting》自行钻研。

webpack4中曾经内置了 UglifyJs 插件，当打包模式参数 mode 设置为 production 时就会主动开启，当然这不是惟一的抉择，babel的插件中也能提供代码压缩的解决，具体的成果和原理笔者尚未深究，感兴趣的读者能够自行钻研。

webpack4废除了 CommonsChunkPlugin 插件，应用 optimization.splitChunks 和optimization.runtimeChunk来代替，起因能够参考《webpack4：连奏中的进化》一文。对于 runtimeChunk 参数，有的文章说是提取出入口 chunk 中的 runtime 局部，造成一个独自的文件，因为这部分不常变动，能够利用缓存。google 开发者社区的博文是这样形容的：

The runtimeChunk option is also specified to move webpack’s runtime into the vendors chunk to avoid duplication of it in our app code.

splitChunks中默认的代码主动宰割要求是上面这样的：

node_modules 中的模块或其余被反复援用的模块
就是说如果援用的模块来自 node_modules, 那么只有它被援用，那么满足其余条件时就能够进行主动宰割。否则该模块须要被反复援用才持续判断其余条件。（对应的就是下文配置选项中的minChunks 为 1 或 2 的场景）
拆散前模块最小体积上限（默认 30k，可批改）
30k 是官网给出的默认数值，它是能够批改的，上一节中曾经讲过，每一次分包对应的都是服务端的性能开销的减少，所以必须要思考分包的性价比。
对于异步模块，生成的公共模块文件不能超出 5 个（可批改）
触发了懒加载模块的下载时，并发申请不能超过 5 个，对于略微理解过服务端技术的开发者来说，【高并发】和 【压力测试】 这样的关键词应该不会生疏。
对于入口模块，抽离出的公共模块文件不能超出 3 个（可批改）
也就是说一个入口文件的最大并行申请默认不得超过 3 个，起因同上。

splitChunks的在webpack4.0 以上版本中的用法是上面这样的：

module.exports = {
  //...
  optimization: {
    splitChunks: {
      chunks: 'async',// 默认只作用于异步模块，为 `all` 时对所有模块失效,`initial` 对同步模块无效
      minSize: 30000,// 合并前模块文件的体积
      minChunks: 1,// 起码被援用次数
      maxAsyncRequests: 5,
      maxInitialRequests: 3,
      automaticNameDelimiter: '~',// 主动命名连接符
      cacheGroups: {
        vendors: {test: /[\\/]node_modules[\\/]/,
          minChunks:1,// 敲黑板
          priority: -10// 优先级更高
        },
        default: {test: /[\\/]src[\\/]js[\\/]/
          minChunks: 2,// 个别为非第三方公共模块
          priority: -20,
          reuseExistingChunk: true
        }
      },
      runtimeChunk:{name:'manifest'}
    }
  }

注：实例中应用的 demo 及配置文件已放在附件中。

单页面利用
单页面利用只有一个入口文件，splitChunks的次要作用是将援用的第三方库拆分进去。从上面的分包后果就能够看出，node_modules中的第三方援用被拆散了进去，放在了 vendors-main.[hash].js 中。

多页面利用

多页面利用的情景稍显简单，以《webpack4：连奏中的进化》一文中的例子进行代码宰割解决，源码的依赖关系为：
```
entryA.js: vue vuex component10k
entryB.js: vue axios component10k
entryC.js: vue vuex axios component10k
```
通过代码宰割后失去的包如下图所示：

splitChunks提供了更准确的宰割策略，然而仿佛无奈间接通过 html-webpack-plugin 配置参数来动静解决宰割后代码的注入问题，因为分包名称是不确定的。这个场景在应用 chunks:'async' 默认配置时是不存在的，因为异步模块的援用代码是不须要以 <script> 标签的模式注入 html 文件的。

当 chunks 配置项设置为 all 或initial时，就会有问题，例如下面示例中，通过在 html-webpack-plugin 中配置 excludeChunks 能够去除 page 和about这两个 chunk，然而却无奈提前排除 vendors-about-page 这个 chunk，因为打包前无奈晓得是否会生成这样一个 chunk。这个场景笔者并没有找到现成的解决方案，对此场景有需要的读者兴许能够通过应用 html-webpack-plugin 的事件扩大 来解决此类场景，也能够应用折中计划，就是第一次打包后记录下新生成的 chunk 名称，按需填写至 html-webpack-plugin 的chunks配置项里。

通过 Bundle Buddy 剖析工具或 webpack-bundle-analyser 插件就能够看到分包前后对于公共代码的抽取带来的影响（图片来自参考文献的博文）：

【1】附加中文件阐明：

webpack.spa.config.js——单页面利用代码宰割配置实例
main.js——单页面利用入口文件
webpack.multi.config.js——多页面利用代码宰割配置实例
entryA.js,entryB.js,entryC.js——多页面利用的 3 个入口

【2】参考文献：《Reduce JavaScript Payloads with Code Splitting》

关于javascript:webpack40各个击破4-Javascript-splitChunk

一. Js 模块化开发

二. Js 文件的个别打包需要

三. 应用 webpack 解决 js 文件

3.1 应用 babel 转换 ES6+ 语法

3.2 脚本合并

3.3 公共模块辨认

3.4 代码宰割

3.5 代码混同压缩

四. 细说 splitChunks 技术

4.1 参数阐明

4.2 参数配置

4.3 代码宰割实例

4.4 后果剖析

五. 参考及附件阐明