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

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

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

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

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

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

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

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

接下來(lái)我們簡(jiǎn)單節(jié)選幾個(gè)函數(shù)分析一下：

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

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

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

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

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

// 模擬兩個(gè)插件
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

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

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

大部分代碼和 applyPluginsAsync 有點(diǎn)兒類似

這個(gè) applyPluginsParallel 主要功能和 最簡(jiǎn)單的 applyPlugins 方法比較相似，無(wú)論如何都會(huì)讓所有注冊(cè)的插件運(yùn)行一遍；

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

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

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

如果讓 第二個(gè) cb()的第一個(gè)值不是 null，比如 cb("err")，則 callback 之后輸出這個(gè)錯(cuò)誤，之后再也不會(huì)調(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

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

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

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

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

但其中的 callback 只會(huì)執(zhí)行一次（當(dāng)傳給cb的值不是undefined/null 的時(shí)候），這一次執(zhí)行順序是插件定義順序有關(guān)，而跟每個(gè)插件中的 cb() 執(zhí)行時(shí)間無(wú)關(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)});

// 運(yùn)行結(jié)果

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

這是最普通的運(yùn)行情況，我們稍微調(diào)整一下（注意三個(gè)插件運(yùn)行的順序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)});
// 運(yùn)行結(jié)果

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

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

這是因?yàn)椴寮?cè)順序是 1-2-3，雖然運(yùn)行的時(shí)候順序是 2-1-3，但所運(yùn)行的還是 1 對(duì)應(yīng)的 cb；所以，就算1執(zhí)行的速度最慢（比如把其setTimeout的值設(shè)置成 2000），運(yùn)行的 cb 仍然是1對(duì)應(yīng)的cb;

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

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

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

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

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

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

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

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

entry-option：初始化options

run：開(kāi)始編譯

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

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

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

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

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

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

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

bootstrap： 生成啟動(dòng)代碼

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

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

webpack 源碼解析

細(xì)說(shuō) webpack 之流程篇

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

如何寫(xiě)一個(gè)webpack插件

plugins官方文檔：

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