摘要：所有依賴這個模塊的語句，都定義在一個回調函數中，等到所有依賴加載完成之后前置依賴，這個回調函數才會運行。如果將前面的代碼改寫成形式，就是下面這樣定義了一個文件，該文件依賴模塊，當模塊加載完畢之后執行回調函數，這里并沒有暴露任何變量。

模塊化是我們日常開發都要用到的基本技能，使用簡單且方便，但是很少人能說出來但是的原因及發展過程。現在通過對比不同時期的js的發展，將JavaScript模塊化串聯起來整理學習記憶。

技術的誕生是為了解決某個問題，模塊化也是。在js模塊化誕生之前，開發者面臨很多問題：隨著前端的發展，web技術日趨成熟，js功能越來越多，代碼量也越來越大。之前一個項目通常各個頁面公用一個js，但是js逐漸拆分，項目中引入的js越來越多：

當年我剛剛實習的時候，項目中的js就是類似這樣，這樣的js引入造成了問題：

全局變量污染：各個文件的變量都是掛載到window對象上，污染全局變量。

變量重名：不同文件中的變量如果重名，后面的會覆蓋前面的，造成程序運行錯誤。

文件依賴順序：多個文件之間存在依賴關系，需要保證一定加載順序問題嚴重。

這些問題嚴重干擾開發，也是日常開發中經常遇到的問題。

我覺得用樂高積木來比喻模塊化再好不過了。每個積木都是固定的顏色形狀，想要組合積木必須使用積木凸起和凹陷的部分進行連接，最后多個積木累積成你想要的形狀。

模塊化其實是一種規范，一種約束，這種約束會大大提升開發效率。將每個js文件看作是一個模塊，每個模塊通過固定的方式引入，并且通過固定的方式向外暴露指定的內容。

按照js模塊化的設想，一個個模塊按照其依賴關系組合，最終插入到主程序中。

模塊化這種規范提出之后，得到社區和廣大開發者的響應，不同時間點有多種實現方式。我們舉個例子：a.js

// a.js
var aStr = "aa";
var aNum = cNum + 1;

b.js

// b.js
var bStr = aStr + " bb";

c.js

// c.js
var cNum = 0;

index.js

// index.js
console.log(aNum, bStr);

四份文件，不同的依賴關系（a依賴c，b依賴a，index依賴a b）在沒有模塊化的時候我們需要頁面中這樣：

嚴格保證加載順序，否則報錯。

這是最容易想到的也是最簡便的解決方式，早在模塊化概念提出之前很多人就已經使用閉包的方式來解決變量重名和污染問題。

這樣每個js文件都是使用IIFE包裹的，各個js文件分別在不同的詞法作用域中，相互隔離，最后通過閉包的方式暴露變量。每個閉包都是多帶帶一個文件，每個文件仍然通過script標簽的方式下載，標簽的順序就是模塊的依賴關系。

上面的例子我們用該方法修改下寫法：

a.js

// a.js
var a = (function(cNum){
   var aStr = "aa";
   var aNum = cNum + 1; 
    
    return {
       aStr: aStr,
       aNum: aNum
    };
})(cNum);

b.js

// b.js
var bStr = (function(a){
   var bStr = a.aStr + " bb";
    
   return bStr;
})(a);

c.js

// c.js
var cNum = (function(){
   var cNum = 0;
    
   return cNum;
})();

index.js

;(function(a, bStr){
    console.log(a.aNum, bStr);
})(a, bStr)

這種方法下仍然需要在入口處嚴格保證加載順序：

這種方式最簡單有效，也是后續其他解決方案的基礎。這樣做的意義：

各個js文件之間避免了變量重名干擾，并且最少的暴露變量，避免全局污染。

模塊外部不能輕易的修改閉包內部的變量，程序的穩定性增加。

模塊與外部的連接通過IIFE傳參，語義化更好，清晰地知道有哪些依賴。

不過各個模塊的依賴關系仍然要通過加裝script的順序來保證。

一開始一些人在閉包的解決方案上做出了規范約束：每個js文件始終返回一個object，將內容作為object的屬性。

比如上面的例子中b.js

// b.js
var b = (function(a){
   var bStr = a.aStr + " bb";
    
   return {
       bStr: bStr
   };
})(a);

及時返回的是個值，也要用object包裹。后來很多人開始使用面向對象的方式開發插件：

;(function($){
    var LightBox = function(){
        // ...
    };
    
    LightBox.prototype = {
        // ....
    };
    
    window["LightBox"] = LightBox;
})($);

使用的時候：

var lightbox = new LightBox();

當年很多人都喜歡這樣開發插件，并且認為能寫出這種插件的水平至少不低。這種方法只是閉包方式的小改進，約束js文件返回必須是對象，對象其實就是一些個方法和屬性的集合。這樣的優點：

規范化輸出，更加統一的便于相互依賴和引用。

使用‘類’的方式開發，便于后面的依賴進行擴展。

本質上這種方法只是對閉包方法的規范約束，并沒有做什么根本改動。

早期雅虎出品的一個工具，模塊化管理只是一部分，其還具有JS壓縮、混淆、請求合并（合并資源需要server端配合）等性能優化的工具，說其是現有JS模塊化的鼻祖一點都不過分。

// YUI - 編寫模塊
YUI.add("dom", function(Y) {
  Y.DOM = { ... }
})

// YUI - 使用模塊
YUI().use("dom", function(Y) {
  Y.DOM.doSomeThing();
  // use some methods DOM attach to Y
})

// hello.js
YUI.add("hello", function(Y){
    Y.sayHello = function(msg){
        Y.DOM.set(el, "innerHTML", "Hello!");
    }
},"3.0.0",{
    requires:["dom"]
})

// main.js
YUI().use("hello", function(Y){
    Y.sayHello("hey yui loader");
})

YUI的出現令人眼前一新，他提供了一種模塊管理方式：通過YUI全局對象去管理不同模塊，所有模塊都只是對象上的不同屬性，相當于是不同程序運行在操作系統上。YUI的核心實現就是閉包，不過好景不長，具有里程碑式意義的模塊化工具誕生了。

2009年Nodejs發布，其中Commonjs是作為Node中模塊化規范以及原生模塊面世的。Node中提出的Commonjs規范具有以下特點：

原生Module對象，每個文件都是一個Module實例

文件內通過require對象引入指定模塊

所有文件加載均是同步完成

通過module關鍵字暴露內容

每個模塊加載一次之后就會被緩存

模塊編譯本質上是沙箱編譯

由于使用了Node的api，只能在服務端環境上運行

基本上Commonjs發布之后，就成了Node里面標準的模塊化管理工具。同時Node還推出了npm包管理工具，npm平臺上的包均滿足Commonjs規范，隨著Node與npm的發展，Commonjs影響力也越來越大，并且促進了后面模塊化工具的發展，具有里程碑意義的模塊化工具。之前的例子我們這樣改寫：

a.js

// a.js
var c = require("./c");

module.exports = {
    aStr: "aa",
    aNum: c.cNum + 1
};

b.js

// b.js
var a = require("./a");

exports.bStr = a.aStr + " bb";

c.js

// c.js
exports.cNum = 0;

入口文件就是 index.js

var a = require("./a");
var b = require("./b");

console.log(a.aNum, b.bStr);

可以直觀的看到，使用Commonjs管理模塊，十分方便。Commonjs優點在于：

強大的查找模塊功能，開發十分方便

標準化的輸入輸出，非常統一

每個文件引入自己的依賴，最終形成文件依賴樹

模塊緩存機制，提高編譯效率

利用node實現文件同步讀取

依靠注入變量的沙箱編譯實現模塊化

這里補充一點沙箱編譯：require進來的js模塊會被Module模塊注入一些變量，使用立即執行函數編譯，看起來就好像：

(function (exports, require, module, __filename, __dirname) {
    //原始文件內容
})();

看起來require和module好像是全局對象，其實只是閉包中的入參，并不是真正的全局對象。之前專門整理探究過 Node中的Module源碼分析，也可以看看阮一峰老師的require()源碼解讀，或者廖雪峰老師的CommonJS規范。

Commonjs的誕生給js模塊化發展有了重要的啟發，Commonjs非常受歡迎，但是局限性很明顯：Commonjs基于Node原生api在服務端可以實現模塊同步加載，但是僅僅局限于服務端，客戶端如果同步加載依賴的話時間消耗非常大，所以需要一個在客戶端上基于Commonjs但是對于加載模塊做改進的方案，于是AMD規范誕生了。

AMD是"Asynchronous Module Definition"的縮寫，意思就是"異步模塊定義"。它采用異步方式加載模塊，模塊的加載不影響它后面語句的運行。所有依賴這個模塊的語句，都定義在一個回調函數中，等到所有依賴加載完成之后（前置依賴），這個回調函數才會運行。

AMD與Commonjs一樣都是js模塊化規范，是一套抽象的約束，與2009年誕生。文檔這里。該約束規定采用require語句加載模塊，但是不同于CommonJS，它要求兩個參數：

require([module], callback);

第一個參數[module]，是一個數組，里面的成員就是要加載的模塊；第二個參數callback，則是加載成功之后的回調函數。如果將前面的代碼改寫成AMD形式，就是下面這樣：

require(["math"], function (math) {

    math.add(2, 3);

});

定義了一個文件，該文件依賴math模塊，當math模塊加載完畢之后執行回調函數，這里并沒有暴露任何變量。不同于Commonjs，在定義模塊的時候需要使用define函數定義：

define(id?, dependencies?, factory);

define方法與require類似，id是定義模塊的名字，仍然會在所有依賴加載完畢之后執行factory。

RequireJs是js模塊化的工具框架，是AMD規范的具體實現。但是有意思的是，RequireJs誕生之后，推廣過程中產生的AMD規范。文檔這里。

RequireJs有兩個最鮮明的特點：

依賴前置：動態創建

RequireJs當年在國內非常受歡迎，主要是以下優點：

define(id?, dependencies?, factory);

a1
a2
b1
b2
c1
c2

a1
a2
b1
b2
c1
c2
inner a1
inner c1 
inner b1
index

import {cNum} from "./c";

export default {
    aStr: "aa",
    aNum: cNum + 1
};

import {aStr} from "./a";

export const bStr = aStr + " bb";

export const bNum = 0;

import {aNum} from "./a";
import {bStr} from "./b";

console.log(aNum, bStr);

// counter.js
exports.count = 0
setTimeout(function () {
  console.log("increase count to", ++exports.count, "in counter.js after 500ms")
}, 500)

// commonjs.js
const {count} = require("./counter")
setTimeout(function () {
  console.log("read count after 1000ms in commonjs is", count)
}, 1000)

//es6.js
import {count} from "./counter"
setTimeout(function () {
  console.log("read count after 1000ms in es6 is", count)
}, 1000)

?  test node commonjs.js
increase count to 1 in counter.js after 500ms
read count after 1000ms in commonjs is 0
?  test babel-node es6.js
increase count to 1 in counter.js after 500ms
read count after 1000ms in es6 is 1