最近新起了一个多页项目，之前都未使用 webpack4，于是准备上手实践一下。这篇文章主要就是一些配置介绍，对于正准备使用 webpack4 的同学，可以做一些参考。
webpack4 相比之前的 2 与 3，改变很大。最主要的一点是很多配置已经内置，使得 webpack 能“开箱即用”。当然这个开箱即用不可能满足所有情况，但是很多以往的配置，其实可以不用了。比如在之前，压缩混淆代码，需要增加uglify插件，作用域提升(scope hosting)需要增加ModuleConcatenationPlugin。而在 webpack4 中，只需要设置 mode 为 production即可。当然，如果再强行增加这些插件也不会报错。
所以我建议，如果大家想迁移到 webpack4，还是从 0 开始做加法，参考历史，重新做一个配置。而不是从历史的配置里删删减减，再升级为 webpack4。这样 webpack4 的配置会显得更精简。
打包优化
打包优化主要就是多页应用构建时，对所有页面加载的依赖进行合理打包。这个目前业界都已经有了很多实践，包括 webpack4，也有很多文章介绍。我再补充几个不容易注意的小细节。有些点我不详细介绍，不熟悉 webpack 配置的同学可能会不明白，可以搜索对应关键词，网上肯定有非常详细的文章介绍。
首先，构建多页应用，往往会抽离如下几个 chunk 包：
common：将被多个页面同时引用的依赖包打到一个 common chunk 中。网上大部分教程是被引入两次即打入 common。我建议可以根据自己页面数量来调整，在我的工程中，我设置引入次数超过页面数量的 1/3 时，才会打入 common 包。
dll: 将每个页面都会引用的且基本不会改变的依赖包，如 react/react-dom 等再抽离出来，不让其他模块的变化污染 dll 库的 hash 缓存。
manifest: webpack 运行时(runtime)代码。每当依赖包变化，webpack 的运行时代码也会发生变化，如若不将这部分抽离开来，增加了 common 包 hash 值变化的可能性。
页面入口文件对应的page.js
然后我们会给打出的 chunk 包名，注入 contentHash，以实现最大缓存效果。在我们分 chunk 的过程中，最关键的一个思想就是，每次迭代发布，尽量减少 chunk hash 值的改变。这个在业界也有很多非常多的实践，比如这篇文章：https://github.com/pigcan/blog/issues/9
不过在 webpack4 中，我们不用再增加这么多插件啦，一个 optimization 配置完全就能搞定。
我先贴上我的 webpack 的 optimization 配置，然后我再对其做一些介绍，加深大家印象
const commonOptions = { chunks: 'all', reuseExistingChunk: true } export default { namedChunks: true, moduleIds: 'hashed', runtimeChunk: { name: 'manifest' }, splitChunks: { maxInitialRequests: 5, cacheGroups: { polyfill: { test: /[\\/]node_modules[\\/](core-js|raf|@babel|babel)[\\/]/, name: 'polyfill', priority: 2, ...commonOptions }, dll: { test: /[\\/]node_modules[\\/](react|react-dom)[\\/]/, name: 'dll', priority: 1, ...commonOptions }, commons: { name: 'commons', minChunks: Math.ceil(pages.length / 3), // 至少被1/3页面的引入才打入common包 ...commonOptions } } } }
runtimeChunk
在 webpack4 之前，抽离 manifest，需要使用 CommonsChunkPlugin，配置一个指定 name 属性为'manifest'的 chunk。在 webpack4 中，无需手动引入插件，配置 runtimeChunk 即可。
splitChunks
这个配置能让我们以一定规则抽离想要的包，我们可能会抽好几个包，如 verdor + common，所以 splitChunks 中提供 cacheGroups 字段，cacheGroups 每增加一个 key，就相当于多一个抽包规则。
在网上很多教程中，dll 往往是专门再加一个 webpack 配置，使用 DllPlugin 来构建 dll 库，再在自己项目工程的 webpack 中利用 DllReferencePlugin 来映射 dll 库。虽然这样构建速度会快不少，但是，哎，是真 TM 烦.....
我是一个很怕烦的人，我情愿在 webpack4 中利用 splitChunks，配好规则，再抽离对应的 dll 包。当然这个大家可以自己根据实际情况选择方案。
除了 dll 与 common 两个 chunk，我还加了一个 polyfill。这是因为我们用的某些新的库或者使用某些 ES6+语法(如 async/await)需要 runtime 垫片。比如我工程中使用了 react16，需要增加Map/Set/requestAnimationFrame ()那我必须在 dll 库加载之前增加 polyfill，因此我将所有 core-js 与 babel 引入的包专门打进 polyfill，保证后续加载的 chunk 能执行。priority字段用来配置 chunk 的引入优先级，一般的项目应该都是 polyfill > dll > common > page。
splitChunks 中配置项maxInitialRequests表示在一个入口(entry)中，最大初始请求 chunk 数(不包含按需加载的，即 dom 中 script 引入的 chunk)，默认值是 3。我现在 cacheGroups 中已经有三个，又因为配置了 runtimeChunk，会打出 manifest，故而总共有 4 个 chunk 包，超出了默认 3 个，因此需要重新配置值。
moduleIds