辛辛苦苦學會的 webpack dll 配置，可能已經過時了

鹵代烴發表於2019-09-26

前段時間寫了一篇詳解 webpack4 中易混淆知識點的文章，沒想到收穫了近 600 個贊，在這裡對各位老鐵抱拳感謝。上篇文章我費了很多時間去構思 demo 和原創作圖，就是想把一些概念徹底講清楚，看評論區的反響我感覺還是做到了自己設定的目標。

如果大家看過一些 webpack4 優化的文章，一定會出現 dll 動態連結庫。它以配置之複雜讓眾多初學者記憶猶新。今天我會以一個學習者的角度去一步一步探討 webpack dll 的配置，最後得出一個完美的解決方案。

本文的內容和大部分講解 webpack4 優化文章的觀點不一樣，如果有不同的見解，歡迎在評論區和我討論。

友情提示：本文章不是入門教程，不會費大量筆墨去描寫 webpack 的基礎配置，請讀者配合教程[原始碼](https://github.com/skychx/webpack_learn/tree/master/optimization)食用。

1. 基礎概念：dll 其實就是快取

說實話我剛看見這個 dll 動態連結庫的時候，我真被鎮住了：這是什麼玩意？怎麼根本沒聽說過？

好學的我趕緊 Google 一下，在維基百科裡找到了標準定義：

所謂動態連結，就是把一些經常會共享的程式碼製作成 DLL 檔，當可執行檔案呼叫到 DLL 檔內的函式時，Windows 作業系統才會把 DLL 檔載入儲存器內，DLL 檔本身的結構就是可執行檔，當程式有需求時函式才進行連結。透過動態連結方式，儲存器浪費的情形將可大幅降低。

唉，你們官方就是不說人話。

我結合 webpack，從前端的角度翻譯一下：

具體到 webpack 這塊兒，就是事先把常用但又構建時間長的程式碼提前打包好（例如 react、react-dom），取個名字叫 dll。後面再打包的時候就跳過原來的未打包程式碼，直接用 dll。這樣一來，構建時間就會縮短，提高 webpack 打包速度。

我盯著上面那句話看了三分鐘，什麼 DLL，什麼動態連結庫，在前端世界裡，不就是個快取嗎！都是拿空間換時間。

注：在這裡狹義上可以理解為拿空間換時間，如果真的要探討 dll 背後的知識：動態連結庫和靜態連結庫，就又涉及到編譯器的知識了，具體講下去又是一篇新的文章了，所以暫時按下不表。

我們對比一下 DLL 和前端常接觸的網路快取，一張表就看明白了：

DLL	快取
1.把公共程式碼打包為 DLL 檔案存到硬碟裡	1.把常用檔案存到硬碟/記憶體裡
2.第二次打包時動態連結 DLL 檔案，不重新打包	2.第二次載入時直接讀取快取，不重新請求
3.打包時間縮短	3.載入時間縮短

所以在前端世界裡， DLL 就是個另類快取。

2. DLL 手動配置：這麼多步根本記不住

剛開始我們先不搞配置，我們設想一下，如果讓你手動建立並管理快取，你會怎麼做？

我想，大家的思路一般都是這樣的：

第一次請求的時候，把請求後的內容儲存起來
建立一個對映表，當後續有請求時，先根據這個對映表到看看要請求的內容有沒有被快取，有的話就載入快取，沒有就走正常請求流程（也就是所謂的快取命中問題）
命中快取後，直接從快取中拿取內容，交給程式處理

主要流程無非這 3 步，想把事情搞大，可以再加些權重啊，過期時間啊，多級快取什麼的，但主要流程就是上面的 3 步。

一般我們在開發的時候，瀏覽器，http 協議都幫我們把這些操作封裝好了，我們就記幾個引數調參就行了；但是 webpack dll 不一樣，它需要我們手動實現上面 3 個步驟，所以就非常的無聊 + 繁瑣。

下面的程式碼比較亂，因為我也沒打算好好講這些繞來繞去的配置，具體結構最好看我 github 上放出的示例原始碼，看不懂也沒事，後面有更好的解決方案。

看得煩就直接跳過下面的內容

第 1 步，我們先要建立 dll 檔案，這個相當於我們對第一次的請求內容進行儲存，然後我們還要建立一個對映表，告訴程式我們把啥檔案做成 dll 了（這個相當於第 2 步）：

首先我們寫一個建立 dll 檔案的打包指令碼，目的是把 react，react-dom打包成 dll 檔案：

// 檔案目錄：configs/webpack.dll.js
// 程式碼太長可以不看

'use strict';

const path = require('path');
const webpack = require('webpack');

module.exports = {
    mode: 'production',
    entry: {
        react: ['react', 'react-dom'],
    },
    // 這個是輸出 dll 檔案
    output: {
        path: path.resolve(__dirname, '../dll'),
        filename: '_dll_[name].js',
        library: '_dll_[name]',
    },
    // 這個是輸出對映表
    plugins: [
        new webpack.DllPlugin({ 
            name: '_dll_[name]', // name === output.library
            path: path.resolve(__dirname, '../dll/[name].manifest.json'),
        })
    ]
};
複製程式碼

打包指令碼寫好了，我們總得執行吧？所以我們寫個執行指令碼放在 package.json 的 scripts 標籤裡，這樣我們執行 npm run build:dll 就可以打包 dll 檔案了：

// package.json

{
  "scripts": {
    "build:dll": "webpack --config configs/webpack.dll.js",
  },
}
複製程式碼

第 3 步，連結 dll 檔案，也就是告訴 webpack 可以命中的 dll 檔案，配置也是一大坨：

// 檔案目錄：configs/webpack.common.js
// 程式碼太長可以不看

const path = require('path');
const AddAssetHtmlPlugin = require('add-asset-html-webpack-plugin'); // 顧名思義，把資源加到 html 裡，那這個外掛把 dll 加入到 index.html 裡
const webpack = require('webpack');
module.exports = {
  // ......
  plugins: [
    new webpack.DllReferencePlugin({
      // 注意: DllReferencePlugin 的 context 必須和 package.json 的同級目錄，要不然會連結失敗
      context: path.resolve(__dirname, '../'),
      manifest: path.resolve(__dirname, '../dll/react.manifest.json'),
    }),
    new AddAssetHtmlPlugin({
      filepath: path.resolve(__dirname, '../dll/_dll_react.js'),
    }),
  ]
}
複製程式碼

為了減少一些大型庫的二次打包時間，我們在 3 個檔案裡寫了一堆配置程式碼，小心翼翼，如履薄冰，中間說不定還會因為作用域的問題連結失敗（對，說的就是我）。配置 dll 會給人帶來巨大的心理陰影，有沒有其他方法降低我們的心智負擔呢？

3. AutoDllPlugin：解放你的配置負擔

在第 2 小節裡我瘋狂勸退，就是想介紹這個外掛：autodll-webpack-plugin，這個外掛把上面那 3 坨程式碼整合到一塊兒，讓我們擺脫繁瑣的配置，讓我們看看這麼用吧：

// 檔案目錄：configs/webpack.common.js

const path = require('path');
const AutoDllPlugin = require('autodll-webpack-plugin'); // 第 1 步：引入 DLL 自動連結庫外掛

module.exports = {
  // ......
  plugins: [
        // 第 2 步：配置要打包為 dll 的檔案
        new AutoDllPlugin({
            inject: true, // 設為 true 就把 DLL bundles 插到 index.html 裡
            filename: '[name].dll.js',
            context: path.resolve(__dirname, '../'), // AutoDllPlugin 的 context 必須和 package.json 的同級目錄，要不然會連結失敗
            entry: {
                react: [
                    'react',
                    'react-dom'
                ]
            }
        })
  ]
}
複製程式碼

autodll-webpack-plugin 的使用方法和 webpack 的其他 plugin 使用方式非常相似，和手動引入 dll 的方法比起來，簡單許多，而且這個外掛之前是被 vue-cli 使用的，質量也是比較穩定的，大家可以放心使用。

4. 拋棄 DLL：Vue & React 官方的共同選擇

第 3 節我說 autodll-webpack-plugin 之前被 vue-cli 使用，那意思是現在不用了？是不是有 bug 啊？這個還真不是。

學習 webpack 的時候，為了借鑑一下業內優秀的框架的 webpack 配置，我專門看了 vue-cli 和 create-react-app 的原始碼，但是卻沒有找到任何 dll 的配置痕跡。

這就很奇怪了，我之前翻過一些 nuxt.js 1.0 的原始碼，裡面是有 dll 的配置程式碼的，按道理來說 vue-cli 也應該有的，我就猜測是在某次升級中，把 dll 去掉了。所以我開始查詢 commit 記錄，果然被我找到了：

白紙黑字，remove DLL option 3 個大字寫的清清楚楚

原因是什麼呢？在這個 issue 裡尤雨溪解釋了去除的原因：

dll option will be removed. Webpack 4 should provide good enough perf and the cost of maintaining DLL mode inside Vue CLI is no longer justified.

dll 配置將會被移除，因為 Webpack 4 的打包效能足夠好的，dll 沒有在 Vue ClI 裡繼續維護的必要了。

同樣的，在這個 PR 裡 create-react-app 裡也給出了類似的解釋：webpack 4 有著比 dll 更好的打包效能。

所以說，如果專案上了 webpack 4，再使用 dll 收益並不大。我拿實際專案的程式碼試了一下，加入 dll 可能會有 1-2 s 的速度提升，對於整體打包時間可以說可以忽略不計。

Vue 和 React 官方 2018 都不再使用 dll 了，現在 2019 年都快過去了，所以說我上面說的都沒用了，都不用學了，是不是感覺鬆了一口氣（瘋狂暗示點贊）？

5. 比 DLL 更優秀的外掛

dll 加速不明顯了，有沒有更好的替代品？在 AutoDllPlugin 的 README.md 裡，給我們推薦了 HardSourceWebpackPlugin，初始配置更簡單，只需要一行程式碼：

const HardSourceWebpackPlugin = require('hard-source-webpack-plugin');

module.exports = {
  // ......
  plugins: [
    new HardSourceWebpackPlugin() // <- 直接加入這行程式碼就行
  ]
}
複製程式碼

這個外掛加速有多明顯呢？我拿本文的試例程式碼測試了一下，下圖是常規的打包時間，大概 900 ms：