摘要：開始對進(jìn)行遍歷，當(dāng)遇到等一些調(diào)用表達(dá)式時，觸發(fā)事件的執(zhí)行，收集依賴，并。

Tap 的英文單詞解釋，除了最常用的 點擊 手勢之外，還有一個意思是 水龍頭 —— 在 webpack 中指的是后一種；

Webpack 可以認(rèn)為是一種基于事件流的編程范例，內(nèi)部的工作流程都是基于 插件 機(jī)制串接起來；

而將這些插件粘合起來的就是webpack自己寫的基礎(chǔ)類 Tapable 是，plugin方法就是該類暴露出來的；

后面我們將看到核心的對象 Compiler、Compilation 等都是繼承于該對象

基于該類規(guī)范而其的 Webpack 體系保證了插件的有序性，使得整個系統(tǒng)非常有彈性，擴(kuò)展性很好；然而有一個致命的缺點就是調(diào)試、看源碼真是很痛苦，各種跳來跳去；（基于事件流的寫法，和程序語言中的 goto 語句很類似）

把這個倉庫下載，使用 Webstorm 進(jìn)行調(diào)試，test 目錄是很好的教程入口；

Tapable.plugin()：相當(dāng)于把對象歸類到名為 name 的對象下，以array的形式；所有的插件都存在私有變量 _plugin 變量中；

接下來我們簡單節(jié)選幾個函數(shù)分析一下：

該方法最普通也是最常用的，看一下它的定義：

Tapable.prototype.apply = function apply() {
    for(var i = 0; i < arguments.length; i++) {
        arguments[i].apply(this);
    }
};

毫無懸念，就是 挨個順序 執(zhí)行傳入到該函數(shù)方法中對象的 apply 方法；通常傳入該函數(shù)的對象也是 Tapable 插件 對象，因此必然也存在 apply 方法；（Webpack 的插件就是Tapable對象，因此必須要提供 apply 方法 ）

只是更改上下文為當(dāng)前 this

因此當(dāng)前這里最大的作用就是傳入當(dāng)前 Tapable 的上下文

// 模擬兩個插件
var _plugins = {
    "emit":[
        function(a,b,cb){
            setTimeout(()=>{
              console.log("1",a,b);
              cb();
            },1000);
        },
        function(a,b,cb){
            setTimeout(()=>{
                console.log("2",a,b);
                cb();
            },500)
        }
    ]
}

applyPluginsAsync("emit","aaaa","bbbbb",function(){console.log("end")});

// 輸出結(jié)果：

// 1 aaaa bbbbb
// 2 aaaa bbbbb
//  end

我們看到，雖然第一個插件是延后 1000ms 執(zhí)行，第二個則是延后 500ms，但在真正執(zhí)行的時候，是嚴(yán)格按照順序執(zhí)行的；每個插件需要在最后顯式調(diào)用cb()通知下一個插件的運行；

這里需要注意每個插件的形參的個數(shù)都要一致，且最后一個必須是cb()方法，用于喚起下一個插件的運行；cb的第一個參數(shù)是err，如果該參數(shù)不為空，就直接調(diào)用最后callback，中斷后續(xù)插件的運行；

大部分代碼和 applyPluginsAsync 有點兒類似

這個 applyPluginsParallel 主要功能和 最簡單的 applyPlugins 方法比較相似，無論如何都會讓所有注冊的插件運行一遍；

只是相比 applyPlugins 多了一個額外的功能，它最后 提供一個 callback 函數(shù)，這個 callback 的函數(shù)比較倔強(qiáng)，如果所有的插件x都正常執(zhí)行，且最后都cb()，則會在最后執(zhí)行callback里的邏輯；不過，一旦其中某個插件運行出錯，就會調(diào)用這個callback(err)，之后就算插件有錯誤也不會再調(diào)用該callback函數(shù)；

var _plugins = {
"emit":[
    function(a,b,cb){
        setTimeout(()=>{
          console.log("1",a,b);
          cb(null,"e222","33333");
        },1000);
    },
    function(a,b,cb){
        setTimeout(()=>{
            console.log("2",a,b);
            cb(null,"err");
        },500)
    }
]
}

applyPluginsParallel("emit","aaaa","bbbbb",function(a,b){console.log("end",a,b)});

// 輸出結(jié)果：

// 2 aaaa bbbbb
// 1 aaaa bbbbb
//  end undefined undefined

上面的兩個插件都是調(diào)用了 cb，且第一個參數(shù)是 null（表示沒有錯誤），所以最后能輸出 callback 函數(shù)中的 console 內(nèi)容；

如果注釋兩個插件中任何一個 cb() 調(diào)用，你會發(fā)現(xiàn)最后的 callback 沒有執(zhí)行；

如果讓 第二個 cb()的第一個值不是 null，比如 cb("err")，則 callback 之后輸出這個錯誤，之后再也不會調(diào)用此 callback：

var _plugins = {
"emit":[
    function(a,b,cb){
        setTimeout(()=>{
          console.log("1",a,b);
          cb("e222","33333");
        },1000);
    },
    function(a,b,cb){
        setTimeout(()=>{
            console.log("2",a,b);
            cb("err");
        },500)
    }
]
}

// 輸出結(jié)果：

// 2 aaaa bbbbb
// end err undefined
// 1 aaaa bbbbb

顧名思義，這個方法相當(dāng)于是 瀑布式 調(diào)用，給第一個插件傳入初始對象 init，然后經(jīng)過第一個插件調(diào)用之后會獲得一個結(jié)果對象，該結(jié)果對象會傳給下一個插件 作為初始值，直到最后調(diào)用完畢，最后一個插件的直接結(jié)果傳給 callback 作為初始值；

這個方法應(yīng)該是所有方法中最難理解的；

首先它的行為和 applyPluginsParallel 非常相似，首先會 無論如何都會讓所有注冊的插件運行一遍（根據(jù)注冊的順序）；

為了讓 callback 執(zhí)行，其前提條件是每個插件都需要調(diào)用 cb()；

但其中的 callback 只會執(zhí)行一次（當(dāng)傳給cb的值不是undefined/null 的時候），這一次執(zhí)行順序是插件定義順序有關(guān)，而跟每個插件中的 cb() 執(zhí)行時間無關(guān)的；

var _plugins = {
"emit":[
    function(a,b,cb){
        setTimeout(()=>{
          console.log("1",a,b);
          cb();
        },1000);
    },
    function(a,b,cb){
        setTimeout(()=>{
            console.log("2",a,b);
            cb();
        },500)
    },
    function(a,b,cb){
        setTimeout(()=>{
            console.log("3",a,b);
            cb();
        },1500)
    }
]
}

applyPluginsParallelBailResult("emit","aaaa","bbbbb",function(a,b){console.log("end",a,b)});

// 運行結(jié)果

// 2 aaaa bbbbb
// 1 aaaa bbbbb
// 3 aaaa bbbbb
// end undefined undefined

這是最普通的運行情況，我們稍微調(diào)整一下（注意三個插件運行的順序2-1-3），分別給cb傳入有效的值：

var _plugins = {
"emit":[
    function(a,b,cb){
        setTimeout(()=>{
          console.log("1",a,b);
          cb("1");
        },1000);
    },
    function(a,b,cb){
        setTimeout(()=>{
            console.log("2",a,b);
            cb("2");
        },500)
    },
    function(a,b,cb){
        setTimeout(()=>{
            console.log("3",a,b);
            cb("3");
        },1500)
    }
]
}
applyPluginsParallelBailResult("emit","aaaa","bbbbb",function(a,b){console.log("end",a,b)});
// 運行結(jié)果

// 2 aaaa bbbbb
// 1 aaaa bbbbb
// end 1 undefined
// 3 aaaa bbbbb

可以發(fā)現(xiàn)第1個插件 cb("1") 執(zhí)行了，后續(xù)的 cb("2") 和 cb("3") 都給忽略了；

這是因為插件注冊順序是 1-2-3，雖然運行的時候順序是 2-1-3，但所運行的還是 1 對應(yīng)的 cb；所以，就算1執(zhí)行的速度最慢（比如把其setTimeout的值設(shè)置成 2000），運行的 cb 仍然是1對應(yīng)的cb;

其中涉及的魔法是 閉包，傳入的i就是和注冊順序綁定了
這樣一說明，你會發(fā)現(xiàn) applyPluginsParallel 的 cb 執(zhí)行時機(jī)是和執(zhí)行時間有關(guān)系的，你可以自己驗證一下；

總結(jié)一下，Tapable 就相當(dāng)于是一個 事件管家，它所提供的 plugin 方法類似于 addEventListen 監(jiān)聽事件，apply 方法類似于事件觸發(fā)函數(shù) trigger；

既然 Webpack 是基于 Tapable 搭建起來的，那么我們看一下 Webpack 構(gòu)建一個模塊的基本事件流是如何的；

我們在 Webpack 庫中的 Tapable.js 中每個方法中新增 console 語句打出日志，就能找出所有關(guān)鍵的事件名字：

打印結(jié)果：（這里只列舉了簡單的事件流程，打包不同的入口文件會有所差異，但 事件出現(xiàn)的先后順序是固定的 ）

內(nèi)容較多，依據(jù)源碼內(nèi)容的編排，可以將上述進(jìn)行分層；大粒度的事件流如下：

而其中 make、 seal 和 emit 階段比較核心（包含了很多小粒度的事件），后續(xù)會繼續(xù)展開講解；

這里羅列一下關(guān)鍵的事件節(jié)點：

entry-option：初始化options

run：開始編譯

make：從entry開始遞歸的分析依賴，對每個依賴模塊進(jìn)行build

before-resolve - after-resolve： 對其中一個模塊位置進(jìn)行解析

build-module ：開始構(gòu)建 (build) 這個module,這里將使用文件對應(yīng)的loader加載

normal-module-loader：對用loader加載完成的module(是一段js代碼)進(jìn)行編譯,用 acorn 編譯,生成ast抽象語法樹。

program： 開始對ast進(jìn)行遍歷，當(dāng)遇到require等一些調(diào)用表達(dá)式時，觸發(fā) call require 事件的handler執(zhí)行，收集依賴，并。如：AMDRequireDependenciesBlockParserPlugin等

seal： 所有依賴build完成，下面將開始對chunk進(jìn)行優(yōu)化，比如合并,抽取公共模塊,加hash

optimize-chunk-assets：壓縮代碼，插件 UglifyJsPlugin 就放在這個階段

bootstrap： 生成啟動代碼

emit： 把各個chunk輸出到結(jié)果文件

本系列的源碼閱讀，以下幾篇文章給了很多啟發(fā)和思路，其中 webpack 源碼解析 和 細(xì)說 webpack 之流程篇 尤為突出，推薦閱讀；

webpack 源碼解析

細(xì)說 webpack 之流程篇

WebPack學(xué)習(xí)：WebPack內(nèi)置Plugin

如何寫一個webpack插件

plugins官方文檔：

下面的是我的公眾號二維碼圖片，歡迎關(guān)注。