?webpack團隊人員臥薪嘗膽五個多月的時間終于帶來的webpack4+，個人覺得webpack4帶來的最大優(yōu)化便是對于懶加載塊拆分的優(yōu)化，刪除了CommonsChunkPlugin，新增了優(yōu)化后的SplitChunksPlugin，那么CommonsChunkPlugin的痛點在哪？SplitChunksPlugin的優(yōu)化又是在哪？

1、CommonsChunkPlugin的痛

記得17年始，我剛開始用webpack搭建一個vue的單頁應用框架時，我陸續(xù)的拋出了幾個問題：

1、如何避免單頁應用首次的入口文件過大？

這個問題處理起來倒簡單，webpack支持import()語法實現(xiàn)模塊的懶加載，可以做到隨用隨載，也就是除了首頁要用到文件，其他模塊使用懶加載就能有效的避免入口文件過大

2、入口模塊以及剩下的懶加載模塊引用公用的模塊時，代碼會重復嗎？webpack會處理嗎？怎么處理？

代碼重復是肯定的，如果父級模塊中沒有引入懶加載模塊的共用模塊，那么懶加載各模塊間就會出現(xiàn)代碼重復；webpack能處理，那么怎么處理呢？這時CommonsChunkPlugin就信誓旦旦地登場了，它能夠?qū)⑷康膽屑虞d模塊引入的共用模塊統(tǒng)一抽取出來，形成一個新的common塊，這樣就避免了懶加載模塊間的代碼重復了，哇！好強大，點個贊。可惜的是，又回到了第一個問題，你把共用的東西都抽出來了，這樣又造成了入口文件過大了。以下是CommonsChunkPlugin時代常用的配置

new webpack.optimize.CommonsChunkPlugin({name: 'vendor',// 引入node_modules的依賴全抽出來minChunks: function (module, count) {// any required modules inside node_modules are extracted to vendorreturn (module.resource &&/\.js$/.test(module.resource) &&module.resource.indexOf(path.join(__dirname, '../node_modules')) === 0)}// 或者直接minChunks: 2，重復模塊大于2的全部抽出來 }), 總之你在代碼重復與入口文件控制方面你得做個平衡，而這個平衡挺不利于多人開發(fā)的，也不易于優(yōu)化.

CommonsChunkPlugin的痛，痛在只能統(tǒng)一抽取模塊到父模塊，造成父模塊過大，不易于優(yōu)化

2、SplitChunksPlugin的好

前面講了那么多，其實SplitChunksPlugin的登場就是為了抹平之前CommonsChunkPlugin的痛的，它能夠抽出懶加載模塊之間的公共模塊，并且不會抽到父級，而是會與首次用到的懶加載模塊并行加載，這樣我們就可以放心的使用懶加載模塊了，以下是官網(wǎng)說明的一些例子：

假設存在以下chunk-a~chunk-d

chunk-a: react, react-dom, some components

chunk-b: react, react-dom, some other components

chunk-c: angular, some components

chunk-d: angular, some other components

webpack會自動創(chuàng)建兩個chunk模塊，結(jié)果如下：

chunk-a~chunk-b: react, react-dom

chunk-c~chunk-d: angular

chunk-a?to?chunk-d: Only the components

SplitChunksPlugin使用官網(wǎng)默認配置基本可以滿足大多數(shù)單頁應用了

module.exports = {//...optimization: {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}}}} };

以下是我對于多頁應用補充的配置

optimization: {splitChunks: {// 抽離入口文件公共模塊為commmons模塊cacheGroups: {commons: {name: "commons",chunks: "initial",minChunks: 2}}}},

SplitChunksPlugin的好，好在解決了入口文件過大的問題還能有效自動化的解決懶加載模塊之間的代碼重復問題

?

?

資料：沒有了CommonsChunkPlugin，咱拿什么來分包

?

總結(jié)

以上是生活随笔為你收集整理的webpack.optimize.CommonsChunkPulgin is not a constructor???请看CommonsChunkPlugin VS SplitChunksPlugin的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。