（點選上方公眾號，可快速關注）

作者：華爾街見聞技術團隊 - 花褲衩

segmentfault.com/a/1190000015919863

前幾天 webpack 作者 Tobias Koppers 釋出了一篇新的文章：webpack 4.0 to 4.16: Did you know?，總結了一下 webpack4釋出以來，做了哪些調整和優化，並且說自己正在著手開發 webpack5。

Oh you are still on webpack 3. I’m sorry, what is blocking you? We already working on webpack 5, so your stack might be outdated soon…

翻譯成中文就是：

正好我也在使用一個文件生成工具 docz(安利一波) 也最低需要 webpack4+，新版 webpack效能提高了不少，而且 webpack4 都已經發布五個多月了，想必應該已經沒什麼坑了，應該可以安心的按照別人寫的升級攻略升級了。之前一直遲遲不升級完全是被去年被 webpack3 坑怕了。它在 code splitting 的情況下 CommonsChunkPlugin會完全失效。過了好一段時間才修復，欲哭無淚。

所以這次我等了快大半年才準備升級到 webpack4 但萬萬沒想到還是遇到了不少的問題！ 有很多之前遺留的問題還是沒有很好地解決。但最主要的問題還是它的文件有所欠缺，已經廢除了的東西如

commonsChunkPlugin還在官方文件中到處出現，很多重要的東西卻一筆帶過，甚至沒寫，需要使用者自己去看原始碼才能解決。

還比如在 v4.16.0版本中廢除了 optimization.occurrenceOrder、 optimization.namedChunks、 optimization.hashedModuleIds、 optimization.namedModules 這幾個配置項，替換成了 optimization.moduleIds 和 optimization.chunkIds，但文件完中全沒有任何體現，所以你在新版本中還按照文件那樣配置其實是沒有任何效果的。

最新最完整的文件還是看他專案的配置WebpackOptions.json，強烈建議遇到不清楚的配置項可以看這個，因為它一定保證是和最新程式碼同步的。

吐槽了這麼多，我們言歸正傳。由於本次手摸手篇幅有些長，所以拆解成了上下兩篇文章：

• 上篇 -- 就是普通的在 webpack3的基礎上升級，要做哪些操作和遇到了哪些坑

• 下篇 -- 是在 webpack4下怎麼合理的打包和拆包，並且如何最大化利用 longterm caching

本文章不是手摸手從零教你 webpack 配置，所以並不會講太多很基礎的配置問題。比如如何處理 css 檔案，如何配置 webpack-dev-server，講述 file-loader 和 url-loader 之間的區別等等，有需求的推薦看 官方文件 或者 survivejs 出的一個系列教程。或者推薦看我司的另一篇 wbepack 入門文章，已同步到 webpack4 傳送門。

升級篇

前言

我一直認為模仿和借鑑是學習一個新東西最高效的方法。所以我建議還是通過借鑑一些成熟的 webpack 配置比較好。比如你專案是基於 react 生態圈的話可以借鑑 create-react-app ，下載之後 npm run eject 就可以看到它詳細的 webpack 配置了。vue 的話由於新版 vue cli不支援 eject了，而且改用 webpack-chain來配置，所以借鑑起來可能會不太方便，主要配置 地址。覺得麻煩的話你可以直接借鑑 vue-element-admin 的 配置。或者你想自己發揮，你可以借鑑 webpack 官方的各種 examples，來組合你的配置。

升級 webpack

首先將 webpack 升級到 4 之後，直接執行 webpack--xxx是不行的，因為新版本將命令列相關的東西單獨拆了出去封裝成了 webpack-cli。會報如下錯誤：

The CLI moved into a separate package: webpack-cli. Please install webpack-cli in addition to webpack itself to use the CLI.

所有你需要安裝 npm install webpack-cli-D-S。你也可將它安裝在全域性。

同時新版 webpack 需要 Node.js的最低支援版本為6.11.5不要忘了升級。如果還需要維護老專案可以使用 nvm 來做一下 node 版本管理。

升級所有依賴

因為 webpack4改了 它的 hook api ，所以所有的 loaders、 plugins都需要升級才能夠適配。

可以使用命令列 npm outdated，列出所以可以更新的包。免得再一個個去 npm找相對於的可用版本了。

反正把 devDependencies的依賴都升級一下，總歸不會有錯。

帶來的變化

其實這次升級帶來了不少改變，但大部分其實對於普通使用者來說是不需要關注的，比如這次升級帶來的功能 SideEffects、 ModuleType’sIntroduced、 WebAssemblySupport，基本平時是用不到的。我們主要關注那些對我們影響比較大的改動如： optimization.splitChunks代替原有的 CommonsChunkPlugin(下篇文章會著重介紹)，和 BetterDefaults-mode更好的預設配置，這是大家稍微需要關注一下的。

如果想進一步瞭解 TreeShaking和 SideEffects的可見文末拓展閱讀。上圖參考 Webpack 4 進階

預設配置

webpack 4 引入了 零配置的概念，被 parcel 刺激到了。 不管效果怎樣，這改變還是值得稱讚的。

最近又新出了 Fastpack 可以關注一下。

言歸正題，我們來看看 webpack 預設幫我們做了些什麼?

development 模式下，預設開啟了 NamedChunksPlugin 和 NamedModulesPlugin方便除錯，提供了更完整的錯誤資訊，更快的重新編譯的速度。

1. module.exports = {

2. + mode: 'development'

3. - devtool: 'eval',

4. - plugins: [

5. -   new webpack.NamedModulesPlugin(),

6. -   new webpack.NamedChunksPlugin(),

7. -   new webpack.DefinePlugin({ "process.env.NODE_ENV": JSON.stringify("development") }),

8. - ]

9. }

production 模式下，由於提供了 splitChunks和 minimize，所以基本零配置，程式碼就會自動分割、壓縮、優化，同時 webpack 也會自動幫你 Scopehoisting 和 Tree-shaking。

1. module.exports = {

2. +  mode: 'production',

3. -  plugins: [

4. -    newUglifyJsPlugin(/* ... */),

5. -    new webpack.DefinePlugin({ "process.env.NODE_ENV": JSON.stringify("production") }),

6. -    new webpack.optimize.ModuleConcatenationPlugin(),

7. -    new webpack.NoEmitOnErrorsPlugin()

8. -  ]

9. }

webpack 一直以來最飽受詬病的就是其配置門檻極高，配置內容極其複雜和繁瑣，容易讓人從入門到放棄，而它的後起之秀如 rollup、parcel 等均在配置流程上做了極大的優化，做到開箱即用，所以 webpack4也從中借鑑了不少經驗來提升自身的配置效率。願世間再也不需要 webpack 配置工程師。

html-webpack-plugin

用最新版本的的 html-webpack-plugin你可能還會遇到如下的錯誤：

thrownewError('Cyclic dependency'+nodeRep)

產生這個 bug 的原因是迴圈引用依賴，如果你沒有這個問題可以忽略。

目前解決方案可以使用 Alpha 版本， npm i--save-dev [email protected]

或者加入 chunksSortMode:'none'就可以了。

但仔細檢視文件發現設定成 chunksSortMode:'none'這樣是會有問題的。

Allows to control how chunks should be sorted before they are included to the HTML.

這屬性會決定你 chunks 的載入順序，如果設定為 none，你的 chunk 載入在頁面中載入的順序就不能夠保證了，可能會出現樣式被覆蓋的情況。比如我在 app.css裡面修改了一個第三方庫 element-ui的樣式，通過載入順序的先後來覆蓋它，但由於設定為了 none，打包出來的結果變成了這樣：

1. <linkhref="/app.8945fbfc.css"rel="stylesheet">

2. <linkhref="/chunk-elementUI.2db88087.css"rel="stylesheet">

app.css被先載入了，之前寫的樣式覆蓋就失效了，除非你使用 important或者其它 css 權重的方式覆蓋它，但這明顯是不太合理的。 vue-cli正好也有這個相關 issue，尤雨溪也在不使用 @next版本的基礎上 hack 了它，有興趣的可以自己研究一下，本人在專案中直接使用了 @next版本，也沒遇到其它什麼問題（除了不相容 webpack 的 prefetch/preload 相關 issue）。兩種方案都可以，自行選擇。

其它 html-webpack-plugin 的配置和之前使用沒有什麼區別。

mini-css-extract-plugin

與 extract-text-webpack-plugin 區別

由於 webpack4對 css 模組支援的完善以及在處理 css 檔案提取的方式上也做了些調整，所以之前我們一直使用的 extract-text-webpack-plugin也完成了它的歷史使命，將讓位於 mini-css-extract-plugin。

使用方式也很簡單，大家看著 文件 抄就可以了。

它與 extract-text-webpack-plugin最大的區別是：它在 code spliting的時候會將原先內聯寫在每一個 js chunk bundle的 css，單獨拆成了一個個 css 檔案。

原先 css 是這樣內聯在 js 檔案裡的：

將 css 獨立拆包最大的好處就是 js 和 css 的改動，不會影響對方。比如我改了 js 檔案並不會導致 css 檔案的快取失效。而且現在它自動會配合 optimization.splitChunks的配置，可以自定義拆分 css 檔案，比如我單獨配置了 element-ui作為單獨一個 bundle,它會自動也將它的樣式單獨打包成一個 css 檔案，不會像以前預設將第三方的 css 全部打包成一個幾十甚至上百 KB 的 app.xxx.css檔案了。

壓縮與優化

打包 css 之後檢視原始碼，我們發現它並沒有幫我們做程式碼壓縮，這時候需要使用 optimize-css-assets-webpack-plugin 這個外掛，它不僅能幫你壓縮 css 還能優化你的程式碼。

1. //配置

2. optimization: {

3.  minimizer: [newOptimizeCSSAssetsPlugin()];

4. }

如上圖測試用例所示，由於 optimize-css-assets-webpack-plugin這個外掛預設使用了 cssnano 來作 css 優化，所以它不僅壓縮了程式碼、刪掉了程式碼中無用的註釋、還去除了冗餘的 css、優化了 css 的書寫順序，優化了你的程式碼 margin:10px20px10px20px; => margin:10px20px;。同時大大減小了你 css 的檔案大小。更多優化的細節見文件。

contenthash

但使用 MiniCssExtractPlugin 有一個需求特別注意的地方，在預設文件中它是這樣配置的：

1. newMiniCssExtractPlugin({

2. // Options similar to the same options in webpackOptions.output

3. // both options are optional

4.  filename: devMode ? "[name].css" : "[name].[hash].css",

5.  chunkFilename: devMode ? "[id].css" : "[id].[hash].css"

6. });

簡單說明一下： filename 是指在你入口檔案 entry中引入生成出來的檔名，而 chunkname是指那些未被在入口檔案 entry引入，但又通過按需載入（非同步）模組的時候引入的檔案。

在 copy 如上程式碼使用之後發現情況不對！每次改動一個 xx.js檔案，它對應的 css 雖然沒做任何改動，但它的 檔案 hash 還是會發生變化。仔細對比發現原來是 hash 惹的禍。 6.f3bfa3af.css => 6.40bc56f6.css

但我這是根據官方文件來寫的！為什麼還有問題！後來在文件的最最最下面發下了這麼一段話！

For long term caching use filename: [contenthash].css. Optionally add [name].

非常的不理解，這麼關鍵的一句話會放在 Maintainers 還後面的地方，預設寫在配置裡面提示大家不是更好？有熱心群眾已經開了一個 pr，將文件預設配置為 contenthash。 chunkhash=> contenthash相關 issue。

這個真的蠻過分的，稍不注意就會讓自己的 css 檔案快取無效。而且很多使用者平時修改程式碼的時候都不會在意自己最終打包出來的 dist資料夾中到底有哪些變化。所以這個問題可能就一直存在了。浪費了多少資源！人艱不拆！大家覺得 webpack 難用不是沒道理的。

這裡再簡單說明一下幾種 hash 的區別：

hash

hash 和每次 build有關，沒有任何改變的情況下，每次編譯出來的 hash都是一樣的，但當你改變了任何一點東西，它的 hash就會發生改變。

簡單理解，你改了任何東西， hash 就會和上次不一樣了。

chunkhash

chunkhash是根據具體每一個模組檔案自己的的內容包括它的依賴計算所得的 hash，所以某個檔案的改動只會影響它本身的 hash，不會影響其它檔案。

相關推薦