Webpack原理

webpack原理

查看所有文檔頁面：全棧開發，獲取更多信息。
原文鏈接：webpack原理，原文廣告模態框遮擋，閱讀體驗不好，所以整理成本文，方便查找。

工作原理概括

基本概念

在瞭解 Webpack 原理前，需要掌握以下幾個核心概念，以方便後面的理解：

• Entry：入口，Webpack 執行構建的第一步將從 Entry 開始，可抽象成輸入。
• Module：模塊，在 Webpack 裏一切皆模塊，一個模塊對應着一個文件。Webpack 會從配置的 Entry 開始遞歸找出所有依賴的模塊。
• Chunk：代碼塊，一個 Chunk 由多個模塊組合而成，用於代碼合併與分割。
• Loader：模塊轉換器，用於把模塊原內容按照需求轉換成新內容。
• Plugin：擴展插件，在 Webpack 構建流程中的特定時機會廣播出對應的事件，插件可以監聽這些事件的發生，在特定時機做對應的事情。

流程概括

Webpack 的運行流程是一個串行的過程，從啓動到結束會依次執行以下流程：

1. 初始化參數：從配置文件和 Shell 語句中讀取與合併參數，得出最終的參數；
2. 開始編譯：用上一步得到的參數初始化 Compiler 對象，加載所有配置的插件，執行對象的 run 方法開始執行編譯；
3. 確定入口：根據配置中的 entry 找出所有的入口文件；
4. 編譯模塊：從入口文件出發，調用所有配置的 Loader 對模塊進行翻譯，再找出該模塊依賴的模塊，再遞歸本步驟直到所有入口依賴的文件都經過了本步驟的處理；
5. 完成模塊編譯：在經過第4步使用 Loader 翻譯完所有模塊後，得到了每個模塊被翻譯後的最終內容以及它們之間的依賴關係；
6. 輸出資源：根據入口和模塊之間的依賴關係，組裝成一個個包含多個模塊的 Chunk，再把每個 Chunk 轉換成一個單獨的文件加入到輸出列表，這步是可以修改輸出內容的最後機會；
7. 輸出完成：在確定好輸出內容後，根據配置確定輸出的路徑和文件名，把文件內容寫入到文件系統。

在以上過程中，Webpack 會在特定的時間點廣播出特定的事件，插件在監聽到感興趣的事件後會執行特定的邏輯，並且插件可以調用 Webpack 提供的 API 改變 Webpack 的運行結果。

流程細節

Webpack 的構建流程可以分爲以下三大階段：

1. 初始化：啓動構建，讀取與合併配置參數，加載 Plugin，實例化 Compiler。
2. 編譯：從 Entry 發出，針對每個 Module 串行調用對應的 Loader 去翻譯文件內容，再找到該 Module 依賴的 Module，遞歸地進行編譯處理。
3. 輸出：對編譯後的 Module 組合成 Chunk，把 Chunk 轉換成文件，輸出到文件系統。

如果只執行一次構建，以上階段將會按照順序各執行一次。但在開啓監聽模式下，流程將變爲如下：

在每個大階段中又會發生很多事件，Webpack 會把這些事件廣播出來供給 Plugin 使用，下面來一一介紹。

初始化階段

事件名	解釋
初始化參數	從配置文件和 Shell 語句中讀取與合併參數，得出最終的參數。 這個過程中還會執行配置文件中的插件實例化語句 new Plugin()。
實例化 Compiler	用上一步得到的參數初始化 Compiler 實例，Compiler 負責文件監聽和啓動編譯。Compiler 實例中包含了完整的 Webpack 配置，全局只有一個 Compiler 實例。
加載插件	依次調用插件的 apply 方法，讓插件可以監聽後續的所有事件節點。同時給插件傳入 compiler 實例的引用，以方便插件通過 compiler 調用 Webpack 提供的 API。
environment	開始應用 Node.js 風格的文件系統到 compiler 對象，以方便後續的文件尋找和讀取。
entry-option	讀取配置的 Entrys，爲每個 Entry 實例化一個對應的 EntryPlugin，爲後面該 Entry 的遞歸解析工作做準備。
after-plugins	調用完所有內置的和配置的插件的 apply 方法。
after-resolvers	根據配置初始化完 resolver，resolver 負責在文件系統中尋找指定路徑的文件。
空格	空格
空格	空格
空格	空格

編譯階段

事件名	解釋
run	啓動一次新的編譯。
watch-run	和 run 類似，區別在於它是在監聽模式下啓動的編譯，在這個事件中可以獲取到是哪些文件發生了變化導致重新啓動一次新的編譯。
compile	該事件是爲了告訴插件一次新的編譯將要啓動，同時會給插件帶上 compiler 對象。
compilation	當 Webpack 以開發模式運行時，每當檢測到文件變化，一次新的 Compilation 將被創建。一個 Compilation 對象包含了當前的模塊資源、編譯生成資源、變化的文件等。Compilation 對象也提供了很多事件回調供插件做擴展。
make	一個新的 Compilation 創建完畢，即將從 Entry 開始讀取文件，根據文件類型和配置的 Loader 對文件進行編譯，編譯完後再找出該文件依賴的文件，遞歸的編譯和解析。
after-compile	一次 Compilation 執行完成。
invalid	當遇到文件不存在、文件編譯錯誤等異常時會觸發該事件，該事件不會導致 Webpack 退出。
空格	空格
空格	空格

在編譯階段中，最重要的要數 compilation 事件了，因爲在 compilation 階段調用了 Loader 完成了每個模塊的轉換操作，在 compilation 階段又包括很多小的事件，它們分別是：

事件名	解釋
build-module	使用對應的 Loader 去轉換一個模塊。
normal-module-loader	在用 Loader 對一個模塊轉換完後，使用 acorn 解析轉換後的內容，輸出對應的抽象語法樹（AST），以方便 Webpack 後面對代碼的分析。
program	從配置的入口模塊開始，分析其 AST，當遇到 require 等導入其它模塊語句時，便將其加入到依賴的模塊列表，同時對新找出的依賴模塊遞歸分析，最終搞清所有模塊的依賴關係。
seal	所有模塊及其依賴的模塊都通過 Loader 轉換完成後，根據依賴關係開始生成 Chunk。

輸出階段

事件名	解釋
should-emit	所有需要輸出的文件已經生成好，詢問插件哪些文件需要輸出，哪些不需要。
emit	確定好要輸出哪些文件後，執行文件輸出，可以在這裏獲取和修改輸出內容。
after-emit	文件輸出完畢。
done	成功完成一次完成的編譯和輸出流程。
failed	如果在編譯和輸出流程中遇到異常導致 Webpack 退出時，就會直接跳轉到本步驟，插件可以在本事件中獲取到具體的錯誤原因。

在輸出階段已經得到了各個模塊經過轉換後的結果和其依賴關係，並且把相關模塊組合在一起形成一個個 Chunk。 在輸出階段會根據 Chunk 的類型，使用對應的模版生成最終要要輸出的文件內容。

輸出文件分析

雖然在前面的章節中你學會了如何使用 Webpack ，也大致知道其工作原理，可是你想過 Webpack 輸出的 bundle.js 是什麼樣子的嗎？ 爲什麼原來一個個的模塊文件被合併成了一個單獨的文件？爲什麼 bundle.js 能直接運行在瀏覽器中？ 本節將解釋清楚以上問題。

先來看看由 安裝與使用 中最簡單的項目構建出的 bundle.js 文件內容，代碼如下：

<p data-height="565" data-theme-id="0" data-slug-hash="NMQzxz" data-default-tab="js" data-user="whjin" data-embed-version="2" data-pen-title="bundle.js" class="codepen">See the Pen bundle.js點擊預覽 by whjin (@whjin點擊預覽) on CodePen.</p>
<script async src="https://static.codepen.io/ass...;></script>

以上看上去複雜的代碼其實是一個立即執行函數，可以簡寫爲如下：

(function(modules) {

  // 模擬 require 語句
  function __webpack_require__() {
  }

  // 執行存放所有模塊數組中的第0個模塊
  __webpack_require__(0);

})([/*存放所有模塊的數組*/])

bundle.js 能直接運行在瀏覽器中的原因在於輸出的文件中通過 __webpack_require__ 函數定義了一個可以在瀏覽器中執行的加載函數來模擬 Node.js 中的 require 語句。

原來一個個獨立的模塊文件被合併到了一個單獨的 bundle.js 的原因在於瀏覽器不能像 Node.js 那樣快速地去本地加載一個個模塊文件，而必須通過網絡請求去加載還未得到的文件。 如果模塊數量很多，加載時間會很長，因此把所有模塊都存放在了數組中，執行一次網絡加載。

如果仔細分析 __webpack_require__ 函數的實現，你還有發現 Webpack 做了緩存優化： 執行加載過的模塊不會再執行第二次，執行結果會緩存在內存中，當某個模塊第二次被訪問時會直接去內存中讀取被緩存的返回值。

分割代碼時的輸出

例如把源碼中的 main.js 修改爲如下：

// 異步加載 show.js
import('./show').then((show) => {
  // 執行 show 函數
  show('Webpack');
});

重新構建後會輸出兩個文件，分別是執行入口文件 bundle.js 和 異步加載文件 0.bundle.js。

其中 0.bundle.js 內容如下：

// 加載在本文件(0.bundle.js)中包含的模塊
webpackJsonp(
  // 在其它文件中存放着的模塊的 ID
  [0],
  // 本文件所包含的模塊
  [
    // show.js 所對應的模塊
    (function (module, exports) {
      function show(content) {
        window.document.getElementById('app').innerText = 'Hello,' + content;
      }

      module.exports = show;
    })
  ]
);

bundle.js 內容如下：

<p data-height="565" data-theme-id="0" data-slug-hash="yjmRyG" data-default-tab="js" data-user="whjin" data-embed-version="2" data-pen-title="bundle.js" class="codepen">See the Pen bundle.js點擊預覽 by whjin (@whjin點擊預覽) on CodePen.</p>
<script async src="https://static.codepen.io/ass...;></script>

這裏的 bundle.js 和上面所講的 bundle.js 非常相似，區別在於：

• 多了一個 __webpack_require__.e 用於加載被分割出去的，需要異步加載的 Chunk 對應的文件;
• 多了一個 webpackJsonp 函數用於從異步加載的文件中安裝模塊。

在使用了 CommonsChunkPlugin 去提取公共代碼時輸出的文件和使用了異步加載時輸出的文件是一樣的，都會有 __webpack_require__.e 和 webpackJsonp。 原因在於提取公共代碼和異步加載本質上都是代碼分割。

編寫 Loader

Loader 就像是一個翻譯員，能把源文件經過轉化後輸出新的結果，並且一個文件還可以鏈式的經過多個翻譯員翻譯。

以處理 SCSS 文件爲例：

• SCSS 源代碼會先交給 sass-loader 把 SCSS 轉換成 CSS；
• 把 sass-loader 輸出的 CSS 交給 css-loader 處理，找出 CSS 中依賴的資源、壓縮 CSS 等；
• 把 css-loader 輸出的 CSS 交給 style-loader 處理，轉換成通過腳本加載的 JavaScript 代碼；

可以看出以上的處理過程需要有順序的鏈式執行，先 sass-loader 再 css-loader 再 style-loader。 以上處理的 Webpack 相關配置如下：

<p data-height="365" data-theme-id="0" data-slug-hash="YLmbeQ" data-default-tab="js" data-user="whjin" data-embed-version="2" data-pen-title="編寫 Loader" class="codepen">See the Pen 編寫 Loader點擊預覽 by whjin (@whjin點擊預覽) on CodePen.</p>
<script async src="https://static.codepen.io/ass...;></script>

Loader 的職責

由上面的例子可以看出：一個 Loader 的職責是單一的，只需要完成一種轉換。 如果一個源文件需要經歷多步轉換才能正常使用，就通過多個 Loader 去轉換。 在調用多個 Loader 去轉換一個文件時，每個 Loader 會鏈式的順序執行， 第一個 Loader 將會拿到需處理的原內容，上一個 Loader 處理後的結果會傳給下一個接着處理，最後的 Loader 將處理後的最終結果返回給 Webpack。

所以，在你開發一個 Loader 時，請保持其職責的單一性，你只需關心輸入和輸出。

Loader 基礎

由於 Webpack 是運行在 Node.js 之上的，一個 Loader 其實就是一個 Node.js 模塊，這個模塊需要導出一個函數。 這個導出的函數的工作就是獲得處理前的原內容，對原內容執行處理後，返回處理後的內容。

一個最簡單的 Loader 的源碼如下：

module.exports = function(source) {
  // source 爲 compiler 傳遞給 Loader 的一個文件的原內容
  // 該函數需要返回處理後的內容，這裏簡單起見，直接把原內容返回了，相當於該 Loader 沒有做任何轉換
  return source;
};

由於 Loader 運行在 Node.js 中，你可以調用任何 Node.js 自帶的 API，或者安裝第三方模塊進行調用：

const sass = require('node-sass');
module.exports = function(source) {
  return sass(source);
};

Loader 進階

以上只是個最簡單的 Loader，Webpack 還提供一些 API 供 Loader 調用，下面來一一介紹。

獲得 Loader 的 options

在最上面處理 SCSS 文件的 Webpack 配置中，給 css-loader 傳了 options 參數，以控制 css-loader。 如何在自己編寫的 Loader 中獲取到用戶傳入的 options 呢？需要這樣做：

const loaderUtils = require('loader-utils');
module.exports = function(source) {
  // 獲取到用戶給當前 Loader 傳入的 options
  const options = loaderUtils.getOptions(this);
  return source;
};

返回其它結果

上面的 Loader 都只是返回了原內容轉換後的內容，但有些場景下還需要返回除了內容之外的東西。

例如以用 babel-loader 轉換 ES6 代碼爲例，它還需要輸出轉換後的 ES5 代碼對應的 Source Map，以方便調試源碼。 爲了把 Source Map 也一起隨着 ES5 代碼返回給 Webpack，可以這樣寫：

module.exports = function(source) {
  // 通過 this.callback 告訴 Webpack 返回的結果
  this.callback(null, source, sourceMaps);
  // 當你使用 this.callback 返回內容時，該 Loader 必須返回 undefined，
  // 以讓 Webpack 知道該 Loader 返回的結果在 this.callback 中，而不是 return 中 
  return;
};

其中的 this.callback 是 Webpack 給 Loader 注入的 API，以方便 Loader 和 Webpack 之間通信。 this.callback 的詳細使用方法如下：

this.callback(
    // 當無法轉換原內容時，給 Webpack 返回一個 Error
    err: Error | null,
    // 原內容轉換後的內容
    content: string | Buffer,
    // 用於把轉換後的內容得出原內容的 Source Map，方便調試
    sourceMap?: SourceMap,
    // 如果本次轉換爲原內容生成了 AST 語法樹，可以把這個 AST 返回，
    // 以方便之後需要 AST 的 Loader 複用該 AST，以避免重複生成 AST，提升性能
    abstractSyntaxTree?: AST
);

Source Map 的生成很耗時，通常在開發環境下才會生成 Source Map，其它環境下不用生成，以加速構建。 爲此 Webpack 爲 Loader 提供了 this.sourceMap API 去告訴 Loader 當前構建環境下用戶是否需要 Source Map。 如果你編寫的 Loader 會生成 Source Map，請考慮到這點。

同步與異步

Loader 有同步和異步之分，上面介紹的 Loader 都是同步的 Loader，因爲它們的轉換流程都是同步的，轉換完成後再返回結果。 但在有些場景下轉換的步驟只能是異步完成的，例如你需要通過網絡請求才能得出結果，如果採用同步的方式網絡請求就會阻塞整個構建，導致構建非常緩慢。

在轉換步驟是異步時，你可以這樣：

module.exports = function(source) {
    // 告訴 Webpack 本次轉換是異步的，Loader 會在 callback 中回調結果
    var callback = this.async();
    someAsyncOperation(source, function(err, result, sourceMaps, ast) {
        // 通過 callback 返回異步執行後的結果
        callback(err, result, sourceMaps, ast);
    });
};

處理二進制數據

在默認的情況下，Webpack 傳給 Loader 的原內容都是 UTF-8 格式編碼的字符串。 但有些場景下 Loader 不是處理文本文件，而是處理二進制文件，例如 file-loader，就需要 Webpack 給 Loader 傳入二進制格式的數據。 爲此，你需要這樣編寫 Loader：

module.exports = function(source) {
    // 在 exports.raw === true 時，Webpack 傳給 Loader 的 source 是 Buffer 類型的
    source instanceof Buffer === true;
    // Loader 返回的類型也可以是 Buffer 類型的
    // 在 exports.raw !== true 時，Loader 也可以返回 Buffer 類型的結果
    return source;
};
// 通過 exports.raw 屬性告訴 Webpack 該 Loader 是否需要二進制數據 
module.exports.raw = true;

以上代碼中最關鍵的代碼是最後一行 module.exports.raw = true;，沒有該行 Loader 只能拿到字符串。

緩存加速

在有些情況下，有些轉換操作需要大量計算非常耗時，如果每次構建都重新執行重複的轉換操作，構建將會變得非常緩慢。 爲此，Webpack 會默認緩存所有 Loader 的處理結果，也就是說在需要被處理的文件或者其依賴的文件沒有發生變化時， 是不會重新調用對應的 Loader 去執行轉換操作的。

如果你想讓 Webpack 不緩存該 Loader 的處理結果，可以這樣：

module.exports = function(source) {
  // 關閉該 Loader 的緩存功能
  this.cacheable(false);
  return source;
};

其它 Loader API

除了以上提到的在 Loader 中能調用的 Webpack API 外，還存在以下常用 API：

• this.context：當前處理文件的所在目錄，假如當前 Loader 處理的文件是 /src/main.js，則 this.context 就等於 /src。
• this.resource：當前處理文件的完整請求路徑，包括 querystring，例如 /src/main.js?name=1。
• this.resourcePath：當前處理文件的路徑，例如 /src/main.js。
• this.resourceQuery：當前處理文件的 querystring。
• this.target：等於 Webpack 配置中的 Target。
• this.loadModule：但 Loader 在處理一個文件時，如果依賴其它文件的處理結果才能得出當前文件的結果時， 就可以通過 this.loadModule(request: string, callback: function(err, source, sourceMap, module)) 去獲得 request 對應文件的處理結果。
• this.resolve：像 require 語句一樣獲得指定文件的完整路徑，使用方法爲 resolve(context: string, request: string, callback: function(err, result: string))。
• this.addDependency：給當前處理文件添加其依賴的文件，以便再其依賴的文件發生變化時，會重新調用 Loader 處理該文件。使用方法爲 addDependency(file: string)。
• this.addContextDependency：和 addDependency 類似，但 addContextDependency 是把整個目錄加入到當前正在處理文件的依賴中。使用方法爲 addContextDependency(directory: string)。
• this.clearDependencies：清除當前正在處理文件的所有依賴，使用方法爲 clearDependencies()。
• this.emitFile：輸出一個文件，使用方法爲 emitFile(name: string, content: Buffer|string, sourceMap: {...})。

加載本地 Loader

在開發 Loader 的過程中，爲了測試編寫的 Loader 是否能正常工作，需要把它配置到 Webpack 中後，纔可能會調用該 Loader。 在前面的章節中，使用的 Loader 都是通過 Npm 安裝的，要使用 Loader 時會直接使用 Loader 的名稱，代碼如下：

module.exports = {
  module: {
    rules: [
      {
        test: /\.css/,
        use: ['style-loader'],
      },
    ]
  },
};

如果還採取以上的方法去使用本地開發的 Loader 將會很麻煩，因爲你需要確保編寫的 Loader 的源碼是在 node_modules目錄下。 爲此你需要先把編寫的 Loader 發佈到 Npm 倉庫後再安裝到本地項目使用。

解決以上問題的便捷方法有兩種，分別如下：

Npm link

Npm link 專門用於開發和調試本地 Npm 模塊，能做到在不發佈模塊的情況下，把本地的一個正在開發的模塊的源碼鏈接到項目的 node_modules 目錄下，讓項目可以直接使用本地的 Npm 模塊。 由於是通過軟鏈接的方式實現的，編輯了本地的 Npm 模塊代碼，在項目中也能使用到編輯後的代碼。

完成 Npm link 的步驟如下：

• 確保正在開發的本地 Npm 模塊（也就是正在開發的 Loader）的 package.json 已經正確配置好；
• 在本地 Npm 模塊根目錄下執行 npm link，把本地模塊註冊到全局；
• 在項目根目錄下執行 npm link loader-name，把第2步註冊到全局的本地 Npm 模塊鏈接到項目的 node_moduels下，其中的 loader-name 是指在第1步中的 package.json 文件中配置的模塊名稱。

鏈接好 Loader 到項目後你就可以像使用一個真正的 Npm 模塊一樣使用本地的 Loader 了。

ResolveLoader

ResolveLoader 用於配置 Webpack 如何尋找 Loader。 默認情況下只會去 node_modules 目錄下尋找，爲了讓 Webpack 加載放在本地項目中的 Loader 需要修改 resolveLoader.modules。

假如本地的 Loader 在項目目錄中的 ./loaders/loader-name 中，則需要如下配置：

module.exports = {
  resolveLoader:{
    // 去哪些目錄下尋找 Loader，有先後順序之分
    modules: ['node_modules','./loaders/'],
  }
}

加上以上配置後， Webpack 會先去 node_modules 項目下尋找 Loader，如果找不到，會再去 ./loaders/ 目錄下尋找。

實戰

上面講了許多理論，接下來從實際出發，來編寫一個解決實際問題的 Loader。

該 Loader 名叫 comment-require-loader，作用是把 JavaScript 代碼中的註釋語法：

// @require '../style/index.css'

轉換成：

require('../style/index.css');

該 Loader 的使用場景是去正確加載針對 Fis3 編寫的 JavaScript，這些 JavaScript 中存在通過註釋的方式加載依賴的 CSS 文件。

該 Loader 的使用方法如下：

module.exports = {
  module: {
    rules: [
      {
        test: /\.js$/,
        use: ['comment-require-loader'],
        // 針對採用了 fis3 CSS 導入語法的 JavaScript 文件通過 comment-require-loader 去轉換 
        include: [path.resolve(__dirname, 'node_modules/imui')]
      }
    ]
  }
};

該 Loader 的實現非常簡單，完整代碼如下：

function replace(source) {
    // 使用正則把 // @require '../style/index.css' 轉換成 require('../style/index.css');  
    return source.replace(/(\/\/ *@require) +(('|").+('|")).*/, 'require($2);');
}

module.exports = function (content) {
    return replace(content);
};

編寫 Plugin

Webpack 通過 Plugin 機制讓其更加靈活，以適應各種應用場景。 在 Webpack 運行的生命週期中會廣播出許多事件，Plugin 可以監聽這些事件，在合適的時機通過 Webpack 提供的 API 改變輸出結果。

一個最基礎的 Plugin 的代碼是這樣的：

class BasicPlugin{
  // 在構造函數中獲取用戶給該插件傳入的配置
  constructor(options){
  }

  // Webpack 會調用 BasicPlugin 實例的 apply 方法給插件實例傳入 compiler 對象
  apply(compiler){
    compiler.plugin('compilation',function(compilation) {
    })
  }
}

// 導出 Plugin
module.exports = BasicPlugin;

在使用這個 Plugin 時，相關配置代碼如下：

const BasicPlugin = require('./BasicPlugin.js');
module.export = {
  plugins:[
    new BasicPlugin(options),
  ]
}

Webpack 啓動後，在讀取配置的過程中會先執行 new BasicPlugin(options) 初始化一個 BasicPlugin 獲得其實例。 在初始化 compiler 對象後，再調用 basicPlugin.apply(compiler) 給插件實例傳入 compiler 對象。 插件實例在獲取到 compiler 對象後，就可以通過 compiler.plugin(事件名稱, 回調函數) 監聽到 Webpack 廣播出來的事件。 並且可以通過 compiler 對象去操作 Webpack。

通過以上最簡單的 Plugin 相信你大概明白了 Plugin 的工作原理，但實際開發中還有很多細節需要注意，下面來詳細介紹。

Compiler 和 Compilation

在開發 Plugin 時最常用的兩個對象就是 Compiler 和 Compilation，它們是 Plugin 和 Webpack 之間的橋樑。 Compiler 和 Compilation 的含義如下：

• Compiler 對象包含了 Webpack 環境所有的的配置信息，包含 options，loaders，plugins 這些信息，這個對象在 Webpack 啓動時候被實例化，它是全局唯一的，可以簡單地把它理解爲 Webpack 實例；
• Compilation 對象包含了當前的模塊資源、編譯生成資源、變化的文件等。當 Webpack 以開發模式運行時，每當檢測到一個文件變化，一次新的 Compilation 將被創建。Compilation 對象也提供了很多事件回調供插件做擴展。通過 Compilation 也能讀取到 Compiler 對象。

Compiler 和 Compilation 的區別在於：Compiler 代表了整個 Webpack 從啓動到關閉的生命週期，而 Compilation 只是代表了一次新的編譯。

事件流

Webpack 就像一條生產線，要經過一系列處理流程後才能將源文件轉換成輸出結果。 這條生產線上的每個處理流程的職責都是單一的，多個流程之間有存在依賴關係，只有完成當前處理後才能交給下一個流程去處理。 插件就像是一個插入到生產線中的一個功能，在特定的時機對生產線上的資源做處理。

Webpack 通過 Tapable 來組織這條複雜的生產線。 Webpack 在運行過程中會廣播事件，插件只需要監聽它所關心的事件，就能加入到這條生產線中，去改變生產線的運作。 Webpack 的事件流機制保證了插件的有序性，使得整個系統擴展性很好。

Webpack 的事件流機制應用了觀察者模式，和 Node.js 中的 EventEmitter 非常相似。Compiler 和 Compilation 都繼承自 Tapable，可以直接在 Compiler 和 Compilation 對象上廣播和監聽事件，方法如下：

/**
* 廣播出事件
* event-name 爲事件名稱，注意不要和現有的事件重名
* params 爲附帶的參數
*/
compiler.apply('event-name',params);

/**
* 監聽名稱爲 event-name 的事件，當 event-name 事件發生時，函數就會被執行。
* 同時函數中的 params 參數爲廣播事件時附帶的參數。
*/
compiler.plugin('event-name',function(params) {

});

同理，compilation.apply 和 compilation.plugin 使用方法和上面一致。

在開發插件時，你可能會不知道該如何下手，因爲你不知道該監聽哪個事件才能完成任務。

在開發插件時，還需要注意以下兩點：

• 只要能拿到 Compiler 或 Compilation 對象，就能廣播出新的事件，所以在新開發的插件中也能廣播出事件，給其它插件監聽使用。
• 傳給每個插件的 Compiler 和 Compilation 對象都是同一個引用。也就是說在一個插件中修改了 Compiler 或 Compilation 對象上的屬性，會影響到後面的插件。
• 有些事件是異步的，這些異步的事件會附帶兩個參數，第二個參數爲回調函數，在插件處理完任務時需要調用回調函數通知 Webpack，纔會進入下一處理流程。例如：

 compiler.plugin('emit',function(compilation, callback) {
    // 支持處理邏輯

    // 處理完畢後執行 callback 以通知 Webpack 
    // 如果不執行 callback，運行流程將會一直卡在這不往下執行 
    callback();
  });

常用 API

插件可以用來修改輸出文件、增加輸出文件、甚至可以提升 Webpack 性能、等等，總之插件通過調用 Webpack 提供的 API 能完成很多事情。 由於 Webpack 提供的 API 非常多，有很多 API 很少用的上，又加上篇幅有限，下面來介紹一些常用的 API。

讀取輸出資源、代碼塊、模塊及其依賴

有些插件可能需要讀取 Webpack 的處理結果，例如輸出資源、代碼塊、模塊及其依賴，以便做下一步處理。

在 emit 事件發生時，代表源文件的轉換和組裝已經完成，在這裏可以讀取到最終將輸出的資源、代碼塊、模塊及其依賴，並且可以修改輸出資源的內容。 插件代碼如下：

<p data-height="585" data-theme-id="0" data-slug-hash="RJwjPj" data-default-tab="js" data-user="whjin" data-embed-version="2" data-pen-title="emit" class="codepen">See the Pen emit點擊預覽 by whjin (@whjin點擊預覽) on CodePen.</p>
<script async src="https://static.codepen.io/ass...;></script>

監聽文件變化

Webpack 會從配置的入口模塊出發，依次找出所有的依賴模塊，當入口模塊或者其依賴的模塊發生變化時， 就會觸發一次新的 Compilation。

在開發插件時經常需要知道是哪個文件發生變化導致了新的 Compilation，爲此可以使用如下代碼：

<p data-height="255" data-theme-id="0" data-slug-hash="jKOabJ" data-default-tab="js" data-user="whjin" data-embed-version="2" data-pen-title="Compilation" class="codepen">See the Pen Compilation點擊預覽 by whjin (@whjin點擊預覽) on CodePen.</p>
<script async src="https://static.codepen.io/ass...;></script>

默認情況下 Webpack 只會監視入口和其依賴的模塊是否發生變化，在有些情況下項目可能需要引入新的文件，例如引入一個 HTML 文件。 由於 JavaScript 文件不會去導入 HTML 文件，Webpack 就不會監聽 HTML 文件的變化，編輯 HTML 文件時就不會重新觸發新的 Compilation。 爲了監聽 HTML 文件的變化，我們需要把 HTML 文件加入到依賴列表中，爲此可以使用如下代碼：

compiler.plugin('after-compile', (compilation, callback) => {
  // 把 HTML 文件添加到文件依賴列表，好讓 Webpack 去監聽 HTML 模塊文件，在 HTML 模版文件發生變化時重新啓動一次編譯
    compilation.fileDependencies.push(filePath);
    callback();
});

修改輸出資源

有些場景下插件需要修改、增加、刪除輸出的資源，要做到這點需要監聽 emit 事件，因爲發生 emit 事件時所有模塊的轉換和代碼塊對應的文件已經生成好， 需要輸出的資源即將輸出，因此 emit 事件是修改 Webpack 輸出資源的最後時機。

所有需要輸出的資源會存放在 compilation.assets 中，compilation.assets 是一個鍵值對，鍵爲需要輸出的文件名稱，值爲文件對應的內容。

設置 compilation.assets 的代碼如下：

compiler.plugin('emit', (compilation, callback) => {
  // 設置名稱爲 fileName 的輸出資源
  compilation.assets[fileName] = {
    // 返回文件內容
    source: () => {
      // fileContent 既可以是代表文本文件的字符串，也可以是代表二進制文件的 Buffer
      return fileContent;
      },
    // 返回文件大小
      size: () => {
      return Buffer.byteLength(fileContent, 'utf8');
    }
  };
  callback();
});

讀取 compilation.assets 的代碼如下：

compiler.plugin('emit', (compilation, callback) => {
  // 讀取名稱爲 fileName 的輸出資源
  const asset = compilation.assets[fileName];
  // 獲取輸出資源的內容
  asset.source();
  // 獲取輸出資源的文件大小
  asset.size();
  callback();
});

判斷 Webpack 使用了哪些插件

在開發一個插件時可能需要根據當前配置是否使用了其它某個插件而做下一步決定，因此需要讀取 Webpack 當前的插件配置情況。 以判斷當前是否使用了 ExtractTextPlugin 爲例，可以使用如下代碼：

// 判斷當前配置使用使用了 ExtractTextPlugin，
// compiler 參數即爲 Webpack 在 apply(compiler) 中傳入的參數
function hasExtractTextPlugin(compiler) {
  // 當前配置所有使用的插件列表
  const plugins = compiler.options.plugins;
  // 去 plugins 中尋找有沒有 ExtractTextPlugin 的實例
  return plugins.find(plugin=>plugin.__proto__.constructor === ExtractTextPlugin) != null;
}

實戰

下面我們舉一個實際的例子，帶你一步步去實現一個插件。

該插件的名稱取名叫 EndWebpackPlugin，作用是在 Webpack 即將退出時再附加一些額外的操作，例如在 Webpack 成功編譯和輸出了文件後執行發佈操作把輸出的文件上傳到服務器。 同時該插件還能區分 Webpack 構建是否執行成功。使用該插件時方法如下：

module.exports = {
  plugins:[
    // 在初始化 EndWebpackPlugin 時傳入了兩個參數，分別是在成功時的回調函數和失敗時的回調函數；
    new EndWebpackPlugin(() => {
      // Webpack 構建成功，並且文件輸出了後會執行到這裏，在這裏可以做發佈文件操作
    }, (err) => {
      // Webpack 構建失敗，err 是導致錯誤的原因
      console.error(err);        
    })
  ]
}

要實現該插件，需要藉助兩個事件：

• done：在成功構建並且輸出了文件後，Webpack 即將退出時發生；
• failed：在構建出現異常導致構建失敗，Webpack 即將退出時發生；

實現該插件非常簡單，完整代碼如下：

class EndWebpackPlugin {

  constructor(doneCallback, failCallback) {
    // 存下在構造函數中傳入的回調函數
    this.doneCallback = doneCallback;
    this.failCallback = failCallback;
  }

  apply(compiler) {
    compiler.plugin('done', (stats) => {
        // 在 done 事件中回調 doneCallback
        this.doneCallback(stats);
    });
    compiler.plugin('failed', (err) => {
        // 在 failed 事件中回調 failCallback
        this.failCallback(err);
    });
  }
}
// 導出插件 
module.exports = EndWebpackPlugin;

從開發這個插件可以看出，找到合適的事件點去完成功能在開發插件時顯得尤爲重要。 在 工作原理概括 中詳細介紹過 Webpack 在運行過程中廣播出常用事件，你可以從中找到你需要的事件。

調試 Webpack

在編寫 Webpack 的 Plugin 和 Loader 時，可能執行結果會和你預期的不一樣，就和你平時寫代碼遇到了奇怪的 Bug 一樣。 對於無法一眼看出問題的 Bug，通常需要調試程序源碼才能找出問題所在。

雖然可以通過 console.log 的方式完成調試，但這種方法非常不方便也不優雅，本節將教你如何斷點調試 工作原理概括 中的插件代碼。 由於 Webpack 運行在 Node.js 之上，調試 Webpack 就相對於調試 Node.js 程序。

在 Webstorm 中調試

Webstorm 集成了 Node.js 的調試工具，因此使用 Webstorm 調試 Webpack 非常簡單。

1. 設置斷點

在你認爲可能出現問題的地方設下斷點，點擊編輯區代碼左側出現紅點表示設置了斷點。

2. 配置執行入口

告訴 Webstorm 如何啓動 Webpack，由於 Webpack 實際上就是一個 Node.js 應用，因此需要新建一個 Node.js 類型的執行入口。

以上配置中有三點需要注意：

• Name 設置成了 debug webpack，就像設置了一個別名，方便記憶和區分；
• Working directory 設置爲需要調試的插件所在的項目的根目錄；
• JavaScript file 即 Node.js 的執行入口文件，設置爲 Webpack 的執行入口文件 node_modules/webpack/bin/webpack.js。

3. 啓動調試

經過以上兩步，準備工作已經完成，下面啓動調試，啓動時選中前面設置的 debug webpack。

4. 執行到斷點

啓動後程序就會停在斷點所在的位置，在這裏你可以方便的查看變量當前的狀態，找出問題。

原理總結

Webpack 是一個龐大的 Node.js 應用，如果你閱讀過它的源碼，你會發現實現一個完整的 Webpack 需要編寫非常多的代碼。 但你無需瞭解所有的細節，只需瞭解其整體架構和部分細節即可。

對 Webpack 的使用者來說，它是一個簡單強大的工具； 對 Webpack 的開發者來說，它是一個擴展性的高系統。

Webpack 之所以能成功，在於它把複雜的實現隱藏了起來，給用戶暴露出的只是一個簡單的工具，讓用戶能快速達成目的。 同時整體架構設計合理，擴展性高，開發擴展難度不高，通過社區補足了大量缺失的功能，讓 Webpack 幾乎能勝任任何場景。