等了很久終於等到你, webpack團隊人員臥薪嚐膽五個多月的時間終於帶來的webpack4.0,我的以爲webpack4帶來的最大優化即是對於懶加載塊拆分的優化,刪除了CommonsChunkPlugin,新增了優化後的SplitChunksPlugin,那麼CommonsChunkPlugin的痛點在哪?SplitChunksPlugin的優化又是在哪?html
記得17年始,我剛開始用webpack搭建一個vue的單頁應用框架時,我陸續的拋出了幾個問題:vue
一、如何避免單頁應用首次的入口文件過大?node
這個問題處理起來倒簡單,webpack支持import()語法實現模塊的懶加載,能夠作到隨用隨載,也就是除了首頁要用到文件,其餘模塊使用懶加載就能有效的避免入口文件過大react
二、入口模塊以及剩下的懶加載模塊引用公用的模塊時,代碼會重複嗎?webpack會處理嗎?怎麼處理?webpack
代碼重複是確定的,若是父級模塊中沒有引入懶加載模塊的共用模塊,那麼懶加載各模塊間就會出現代碼重複;webpack能處理,那麼怎麼處理呢?這時CommonsChunkPlugin就信誓旦旦地登場了,它可以將所有的懶加載模塊引入的共用模塊統一抽取出來,造成一個新的common塊,這樣就避免了懶加載模塊間的代碼重複了,哇!好強大,點個贊。惋惜的是,又回到了第一個問題,你把共用的東西都抽出來了,這樣又形成了入口文件過大了。如下是CommonsChunkPlugin時代經常使用的配置git
new webpack.optimize.CommonsChunkPlugin({
name: 'vendor',
// 引入node_modules的依賴全抽出來
minChunks: function (module, count) {
// any required modules inside node_modules are extracted to vendor
return (
module.resource &&
/\.js$/.test(module.resource) &&
module.resource.indexOf(
path.join(__dirname, '../node_modules')
) === 0
)
}
// 或者直接minChunks: 2,重複模塊大於2的所有抽出來
}),
總之你在代碼重複與入口文件控制方面你得作個平衡,而這個平衡挺不利於多人開發的,也不易於優化,我剛接觸時有寫了一篇博文也是關於懶加載,這裏對於項目平衡與取捨有作了一些分析,這裏就再也不展開。
CommonsChunkPlugin的痛,痛在只能統一抽取模塊到父模塊,形成父模塊過大,不易於優化github
前面講了那麼多,其實SplitChunksPlugin的登場就是爲了抹平以前CommonsChunkPlugin的痛的,它可以抽出懶加載模塊之間的公共模塊,而且不會抽到父級,而是會與首次用到的懶加載模塊並行加載,這樣咱們就能夠放心的使用懶加載模塊了,如下是官網說明的一些例子:web
假設存在如下chunk-a~chunk-dvue-cli
chunk-a: react, react-dom, some componentsapp
chunk-b: react, react-dom, some other components
chunk-c: angular, some components
chunk-d: angular, some other components
webpack會自動建立兩個chunk模塊,結果以下:
chunk-a~chunk-b: react, react-dom
chunk-c~chunk-d: angular
chunk-a to chunk-d: Only the components
SplitChunksPlugin使用官網默認配置基本能夠知足大多數單頁應用了,如下是我對於多頁應用補充的配置
optimization: {
splitChunks: {
// 抽離入口文件公共模塊爲commmons模塊
cacheGroups: {
commons: {
name: "commons",
chunks: "initial",
minChunks: 2
}
}
}
},
vue-cli這是我升級到webpack4.0後的vue-cli配置,結合了happypack,vue-loader@16,單頁與多頁自動構建等的腳手架
SplitChunksPlugin的好,好在解決了入口文件過大的問題還能有效自動化的解決懶加載模塊之間的代碼重複問題