初衷
webpack4出了兩個月，發現大家包括我對splitChunk的使用都還是在摸索階段。我也看了挺多别人的配置demo，都覺得不太滿意或者沒得到太好的解惑，issue 下面的問題也沒什麼人回複，隻能自己操作了，順便記錄下來，如果大家有更好的，歡迎評論區留下位址。
常用參數
- minSize(預設是30000)：形成一個新代碼塊最小的體積
- minChunks（預設是1）：在分割之前，這個代碼塊最小應該被引用的次數（譯注：保證代碼塊複用性，預設配置的政策是不需要多次引用也可以被分割）
- maxInitialRequests（預設是3）：一個入口最大的并行請求數
- maxAsyncRequests（預設是5）：按需加載時候最大的并行請求數。
- chunks (預設是async) ：initial、async和all
- test： 用于控制哪些子產品被這個緩存組比對到。原封不動傳遞出去的話，它預設會選擇所有的子產品。可以傳遞的值類型：RegExp、String和Function
- name(打包的chunks的名字)：字元串或者函數(函數可以根據條件自定義名字)
- priority ：緩存組打包的先後優先級。
如果你對這些配置還是不熟悉的話，一拉到底，看看文檔
正文
先總覽一下所有配置，後續會根據demo跑一遍常見的需求。
optimization: {
splitChunks: {
chunks: "async", // 必須三選一： "initial" | "all"(推薦) | "async" (預設就是async)
minSize: 30000, // 最小尺寸，30000
minChunks: 1, // 最小 chunk ，預設1
maxAsyncRequests: 5, // 最大異步請求數， 預設5
maxInitialRequests : 3, // 最大初始化請求書，預設3
automaticNameDelimiter: '~',// 打包分隔符
name: function(){}, // 打包後的名稱，此選項可接收 function
cacheGroups:{ // 這裡開始設定緩存的 chunks
priority: 0, // 緩存組優先級
vendor: { // key 為entry中定義的 入口名稱
chunks: "initial", // 必須三選一： "initial" | "all" | "async"(預設就是async)
test: /react|lodash/, // 正則規則驗證，如果符合就提取 chunk
name: "vendor", // 要緩存的 分隔出來的 chunk 名稱
minSize: 30000,
minChunks: 1,
enforce: true,
maxAsyncRequests: 5, // 最大異步請求數， 預設1
maxInitialRequests : 3, // 最大初始化請求書，預設1
reuseExistingChunk: true // 可設定是否重用該chunk
}
}
}
},
接下來看看第一個例子
entry: {
pageA: "./pageA", // 引用utility1.js utility2.js
pageB: "./pageB", // 引用utility2.js utility3.js
pageC: "./pageC" // 引用utility2.js utility3.js
},
optimization: {
splitChunks: {
cacheGroups: {
commons: {
chunks: "initial",
minChunks: 2,
maxInitialRequests: 5, // The default limit is too small to showcase the effect
minSize: 0 // This is example is too small to create commons chunks
}
}
}
},
結果如圖，一切都很正常 commons~pageA~pageB~pageC.js 檔案就是utility2.js
commons~pageB~pageC.js，根據上述代碼，這裡的utility2被引用了三次，首先就被抽離了commons~pageA~pageB~pageC.js，然後utility3被引用了兩次就放到了commons~pageB~pageC.js，最後隻剩下被引用一次的utility1.js,就直接放到了pageA.js裡面，如果這裡的utility1.js的也是兩次，他還是會建立一個chunk放進去，而不是合并到commons~pageB~pageC.js,除非同入口引用才會合并。
mpageA.js pageB.js pageC.js
這裡有個地方是需要優化一下的，就是pageA.js pageB.js pageC.js的代碼不多，但是打出來的包很大，肯定是一些webpack的運作檔案，直接加上
runtimeChunkruntimeChunk: "single"
// 等價于
runtimeChunk: {
name: "manifest"
} 現在就好了
引用第三方子產品 pageA引用vue.js pageB引用react react-dom
vendor: {
test: /node_modules/,
chunks: "initial",
name: "vendor",
priority: 10,
enforce: true
} 但是，這樣子的話，會把pageA pageB pageC所有的庫都打包到一起vendor.js
假如我想拆分這個vendor.js為pageA-vendor.js pageB-vendor.js怎麼辦，我試了很久，試出一個最簡單的辦法,去掉手動的vendor，讓插件自動處理。
splitChunks: {
chunks: "all",
cacheGroups: {
commons: {
chunks: "initial",
minChunks: 2,
maxInitialRequests: 5, // The default limit is too small to showcase the effect
minSize: 0 // This is example is too small to create commons chunks
}
}
},
後來，我把webpack mode改成production後，發現不管用了，同樣的配置，在生産模式下，打包出來的東西有點匪夷所思，vendor-pageB.js被合并到了pageB.js裡面了。
後來我折騰了好久也分析不出來為什麼，自己折騰出來一種方式，還是老子手動來吧，自動化一邊去
commons: {
chunks: "initial",
minChunks: 2,
maxInitialRequests: 5, // The default limit is too small to showcase the effect
minSize: 0 // This is example is too small to create commons chunks
},
'vendor-pageA': {
test: /vue/, // 直接使用 test 來做路徑比對
chunks: "initial",
name: "vendor-pageA",
enforce: true,
},
'vendor-pageB': {
test: /react/, // 直接使用 test 來做路徑比對
chunks: "initial",
name: "vendor-pageB",
enforce: true,
},
成功打包出來了自己想要的東西。
動态引入
動态引入大家應該都不陌生，就是大家所說的懶加載,直接在pageA和pageB頁面裡動态引入common-async.js，在這裡我先說說，splitChunk應該是可以自動化處理類似commonChunk裡的async，child等情況的。
import(/* webpackChunkName: "common-async.js" */"./common-async").then(common => {
console.log(common);
}) 還不錯，成功打包出來了
f.js成功的被抽離出來了，其他檔案也沒有被重複打包，挺好的。
注意的地方
- cacheGroups 會繼承和覆寫splitChunks的配置項，但是test、priorty和reuseExistingChunk隻能用于配置緩存組。。
- cacheGroups 裡的每一項最好都要加上chunks參數，不然可能打包不出來你想要的東西。
- minSize 預設是30KB（注意這個體積是壓縮之前的）在小于30kb的情況下一定要設定一個值，否則也可能打包不出來你想要的東西，而且這東西要加在cacheGroups裡面。
- priority 在某些情況下，還是挺有用的，可以設定打包chunks的優先級。
上面的例子裡面配置了一個commons，這裡的name可以自己設定，也可以不設定，我是沒設定的，你可以試試設定了是什麼樣子的，然後你就會明白這個name其實在某些情況下還是不設定的比較好。
commons: {
chunks: "initial",
minChunks: 2,
maxInitialRequests: 5, // The default limit is too small to showcase the effect
minSize: 0 ,
name:
總結
可見，splitChunk在懶加載方面，自動化處理的挺不錯的，但在多頁面的配置(根據不同的頁面抽離不同的vendor)裡，他因為有自己的一套優化政策，往往會得到不是我們想要的輸出。這篇文章隻是我初步的一些常識，我還沒有深入去看源碼，後續有空可能會補上splitChunk源碼分析，到時候就更清晰了
源碼
代碼分割 代碼懶加載參考文章
splitChunk中文版 splitChunk英文版 webpack文檔 官方demo原文釋出時間為：2018年05月26日
原文作者：乘風gg
本文來源：
掘金 https://juejin.im/entry/5b3a29f95188256228041f46如需轉載請聯系原作者