一. Js模块化开发

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

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

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

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

三. 应用webpack解决js文件

3.1 应用babel转换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"     ]}

3.2 脚本合并

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

3.3 公共模块辨认

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文件中提取进去，这波及到下一节的“代码宰割”的内容。

3.4 代码宰割

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》 自行钻研。

3.5 代码混同压缩

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

四. 细说splitChunks技术

4.1 参数阐明

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个，起因同上。

4.2 参数配置

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'      }    }  }

4.3 代码宰割实例

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

  • 单页面利用

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

  • 多页面利用

    多页面利用的情景稍显简单，以《webpack4：连奏中的进化》一文中的例子进行代码宰割解决，源码的依赖关系为：

    entryA.js: vue vuex component10kentryB.js: vue axios component10kentryC.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配置项里。

4.4 后果剖析

通过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》