摘要：每一個模塊的源代碼都會被組織在一個立即執(zhí)行的函數(shù)里。接下來看的生成代碼可以看到，的源代碼中關(guān)于引入的模塊的部分做了修改，因?yàn)闊o論是，或是風(fēng)格的，都無法被解釋器直接執(zhí)行，它需要依賴模塊管理系統(tǒng)，把這些抽象的關(guān)鍵詞具體化。

現(xiàn)在前端用Webpack打包JS和其它文件已經(jīng)是主流了，加上Node的流行，使得前端的工程方式和后端越來越像。所有的東西都模塊化，最后統(tǒng)一編譯。Webpack因?yàn)榘姹镜牟粩喔乱约案鞣N各樣紛繁復(fù)雜的配置選項(xiàng)，在使用中出現(xiàn)一些迷之錯誤常常讓人無所適從。所以了解一下Webpack究竟是怎么組織編譯模塊的，生成的代碼到底是怎么執(zhí)行的，還是很有好處的，否則它就永遠(yuǎn)是個黑箱。當(dāng)然了我是前端小白，最近也是剛開始研究Webpack的原理，在這里做一點(diǎn)記錄。

編譯兩個字聽起來就很黑科技，加上生成的代碼往往是一大坨不知所云的東西，所以常常會讓人卻步，但其實(shí)里面的核心原理并沒有什么難。所謂的Webpack的編譯，其實(shí)只是Webpack在分析了你的源代碼后，對其作出一定的修改，然后把所有源代碼統(tǒng)一組織在一個文件里而已。最后生成一個大的bundle JS文件，被瀏覽器或者其它Javascript引擎執(zhí)行并返回結(jié)果。

在這里用一個簡單的案例來說明Webpack打包模塊的原理。例如我們有一個模塊mA.js

var aa = 1;

function inc() {
  aa++;
}

module.exports = {
  aa: aa,
  inc: inc
}

我隨便定義了一個變量aa和一個函數(shù)inc，然后export出來，這里是用CommonJS的寫法。

然后再定義一個app.js，作為main文件，仍然是CommonJS風(fēng)格：

var mA = require("./mA.js");

console.log("mA.aa =" + mA.aa);
mA.inc();

現(xiàn)在我們有了兩個模塊，使用Webpack來打包，入口文件是app.js，依賴于模塊mA.js，Webpack要做幾件事情：

從入口模塊app.js開始，分析所有模塊的依賴關(guān)系，把所有用到的模塊都讀取進(jìn)來。

每一個模塊的源代碼都會被組織在一個立即執(zhí)行的函數(shù)里。

改寫模塊代碼中和require和export相關(guān)的語法，以及它們對應(yīng)的引用變量。

在最后生成的bundle文件里建立一套模塊管理系統(tǒng)，能夠在runtime動態(tài)加載用到的模塊。

我們可以看一下上面這個例子，Webpack打包出來的結(jié)果。最后的bundle文件總的來說是一個大的立即執(zhí)行的函數(shù)，組織層次比較復(fù)雜，大量的命名也比較晦澀，所以我在這里做了一定改寫和修飾，把它整理得盡量簡單易懂。

首先是把所有用到的模塊都羅列出來，以它們的文件名（一般是完整路徑）為ID，建立一張表：

var modules = {
  "./mA.js": generated_mA,
  "./app.js": generated_app
}

關(guān)鍵是上面的generated_xxx是什么？它是一個函數(shù)，它把每個模塊的源代碼包裹在里面，使之成為一個局部的作用域，從而不會暴露內(nèi)部的變量，實(shí)際上就把每個模塊都變成一個執(zhí)行函數(shù)。它的定義一般是這樣：

function generated_module(module, exports, webpack_require) {
   // 模塊的具體代碼。
   // ...
}

在這里模塊的具體代碼是指生成代碼，Webpack稱之為generated code。例如mA，經(jīng)過改寫得到這樣的結(jié)果：

function generated_mA(module, exports, webpack_require) {
  var aa = 1;
  
  function inc() {
    aa++;
  }

  module.exports = {
    aa: aa,
    inc: inc
  }
}

乍一看似乎和源代碼一模一樣。的確，mA沒有require或者import其它模塊，export用的也是傳統(tǒng)的CommonJS風(fēng)格，所以生成代碼沒有任何改動。不過值得注意的是最后的module.exports = ...，這里的module就是外面?zhèn)鬟M(jìn)來的參數(shù)module，這實(shí)際上是在告訴我們，運(yùn)行這個函數(shù)，模塊mA的源代碼就會被執(zhí)行，并且最后需要export的內(nèi)容就會被保存到外部，到這里就標(biāo)志著mA加載完成，而那個外部的東西實(shí)際上就后面要說的模塊管理系統(tǒng)。

接下來看app.js的生成代碼：

function generated_app(module, exports, webpack_require) {
  var mA_imported_module = webpack_require("./mA.js");
  
  console.log("mA.aa =" + mA_imported_module["aa"]);
  mA_imported_module["inc"]();
}

可以看到，app.js的源代碼中關(guān)于引入的模塊mA的部分做了修改，因?yàn)闊o論是require/exports，或是ES6風(fēng)格的import/export，都無法被JavaScript解釋器直接執(zhí)行，它需要依賴模塊管理系統(tǒng)，把這些抽象的關(guān)鍵詞具體化。也就是說，webpack_require就是require的具體實(shí)現(xiàn)，它能夠動態(tài)地載入模塊mA，并且將結(jié)果返回給app。

到這里你腦海里可能已經(jīng)初步逐漸構(gòu)建出了一個模塊管理系統(tǒng)的想法，一切的關(guān)鍵就是webpack_require，我們來看一下它的實(shí)現(xiàn)：

// 加載完畢的所有模塊。
var installedModules = {};

function webpack_require(moduleId) {
  // 如果模塊已經(jīng)加載過了，直接從Cache中讀取。
  if (installedModules[moduleId]) {
    return installedModules[moduleId].exports;
  }

  // 創(chuàng)建新模塊并添加到installedModules。
  var module = installedModules[moduleId] = {
    id: moduleId,
    exports: {}
  };
  
  // 加載模塊，即運(yùn)行模塊的生成代碼，
  modules[moduleId].call(
    module.exports, module, module.exports, webpack_require);
  
  return module.exports;
}

注意倒數(shù)第二句里的modules就是我們之前定義過的所有模塊的generated code：

var modules = {
  "./mA.js": generated_mA,
  "./app.js": generated_app
}

webpack_require的邏輯寫得很清楚，首先檢查模塊是否已經(jīng)加載，如果是則直接從Cache中返回模塊的exports結(jié)果。如果是全新的模塊，那么就建立相應(yīng)的數(shù)據(jù)結(jié)構(gòu)module，并且運(yùn)行這個模塊的generated code，這個函數(shù)傳入的正是我們建立的module對象，以及它的exports域，這實(shí)際上就是CommonJS里exports和module的由來。當(dāng)運(yùn)行完這個函數(shù)，模塊就被加載完成了，需要export的結(jié)果保存到了module對象中。

所以我們看到所謂的模塊管理系統(tǒng)，原理其實(shí)非常簡單，只要耐心將它們抽絲剝繭理清楚了，根本沒有什么深奧的東西，就是由這三個部分組成：

// 所有模塊的生成代碼
var modules；
// 所有已經(jīng)加載的模塊，作為緩存表
var installedModules；
// 加載模塊的函數(shù)
function webpack_require(moduleId);

當(dāng)然以上一切代碼，在整個編譯后的bundle文件中，都被包在一個大的立即執(zhí)行的匿名函數(shù)中，最后我們需要執(zhí)行的就是這么一句話：

return webpack_require("./app.js");

即加載入口模塊app.js，當(dāng)運(yùn)行它時(shí)，就會運(yùn)行generated_app；而它需要載入模塊mA，于是就會運(yùn)行webpack_require("./mA.js")，進(jìn)而運(yùn)行generated_mA。也就是說，所有的依賴的模塊就是這樣動態(tài)地、遞歸地在runtime完成加載，并被放入InstalledModules緩存。

Webpack真正生成的代碼和我上面整理的結(jié)構(gòu)略有不同，它大致是這樣：

(function(modules) {
  var installedModules = {};
  
  function webpack_require(moduleId) {
     // ...
  }

  return webpack_require("./app.js");
}) ({
  "./mA.js": generated_mA,
  "./app.js": generated_app
});

可以看到它是直接把modules作為立即執(zhí)行函數(shù)的參數(shù)傳進(jìn)去的而不是另外定義的，當(dāng)然這和我的寫法沒什么本質(zhì)不同，我做這樣的改寫是為了解釋起來更清楚。

以上的例子里都是用傳統(tǒng)的CommonJS的寫法，現(xiàn)在更通用的ES6風(fēng)格是用import和export關(guān)鍵詞，它們看上去似乎只是語法糖，但實(shí)際上根據(jù)ES6的標(biāo)準(zhǔn)，它們和CommonJS在關(guān)于模塊加載的使用和行為上會有一些微妙的不同。例如當(dāng)CommonJS輸出原始類型（非對象）變量時(shí)，輸出的是這個變量的拷貝，這樣一旦模塊加載后，再去修改這個內(nèi)部變量的值，是不會影響到輸出的變量的；而ES6輸出的則是引用，這樣無論模塊內(nèi)部出現(xiàn)什么修改，都會反映在已經(jīng)加載的模塊上。關(guān)于ES6和CommonJS在模塊管理上的區(qū)別，如果你還不熟悉的話，建議先讀一下阮一峰大神的這篇文章。

對于Webpack或者其它模塊管理系統(tǒng)而言，要實(shí)現(xiàn)ES6特性的import/export，本質(zhì)上還是和require/exports類似的，也就是說仍然使用module.export這一套機(jī)制，但是情況會變得比較復(fù)雜，因?yàn)榭赡艽嬖贑ommonJS和ES6模塊之間的相互引用。為了保持兼容，并且符合ES6的相應(yīng)標(biāo)準(zhǔn)，Webpack在生成相應(yīng)語句的generated code時(shí)，就要做很多特殊處理，關(guān)于這一塊內(nèi)容很多，深究起來可以多帶帶寫一篇文章，在這里我只是把我理解的部分寫出來。

export原始類型變量

對于CommonJS而言，export的是很直接的，因?yàn)樵创a里module.exports輸出什么，生成代碼里的輸出也原樣不變，例如我們之前定義的模塊mA.js：

var aa = 1;
function inc() {
  aa++;
}

function get_aa() {
  return aa;
}

module.exports = {
  aa: aa,
  inc: inc,
  get_aa: get_aa;
}

生成代碼里，module.exports也會像源代碼里這樣寫，注意這里輸出的時(shí)候，aa作為一個原始類型，輸出到module.exports里的是一個拷貝，這樣一旦模塊mA加載后，再去調(diào)用inc()，修改的是模塊內(nèi)部的aa，而不會影響輸出后的aa:

var mA = require("./mA.js");

console.log("mA.aa = " + mA.aa);  // 輸出1
mA.inc();
console.log("mA.aa = " + mA.aa);  // 仍然是1

// 這里會輸出2，因?yàn)間et_aa()拿到的是模塊內(nèi)部的aa原始引用。
console.log("mA.get_aa() = " + mA.get_aa());

然而ES6就完全不是這么一回事兒了，假如上面的模塊mA，我們用ES6輸出：

export {aa, inc, get_aa}

然后在別的模塊里加載mA：

import {aa, inc} from "./mA.js"

console.log("aa = " + aa);  // 輸出1
inc();
console.log("aa = " + aa);  // 輸出2

這里不管mA輸出的是什么類型的數(shù)據(jù)，輸出的都是它的引用，當(dāng)別的模塊載入mA時(shí)，得到的也是mA模塊內(nèi)部變量的引用。要實(shí)現(xiàn)這個規(guī)則，mA的generated code就不能簡單地直接給module.exports設(shè)置aa這個原始變量類型了，而是像上面的get_aa那樣，給它定義getter。例如當(dāng)我們export aa，Webpack會生成類似于這樣的代碼：

var aa = 1;

defineGetter(module.exports, “aa”, function(){ return aa; });

defineGetter的定義如下：

function defineGetter(exports, name, getter) {
  if (!Object.prototype.hasOwnProperty.call(exports, name)) {
    Object.defineProperty(exports, name, {
      configurable: false,
      enumerable: true,
      get: getter,
    });
  }
}

這樣就實(shí)現(xiàn)了我們需要的引用功能，也就是說，在module.exports上，我們并不是定義aa這個原始類型，而是定義aa的getter，使之指向其原模塊內(nèi)部aa的引用。

不過對于export default，當(dāng)輸出原始類型時(shí)，它又回到了拷貝，而不是getter引用的方式，即對于這樣的輸出：

export default aa;

Webpack會生成這樣的代碼：

module.exports["default"] = aa;

我還沒完全弄清楚這樣做是否符合ES6標(biāo)準(zhǔn)，懂的童鞋可以留下評論。

當(dāng)然話說回來，模塊中直接輸出aa這樣的原始類型的變量還是挺少見的，但并非不可能。源代碼一旦有這樣的行為，ES6和CommonJS就會表現(xiàn)出完全不同的特性，所以Webpack也必須實(shí)現(xiàn)這種區(qū)別。

__esModule：

Webpack對ES6模塊輸出的另一個特殊處理是__esModule，例如是我們定義ES6模塊mB.js:

let x = 3;

let printX = () => {
  console.log("x = " + x);
}

export {printX}
export default x

它使用了ES6的export，那么Webpack在mB的generated code會加上一句話：

function generated_mB(module, exports, webpack_require) {
  Object.defineProperty(module.exports, "__esModule", {value: true});
  // mB的具體代碼
  // ....
}

也就是說，它給mB的export標(biāo)注了一個__esModule，說明它是ES6風(fēng)格的export。為什么要這樣做？因?yàn)楫?dāng)別人引用一個模塊時(shí)，它并不知道這個模塊是以CommonJS還是ES6風(fēng)格輸出的，所以__esModule的意義就在于告訴別人，這是一個ES6模塊。關(guān)于它的具體作用我們繼續(xù)看下面的import部分。

import：

這是一種比較簡單的import方式：

import {aa} from "./mA.js"
// 基本等價(jià)于
var aa = require("./mA.js")["aa"]

但是當(dāng)別人這樣引用時(shí)：

import m from "./m.js"

情況會稍微復(fù)雜一點(diǎn)，它需要載入模塊m的export default部分，而模塊m可能并非是由ES6的export來寫的，也可能根本沒有export default。這樣在其它模塊中，當(dāng)一個依賴模塊以類似import m from "./m.js"這樣的方式加載時(shí)，必須首先判斷得到的是不是一個ES6 export出來的模塊。如果是，則返回它的default，如果不是，則返回整個export對象。例如上面的mA是傳統(tǒng)CommonJS的，mB是ES6風(fēng)格的：

// mA is CommonJS module
import mA from "./mA.js"
console.log(mA);

// mB is ES6 module
import mB from "./mB.js"
console.log(mB);

這就用到了之前export部分的__esModule了。我們定義get_export_default函數(shù)：

function get_export_default(module) {
  return module && module.__esModule? module["default"] : module;
}

這樣generated code運(yùn)行后在mA和mB上會得到不同的結(jié)果：

var mA_imported_module = webpack_require("./mA.js");
// 打印完整的 mA_imported_module
console.log(get_export_default(mA_imported_module));

var mB_imported_module = webpack_require("./mB.js");
// 打印 mB_imported_module["default"]
console.log(get_export_default(mB_imported_module));

以上就是在ES6的import/export上，Webpack需要做很多特殊處理的地方。我的分析還并不完整，建議感興趣的童鞋自己去敲一下并且閱讀編譯后的代碼，仔細(xì)比較CommonJS和ES6的不同。不過就實(shí)現(xiàn)而言，它們并沒有本質(zhì)區(qū)別，而且Webpack最后生成的generated code也還是基于CommonJS的module/exports這一套機(jī)制來實(shí)現(xiàn)模塊的加載的。

以上就是Webpack如何打包組織模塊，實(shí)現(xiàn)runtime模塊加載的解讀，其實(shí)它的原理并不難，核心的思想就是建立模塊的管理系統(tǒng)，而這樣的做法也是具有普遍性的，如果你讀過Node.js的Module部分的源代碼，就會發(fā)現(xiàn)其實(shí)用的是類似的方法。這里有一篇文章可以參考。