webpack CommonsChunkPlugin 和 SplitChunksPlugin 思路

• 废弃CommonsChunkPlugin

  CommonsChunkPlugin的思路（基于父子关系）：即将满足minchunks配置项所设置的条件的模块移到一个新的chunk文件中去，也就是这个新生成的chunk是所有chunk的父亲，在加载孩子chunk时,父亲chunk是必须提前加载的。

    // example:
    entryA:  vue vuex  someComponents.....
    entryB:  vue axios someComponents.....
    entryC: vue vuex axios  someComponents.....
    minchunks: 2 即某个module被引用2次就提取到公共即父亲chunk中
  
    // 产出的chunk
   vendor-chunk: vue vuex axios
   chunkA 到 chunkC: only the corresponding components
  

  带来的问题就是： 对entryA 和 entryB 都有多余的module

       // example:
       entryA:  vue vuex  someComponents.....
       asyncB:  vue axios someComponents.....
       entryC: vue vuex axios  someComponents.....
       minchunks: 2 
       // 产出的chunk
       vendor-chunk: vue vuex
       chunkA: only the corresponding components
       chunkB: vue axios someComponents
       chunkC: axios someComponents
  

  这边的问题就是对异步模块不友好，如果asyncB在entryA中动态引入，则会引入多余module。【问题二：无法优化异步chunk，引入重复代码】

一句话：痛在只能统一抽取到父chunk，造成父chunk过大，不可避免的存在重复引入，引入多余代码

SplitChunksPlugin的思路：
引入chunkGroup的概念,在入口chunk和异步chunk中发现被重复使用的模块，将重复模块以vendor-chunk的形式分离出来，也就是vendor-chunk可能有多个，不再受限于所有chunk中都共同存在的模块

  entryA:  vue vuex  someComponents.....
  entryB:  vue axios someComponents.....
  entryC: vue vuex axios  someComponents.....
  minchunks: 2 
  产出的chunk:
  vendor-chunkA-B-C: vue
  vendor-chunkA-C: vuex
  vendor-chunkB-C: axios
  chunkA: only the corresponding components
  chunkB: only the corresponding components
  chunkC: only the corresponding components

SplitChunksPlugin 能解决CommonsChunkPlugin的问题，
它在production模式下默认开启，但它只默认作用于异步chunk,如果要作用于入口chunk,需要配置 optimization.splitChunks.chunks: 'all'

无标题.png

同时webpack自动split chunks也是有几个限制条件的：
1、新产出的vendor-chunk的大小要大于30kb
2、并行请求vendor-chunk的数量不能超出5个
3、对于entry-chunk,并行加载的vendor-chunk不能超出3个
这些限制可在SplitChunks的默认配置中看到

 splitChunks: {
   chunks: 'async', // 默认只作用于异步模块，‘all’时对所有模块生效， ‘initial’对同步模块有效
   minSize: 30000,
   minChunks: 1,
   maxAsyncRequsets: 5,
   maxInitialRequests: 3
 }

runtimeChunkPlugin：
作用是将包含chunks映射关系的list单独从app.js里提取出来，因为每一个chunk的id基本都是基于内容hash出来的，所以你每次改动都会影响它，如果不把它提取出来的话，等于app.js每次都会改变，缓存就失效了。
在使用 CommonsChunkPlugin的时候，我们也通常把webpack runtime 的基础函数提取出来，单独作为一个chunk,毕竟code splitting想把不变的代码单独抽离出来，方便浏览器缓存，提升加载速度。
其实就是单独分离出webpack的一些运行文件。
wepack4采用了runtimeChunkPlugin，可以将每个entry chunk中的runtime部分的函数分离出来，只需要一个简单的配置

  runtimeChunk: "single"
  // 等价于
  runtimeChunk: {
    name: 'minifest'
  }