你真的需要 Webpack DllPlugin 嗎？-有解無憂

前段時間寫了一篇詳解 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：