webpack4 splitChunkPlugin配置介紹

webpack4 splitChunkPlugin配置介紹

前言

webpack4刪除了CommonsChunkPlugin插件，它使用內置API optimization.splitChunks和optimization.runtimeChunk,這意味着webpack會默認爲你生成共享的代碼塊，splitchunk的配置很是靈活，讓咱們一塊兒看一下他的配置。 原文閱讀：zhangzippo.github.io/posts/2019/…

基本配置項與commonsChunkPlugin大同小異，下方是啓用mode=production後，splitChunk的默認配置：

splitChunks: {
    chunks: "async",
    minSize: 30000,
    minChunks: 1,
    maxAsyncRequests: 5,
    maxInitialRequests: 3,
    automaticNameDelimiter: '~',
    name: true,
    cacheGroups: {
        vendors: {
            test: /[\\/]node_modules[\\/]/,
            priority: -10
        },
        default: {
            minChunks: 2,
            priority: -20,
            reuseExistingChunk: true
        }
    }
}

複製代碼

cacheGroups中的配置默認會繼承外部的配置，可是有3哥配置是每一個cacheGroup獨有的，分別爲test, priority 和 reuseExistingChunk，test支持正則匹配路徑，priority表示某個文件被命中多個規則時採用哪一個cacheGroup,reuseExistingChunk表示若是當前塊包含已經從主bundle中分離出來的模塊，那麼它將被重用，而不是生成一個新的模塊，通常設置爲 true。從默認配置能夠看出會默認將代碼中從node_modules中引用的的代碼按規則抽離出來。能夠對optimization.splitChunks.cacheGroups.default或者optimization.splitChunks.cacheGroups.verndor爲false以放棄使用默認的配置。

實際上cacheGroups中的配置只是對咱們文件分離的細化配置，咱們主要關心的配置項目主要是chunks, minSize, minChunks, maxAsyncRequests, maxInitialRequests

開始分析

咱們一個配置一個配置的過，首先來看chunks屬性

chunks

默認做用於異步chunk，值爲all/initial/async/function(chunk){}幾類，當值爲function時，第一個參數是遍歷全部入口chunk的chunk模塊，咱們能夠經過判斷chunk的名字來按需處理。咱們這裏主要講前三個配置。爲了咱們後面容易分析，咱們這裏採起一個用例以下圖所示：

咱們新建兩個文件testA.js和testB.js，他們共同靜態引用Vue，共同動態引用qs,testA靜態引用lodash，testB靜態引用lodash. 代碼結構以下： testA.js

import Vue from 'vue'
import lodash from 'lodash'
import('query-string').then(component=>{
    console.log(component)
})
console.log(lodash.add(1))
new Vue({
    el: '#app',
    template: '<h1>qewqwe<h1/>',
})

複製代碼

testB.js

import Vue from 'vue'
import('query-string').then(component=>{
    console.log(component)
})
import('lodash').then(component=>{
    console.log(component)
})
new Vue({
    el: '#app',
    template: '<h1>qewqwe<h1/>',
})

複製代碼

咱們僅切換chunks的配置看看現象：首先是默認的async，咱們經過Bundle Analyzer能夠看到只有異步引入的包被提取了出來

接着咱們設置chunks選項爲all,咱們能夠看到不論是異步引用仍是靜態引用的包都被提取了出來,而且引用方式不一樣的lodash只被提取出了一次（實際上靜態引用被提取出來仍是要知足一些條件的，咱們後面再講）文件命名上，走的是默認配置，靜態引用的包的名字爲verdor加～符號跟引用的包名加chunkhash

接着咱們再看當設置爲initial時的狀況，能夠看到qs被提取，vue被提取，而lodash被提取了兩次，產生了重複的代碼。

minSize與maxSize

這兩個配置成對出現，字面意思就能夠看出來是知足相應大小的包纔會被提取出來，單位是字節，從上面的默認配置中咱們能夠得知，minSize的值爲30000，也就是說小於這個數的包不會被提取而是會被打到引用的文件中去，maxSize與之相反，但優先級小於minSize，另外值得注意的是，這兩個值只對靜態引入的公共包有影響，對於異步引入的包，無論大小多少哪怕minSize設置的很大，也一樣是會被提取出來的，你們能夠自行嘗試。

minChunks

與上面兩個配置同樣，一樣只做用於靜態引入的狀況，控制包被引用的次數來決定是否提取公共包，從上面的默認配置中咱們得知默認是隻要被引用的node_modules中的包就會被提取，當咱們放大爲3時，咱們能夠看到vue並不會被提取出來了。

maxInitialRequests

簡單來說就是每個入口文件打包完成後最多能有多少個模塊組成（1.都打到一塊兒，1以上：能夠拆分，這個數值不包括入口文件（entrys）自己）舉個例子：像剛纔咱們的引用方式，當咱們設置爲1時，咱們能夠看到咱們的html模版中的引用只引用了testA和testB，也就是模版最多引入這兩個文件，其餘都會被合併，當咱們增長以後就會在這兩個入口文件的基礎上增長引入的數量，也就從testA與testB中抽離出了公共代碼。具體現象你們能夠設置完試試看。

maxAsyncRequests

這個配置的現象是最難以琢磨的，我至如今也沒能明白其具體含義，按字面意思理解，我理解爲若是異步引用的包的數量超過了maxAsyncRequests的設置，那麼異步的包就會被合併，然而事實上現象並不是如此，即便設置的很小設置成1，異步引入的包仍是會生成一個個獨立的被提取出來，我嘗試去github上提問，看到做者只回復了一句話：

It limits the requests per import()

可能本人比較愚鈍，尚不能參破其中奧妙

優先級

有時咱們在配置時經常發生不生效或者與預想不一樣的結果，每每時因爲以上的屬性的優先級不一樣形成的，以上屬性的優先級爲：

minSize > maxSize > maxInitialRequest/maxAsyncRequests

參考文章： SplitChunksPlugin | webpack 中文網