摘要：模塊演化簡史從屬于筆者的開發基礎與工程實踐。首個采樣該設計模式的界面庫當屬，其是創建于年。允許我們定義模塊，并且在顯式地聲明其依賴模塊而由框架完成自動注入。而最后的模塊化規范定義于年正式發布，也就是被命名為。

JavaScript 模塊演化簡史 從屬于筆者的 Web 開發基礎與工程實踐。本文主要總結自 The Evolution of JavaScript Modularity、Native ECMAScript modules - the first overview、Native ECMAScript modules: the new features and differences from Webpack modules 等 JavaScript 語法學習資料索引 中注明的文章，更多深度思考參閱 2016-我的前端之路:工具化與工程化。

當年 Brendan Eich 草創 JavaScript 之際，他應該無法想象 JavaScript 在未來二十年內發揮的巨大作用；同樣作為廣為詬病的過于隨意的語言，缺乏強有力的模塊化解決方案一直是 JavaScript 的缺陷之一。早期的 JavaScript 往往作為嵌入到 HTML 頁面中的用于控制動畫與簡單的用戶交互的腳本語言，我們習慣于將其直接嵌入到 script 標簽中：

不過隨著單頁應用與富客戶端的流行，不斷增長的代碼庫也急需合理的代碼分割與依賴管理的解決方案，這也就是我們在軟件工程領域所熟悉的模塊化（Modularity）。所謂模塊化主要是解決代碼分割、作用域隔離、模塊之間的依賴管理以及發布到生產環境時的自動化打包與處理等多個方面。二十年間流行過的 JavaScript 模塊化解決方案包括但不限于直接聲明依賴（Directly Defined Dependences）、命名空間（Namespace Pattern）、模塊模式（Module Pattern）、依賴分離定義（Detached Dependency Definitions）、沙盒（Sandbox）、依賴注入（Dependency Injection）、CommonJS、AMD、UMD、標簽化模塊（Labeled Modules）、YModules、ES 2015 Modules。
在早期的 Web 開發中，所有的嵌入到網頁內的 JavaScript 對象都會使用全局的 window 對象來存放未使用 var 定義的變量。大概在上世紀末，JavaScript 多用于解決簡單的任務，這也就意味著我們只需編寫少量的 JavaScript 代碼；不過隨著代碼庫的線性增長，我們首先會碰到的就是所謂命名沖突（Name Collisions）困境：

// file greeting.js
var helloInLang = {
    en: "Hello world!",
    es: "?Hola mundo!",
    ru: "Привет мир!"
};

function writeHello(lang) {
    document.write(helloInLang[lang]);
}

// file hello.js
function writeHello() {
    document.write("The script is broken");
}

當我們在頁面內同時引入這兩個 JavaScript 腳本文件時，顯而易見兩個文件中定義的 writeHello 函數起了沖突，最后調用的函數取決于我們引入的先后順序。此外在大型應用中，我們不可能將所有的代碼寫入到單個 JavaScript 文件中；我們也不可能手動地在 HTML 文件中引入全部的腳本文件，特別是此時還存在著模塊間依賴的問題，相信很多開發者都會遇到 jQuery 尚未定義這樣的問題。不過物極必反，過度碎片化的模塊同樣會帶來性能的損耗與包體尺寸的增大，這包括了模塊加載、模塊解析、因為 Webpack 等打包工具包裹模塊時封裝的過多 IIFE 函數導致的 JavaScript 引擎優化失敗等。譬如我們的源碼如下：

// index.js
var total = 0
total += require("./module_0")
total += require("./module_1")
total += require("./module_2")
// etc.
console.log(total)

// module_0.js
module.exports = 0

// module_1.js
module.exports = 1

經過 Browserify 打包之后的代碼變成了如下式樣：

(function e(t,n,r){function s(o,u){if(!n[o]){if(!t[o]){var a=typeof require=="function"&&require;if(!u&&a)return a(o,!0);if(i)return i(o,!0);var f=new Error("Cannot find module ""+o+""");throw f.code="MODULE_NOT_FOUND",f}var l=n[o]={exports:{}};t[o][0].call(l.exports,function(e){var n=t[o][1][e];return s(n?n:e)},l,l.exports,e,t,n,r)}return n[o].exports}var i=typeof require=="function"&&require;for(var o=0;o
我們分別測試 100、1000 與 5000 模塊，可以發現隨著模塊數目的增長最后的包體大小并非線性增長：

命名空間模式
命名空間模式始于 2002 年，顧名思義我們可以使用特殊的約定命名。譬如我們可以為某個模塊內的變量統一添加 myApp_ 前綴，譬如 myApp_address，myApp_validateUser() 等等。同樣，我們也可以將函數賦值給模塊內的變量或者對象的屬性，從而可以使得可以像 document.write() 這樣在子命名空間下定義函數而避免沖突。首個采樣該設計模式的界面庫當屬 Bindows，其是 Erik Arvidsson 創建于 2002 年。他沒有簡單地為自定義函數或者對象添加命名前綴，而是將所有的 Bindows 當中的數據與邏輯代碼封裝于某個全局對象內，從而避免所謂的全局作用域污染。命名空間模式的設計思想如下所示：
// file app.js
var app = {};

// file greeting.js
app.helloInLang = {
    en: "Hello world!",
    es: "?Hola mundo!",
    ru: "Привет мир!"
};

// file hello.js
app.writeHello = function (lang) {
    document.write(app.helloInLang[lang]);
};
我們可以發現自定義代碼中的所有數據對象與函數都歸屬于全局對象 app，不過顯而易見這種方式對于大型多人協同項目的可維護性還是較差，并且沒有解決模塊間依賴管理的問題。另外有時候我們需要處理一些自動執行的 Pollyfill 性質的代碼，就需要將模塊包裹在自調用的函數中，譬如在某個大型應用中，我們的代碼可能會切分為如下幾個模塊：
// polyfill-vendor.js
(function(){
    // polyfills-vendor code
}());

// module1.js
function module1(params){
    // module1 code
    return module1;
}

// module3.js
function module3(params){
    this.a = params.a;
}

module3.prototype.getA = function(){
    return this.a;
};

// app.js
var APP = {};

if(isModule1Needed){
    APP.module1 = module1({param1:1});
}

APP.module3 = new module3({a: 42});
那么在引入的時候我們需要手動地按照模塊間依賴順序引入進來：





不過這種方式對于模塊間通信也是個麻煩。命名空間模式算是如今 JavaScript 領域最為著名的模式之一，而在 Bindows 之后 Dojo(2005)，YUI(2005) 這些優秀的界面框架也是承襲了這種思想。
依賴注入
Martin Fowler 于 2004 年提出了依賴注入（Dependency Injection）的概念，其主要用于 Java 中的組件內通信；以 Spring 為代表的一系列支持依賴注入與控制反轉的框架將這種設計模式發揚光大，并且成為了 Java 服務端開發的標準模式之一。依賴注入的核心思想在于某個模塊不需要手動地初始化某個依賴對象，而只需要聲明該依賴并由外部框架自動實例化該對象實現并且傳遞到模塊內。而五年之后的 2009 年 Misko Hevery 開始設計新的 JavaScript 框架，并且使用了依賴注入作為其組件間通信的核心機制。這個框架就是引領一時風騷，甚至于說是現代 Web 開發先驅之一的 Angular。Angular 允許我們定義模塊，并且在顯式地聲明其依賴模塊而由框架完成自動注入。其核心思想如下所示：
// file greeting.js
angular.module("greeter", [])
    .value("greeting", {
        helloInLang: {
            en: "Hello world!",
            es: "?Hola mundo!",
            ru: "Привет мир!"
        },

        sayHello: function(lang) {
            return this.helloInLang[lang];
        }
    });

// file app.js
angular.module("app", ["greeter"])
    .controller("GreetingController", ["$scope", "greeting", function($scope, greeting) {
        $scope.phrase = greeting.sayHello("en");
    }]);
之后在 Angular 2 與 Slot 之中依賴注入仍是核心機制之一，這也是 Angular 一系的更多的被視為大而全的框架而不是小而美的庫的原因之一。
CommonJS
在 Node.js 橫空出世之前，就已經有很多將運行于客戶端瀏覽器中的 JavaScript 遷移運行到服務端的框架；不過由于缺乏合適的規范，也沒有提供統一的與操作系統及運行環境交互的接口，這些框架并未流行開來。2009 年時 Mozilla 的雇員 Kevin Dangoor 發表了博客討論服務端 JavaScript 代碼面臨的困境，號召所有有志于規范服務端 JavaScript 接口的志同道合的開發者協同討論，群策群力，最終形成了 ServerJS 規范；一年之后 ServerJS 重命名為 CommonJS。后來 CommonJS 內的模塊規范成為了 Node.js 的標準實現規范，其基本語法為 var commonjs = require("./commonjs");，核心設計模式如下所示：
// file greeting.js
var helloInLang = {
    en: "Hello world!",
    es: "?Hola mundo!",
    ru: "Привет мир!"
};

var sayHello = function (lang) {
    return helloInLang[lang];
}

module.exports.sayHello = sayHello;

// file hello.js
var sayHello = require("./lib/greeting").sayHello;
var phrase = sayHello("en");
console.log(phrase);
該模塊實現方案主要包含 require 與 module 這兩個關鍵字，其允許某個模塊對外暴露部分接口并且由其他模塊導入使用。在 Node.js 中我們通過內建輔助函數來使用 CommonJS 的導入導出功能，而在其他 JavaScript 引擎中我們可以將其包裹為如下形式：
(function (exports, require, module, __filename, __dirname) {
    // ...
    // Your code injects here!
    // ...
});
CommonJS 規范本身只是定義了不同環境下支持模塊交互性的最小化原則，其具備極大的可擴展性。Node.js 中就對 require 函數添加了 main 屬性，該屬性在執行模塊所屬文件時指向 module 對象。Babel 在實現 ES2015 Modules 的轉義時也擴展了 require 關鍵字：
export default something;
Babel 將此類型的導出轉化為了 CommonJS 模塊，簡單而言形式如下：
export.default = something;
Webpack 打包工具也使用了很多擴展，譬如 require.ensure、require.cache、require.context 等等。CommonJS 算是目前最流行的模塊格式，我們不僅可以在 Node.js 中使用，還可以通過 Browserify 與 Webpack 這樣的打包工具將代碼打包到客戶端運行。另外我們需要注意的是，Node.js 中的模塊在加載之后是以單例化運行，并且遵循值傳遞原則：
// obj.js
module.exports = {
    num:1
}

// primitive.js
module.exports = 1;

// modifier.js
var number = require("./primitive");
var obj = require("./obj");

number = 2;
obj.num = 2;

console.log(number);
console.log(obj);

// main.js
console.log(require("./primitive"));
console.log(require("./obj"));

require("./modifier.js")

console.log(require("./primitive"));
console.log(require("./obj"));

// 執行結果
1
{ num: 1 }
2
{ num: 2 }
1
{ num: 2 }
AMD
就在 CommonJS 規范火熱討論的同時，很多開發者也關注于如何實現模塊的異步加載。Web 應用的性能優化一直是前端工程實踐中不可避免的問題，而模塊的異步加載以及預加載等機制能有效地優化 Web 應用的加載速度。Mozilla 的另一位雇員 James Burke 是討論組的活躍成員，他在 Dojo 1.7 版本中引入了異步模塊機制，并且在 2009 年開發了 require.js 框架。James 的核心思想在于不應該以同步方式加載模塊，而應該充分利用瀏覽器的并發加載能力；James 按照其設計理念開發出的模塊工具就是 AMD（Asynchronous Module Definition），其基本形式如下：
define(["amd-module", "../file"], function(amdModule, file) {
    require(["big-module/big/file"], function(big) {
        var stuff = require("../my/stuff");
    });
});
而將我們上述使用的例子改寫為 AMD 模式應當如下所示：
// file lib/greeting.js
define(function() {
    var helloInLang = {
        en: "Hello world!",
        es: "?Hola mundo!",
        ru: "Привет мир!"
    };

    return {
        sayHello: function (lang) {
            return helloInLang[lang];
        }
    };
});

// file hello.js
define(["./lib/greeting"], function(greeting) {
    var phrase = greeting.sayHello("en");
    document.write(phrase);
});
hello.js 作為整個應用的入口模塊，我們使用 define 關鍵字聲明了該模塊以及外部依賴；當我們執行該模塊代碼時，也就是執行 define 函數的第二個參數中定義的函數功能，其會在框架將所有的其他依賴模塊加載完畢后被執行。這種延遲代碼執行的技術也就保證了依賴的并發加載。從我個人而言，AMD 及其相關技術對于前端開發的工程化進步有著非常積極的意義，不過隨著以 npm 為主導的依賴管理機制的統一，越來越多的開發者放棄了使用 AMD 模式。
UMD
AMD 與 CommonJS 雖然師出同源，但還是分道揚鑣，關注于代碼異步加載與最小化入口模塊的開發者將目光投注于 AMD；而隨著 Node.js 以及 Browserify 的流行，越來越多的開發者也接受了 CommonJS 規范。令人扼腕嘆息的是，符合 AMD 規范的模塊并不能直接運行于實踐了 CommonJS 模塊規范的環境中，符合 CommonJS 規范的模塊也不能由 AMD 進行異步加載，整個 JavaScript 生態圈貌似分崩離析。2011 年中，UMD，也就是 Universal Module Definition 規范正是為了彌合這種不一致性應運而出，其允許在環境中同時使用 AMD 與 CommonJS 規范。Q 算是 UMD 的首個規范實現，其能同時運行于瀏覽器環境（以腳本標簽形式嵌入）與服務端的 Node.js 或者 Narwhal（CommonJS 模塊）環境中；稍后，James 也為 Q 添加了對于 AMD 的支持。我們將上述例子中的 greeting.js 改寫為同時支持 CommonJS 與 AMD 規范的模塊：
(function(define) {
    define(function () {
        var helloInLang = {
            en: "Hello world!",
            es: "?Hola mundo!",
            ru: "Привет мир!"
        };

        return {
            sayHello: function (lang) {
                return helloInLang[lang];
            }
        };
    });
}(
    typeof module === "object" && module.exports && typeof define !== "function" ?
    function (factory) { module.exports = factory(); } :
    define
));
該模式的核心思想在于所謂的 IIFE（Immediately Invoked Function Expression），該函數會根據環境來判斷需要的參數類別，譬如在 CommonJS 環境下上述代碼會以如下方式執行：
function (factory) {
    module.exports = factory();
} 
而如果是在 AMD 模塊規范下，函數的參數就變成了 define。正是因為這種運行時的靈活性是我們能夠將同一份代碼運行于不同的環境中。
ES2015 Modules
JavaScript 模塊規范領域群雄逐鹿，各領風騷，作為 ECMAScript 標準的起草者 TC39 委員會自然也不能置身事外。ES2015 Modules 規范始于 2010 年，主要由 Dave Herman 主導；隨后的五年中 David 還參與了 asm.js，emscription，servo，等多個重大的開源項目，也使得 ES2015 Modules 的設計能夠從多方面進行考慮與權衡。而最后的模塊化規范定義于 2015 年正式發布，也就是被命名為 ES2015 Modules。我們上述的例子改寫為 ES2015 Modules 規范如下所示：
// file lib/greeting.js
const helloInLang = {
    en: "Hello world!",
    es: "?Hola mundo!",
    ru: "Привет мир!"
};

export const greeting = {
    sayHello: function (lang) {
        return helloInLang[lang];
    }
};

// file hello.js
import { greeting } from "./lib/greeting";
const phrase = greeting.sayHello("en");
document.write(phrase);
ES2015 Modules 中主要的關鍵字就是 import 與 export，前者負責導入模塊而后者負責導出模塊。完整的導出語法如下所示：
// default exports
export default 42;
export default {};
export default [];
export default foo;
export default function () {}
export default class {}
export default function foo () {}
export default class foo {}

// variables exports
export var foo = 1;
export var foo = function () {};
export var bar; // lazy initialization
export let foo = 2;
export let bar; // lazy initialization
export const foo = 3;
export function foo () {}
export class foo {}

// named exports
export {foo};
export {foo, bar};
export {foo as bar};
export {foo as default};
export {foo as default, bar};

// exports from
export * from "foo";
export {foo} from "foo";
export {foo, bar} from "foo";
export {foo as bar} from "foo";
export {foo as default} from "foo";
export {foo as default, bar} from "foo";
export {default} from "foo";
export {default as foo} from "foo";
相對應的完整的支持的導入方式如下所示：
// default imports
import foo from "foo";
import {default as foo} from "foo";

// named imports
import {bar} from "foo";
import {bar, baz} from "foo";
import {bar as baz} from "foo";
import {bar as baz, xyz} from "foo";

// glob imports
import * as foo from "foo";

// mixing imports
import foo, {baz as xyz} from "foo";
import * as bar, {baz as xyz} from "foo";
import foo, * as bar, {baz as xyz} from "foo";
ES2015 Modules 作為 JavaScript 官方標準，日漸成為了開發者的主流選擇。雖然我們目前還不能直接保證在所有環境（特別是舊版本瀏覽器）中使用該規范，但是通過 Babel 等轉化工具能幫我們自動處理向下兼容。此外 ES2015 Modules 還是有些許被詬病的地方，譬如導入語句只能作為模塊頂層的語句出現，不能出現在 function 里面或是 if 里面：
if(Math.random()>0.5){
  import "./module1.js"; // SyntaxError: Unexpected keyword "import"
}
const import2 = (import "./main2.js"); // SyntaxError
try{
  import "./module3.js"; // SyntaxError: Unexpected keyword "import"
}catch(err){
  console.error(err);
}
const moduleNumber = 4;

import module4 from `module${moduleNumber}`; // SyntaxError: Unexpected token
并且 import 語句會被提升到文件頂部執行，也就是說在模塊初始化的時候所有的 import 都必須已經導入完成：
import "./module1.js";

alert("code1");

import module2 from "./module2.js";

alert("code2");

import module3 from "./module3.js";

// 執行結果
module1
module2
module3
code1
code2
并且 import 的模塊名只能是字符串常量，導入的值也是不可變對象；比如說你不能 import { a } from "./a" 然后給 a 賦值個其他什么東西。這些設計雖然使得靈活性不如 CommonJS 的 require，但卻保證了 ES6 Modules 的依賴關系是確定（Deterministic）的，和運行時的狀態無關，從而也就保證了 ES6 Modules 是可以進行可靠的靜態分析的。對于主要在服務端運行的 Node 來說，所有的代碼都在本地，按需動態 require 即可，但對于要下發到客戶端的 Web 代碼而言，要做到高效的按需使用，不能等到代碼執行了才知道模塊的依賴，必須要從模塊的靜態分析入手。這是 ES6 Modules 在設計時的一個重要考量，也是為什么沒有直接采用 CommonJS。此外我們還需要關注下的是 ES2015 Modules 在瀏覽器內的原生支持情況，盡管我們可以通過 Webpack 等打包工具將應用打包為單個包文件。目前主流瀏覽器中默認支持 ES2015 Modules 只有 Safari，而 Firefox 在 54 版本之后允許用戶手動啟用該特性。以 Firefox 為例，如果我們在瀏覽器中使用 ES2015 Modules，我們需要聲明入口模塊：

這里的 module 關鍵字就告訴瀏覽器該腳本中包含了對于其他腳本的導入語句，需要進行預先處理；不過問題來了，那么 JavaScript 解釋器又該如何判斷某個文件是否為模塊。社區也經過很多輪的討論，我們可以來看下簡單的例子：



  
    
  
  
  

main.js 的代碼實現如下：
// main.js
import utils from "./utils.js";

utils.alert(`
  JavaScript modules work in this browser:
  https://blog.whatwg.org/js-modules
`);
待導入的模塊如下：
// utils.js
export default {
    alert: (msg)=>{
        alert(msg);
    }
};
我們可以發現，在 import 語句中我們提供了 .js 擴展名，這也是區別于打包工具的重要特性之一，往往打包工具中并不需要我們提供擴展名。此外，在瀏覽器中進行模塊的動態加載，也要求待加載文件具有正確的 MIME 類型。我們常用的正確的模塊地址譬如：
https://example.com/apples.js
http:example.compears.mjs (becomes http://example.com/pears.mjs as step 1 parses with no base URL)
//example.com/bananas
./strawberries.js.cgi
../lychees
/limes.jsx
data:text/javascript,export default ‘grapes’;
blob:https://whatwg.org/d0360e2f-caee-469f-9a2f-87d5b0456f6f
不過筆者覺得有個不錯的特性在于瀏覽器中支持 CORS 協議，跨域加載其他域中的腳本。在瀏覽器中加載進來的模塊與直接加載的腳本的作用域也是不一致的，并且不需要 use strict 聲明其也默認處于嚴格模式下：
var x = 1;

alert(x === window.x);//false
alert(this === undefined);// true
瀏覽器對于模塊的加載默認是異步延遲進行的，即模塊腳本的加載并不會阻塞瀏覽器的解析行為，而是并發加載并在頁面加載完畢后進行解析，也就是所有的模塊腳本具有 defer 屬性。我們也可以為腳本添加 async 屬性，即指明該腳本會在加載完畢后立刻執行。這一點與傳統的非模塊腳本相比很大不同，傳統的腳本會阻塞瀏覽器解析直到抓取完畢，在抓取之后也會立刻進行執行操作。整個加載流程如下所示：