[[188016]]

JavaScript 模塊化

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

<!--html--> 
<script type="application/javascript"> 
    // module1 code 
    // module2 code 
</script> 

不過隨著單頁應用與富客戶端的流行，不斷增長的代碼庫也急需合理的代碼分割與依賴管理的解決方案，這也就是我們在軟件工程領域所熟悉的模塊化(Modularity)。所謂模塊化主要是解決代碼分割、作用域隔離、模塊之間的依賴管理以及發(fā)布到生產(chǎn)環(huán)境時的自動化打包與處理等多個方面。二十年間流行過的 JavaScript 模塊化解決方案包括但不限于直接聲明依賴(Directly Defined Dependences)、命名空間(Namespace Pattern)、模塊模式(Module Pattern)、依賴分離定義(Detached Dependency Definitions)、沙盒(Sandbox)、依賴注入(Dependency Injection)、CommonJS、AMD、UMD、標簽化模塊(Labeled Modules)、YModules、ES 2015 Modules。

在早期的 Web 開發(fā)中，所有的嵌入到網(wǎng)頁內(nèi)的 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'); 
} 

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

// 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 

經(jīng)過 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<r.length;o++)s(r[o]);return s})({1:[function(require,module,exports){ 
module.exports = 0 
},{}],2:[function(require,module,exports){ 
module.exports = 1 
},{}],3:[function(require,module,exports){ 
module.exports = 10 
},{}],4:[function(require,module,exports){ 
module.exports = 100 
// etc. 

我們分別測試 100、1000 與 5000 模塊，可以發(fā)現(xiàn)隨著模塊數(shù)目的增長***的包體大小并非線性增長：

命名空間模式

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

// 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]); 
}; 

我們可以發(fā)現(xiàn)自定義代碼中的所有數(shù)據(jù)對象與函數(shù)都歸屬于全局對象 app，不過顯而易見這種方式對于大型多人協(xié)同項目的可維護性還是較差，并且沒有解決模塊間依賴管理的問題。另外有時候我們需要處理一些自動執(zhí)行的 Pollyfill 性質的代碼，就需要將模塊包裹在自調(diào)用的函數(shù)中，譬如在某個大型應用中，我們的代碼可能會切分為如下幾個模塊：

// 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}); 

那么在引入的時候我們需要手動地按照模塊間依賴順序引入進來：

<!--html--> 
<script type="application/javascript" src="PATH/polyfill-vendor.js" ></script> 
<script type="application/javascript" src="PATH/module1.js" ></script> 
<script type="application/javascript" src="PATH/module2.js" ></script> 
<script type="application/javascript" src="PATH/app.js" ></script> 

不過這種方式對于模塊間通信也是個麻煩。命名空間模式算是如今 JavaScript 領域最為著名的模式之一，而在 Bindows 之后 Dojo(2005)，YUI(2005) 這些優(yōu)秀的界面框架也是承襲了這種思想。

依賴注入

Martin Fowler 于 2004 年提出了依賴注入(Dependency Injection)的概念，其主要用于 Java 中的組件內(nèi)通信;以 Spring 為代表的一系列支持依賴注入與控制反轉的框架將這種設計模式發(fā)揚光大，并且成為了 Java 服務端開發(fā)的標準模式之一。依賴注入的核心思想在于某個模塊不需要手動地初始化某個依賴對象，而只需要聲明該依賴并由外部框架自動實例化該對象實現(xiàn)并且傳遞到模塊內(nèi)。而五年之后的 2009 年 Misko Hevery 開始設計新的 JavaScript 框架，并且使用了依賴注入作為其組件間通信的核心機制。這個框架就是***一時風騷，甚至于說是現(xiàn)代 Web 開發(fā)先驅之一的 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 橫空出世之前，就已經(jīng)有很多將運行于客戶端瀏覽器中的 JavaScript 遷移運行到服務端的框架;不過由于缺乏合適的規(guī)范，也沒有提供統(tǒng)一的與操作系統(tǒng)及運行環(huán)境交互的接口，這些框架并未流行開來。2009 年時 Mozilla 的雇員 Kevin Dangoor 發(fā)表了博客討論服務端 JavaScript 代碼面臨的困境，號召所有有志于規(guī)范服務端 JavaScript 接口的志同道合的開發(fā)者協(xié)同討論，群策群力，最終形成了 ServerJS 規(guī)范;一年之后 ServerJS 重命名為 CommonJS。后來 CommonJS 內(nèi)的模塊規(guī)范成為了 Node.js 的標準實現(xiàn)規(guī)范，其基本語法為 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); 

該模塊實現(xiàn)方案主要包含 require 與 module 這兩個關鍵字，其允許某個模塊對外暴露部分接口并且由其他模塊導入使用。在 Node.js 中我們通過內(nèi)建輔助函數(shù)來使用 CommonJS 的導入導出功能，而在其他 JavaScript 引擎中我們可以將其包裹為如下形式：

(function (exports, require, module, __filename, __dirname) { 
    // ... 
    // Your code injects here! 
    // ... 
}); 

CommonJS 規(guī)范本身只是定義了不同環(huán)境下支持模塊交互性的最小化原則，其具備極大的可擴展性。Node.js 中就對 require 函數(shù)添加了 main 屬性，該屬性在執(zhí)行模塊所屬文件時指向 module 對象。Babel 在實現(xiàn) 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')); 
 
// 執(zhí)行結果 
1 
{ num: 1 } 
2 
{ num: 2 } 
1 
{ num: 2 } 

AMD

就在 CommonJS 規(guī)范火熱討論的同時，很多開發(fā)者也關注于如何實現(xiàn)模塊的異步加載。Web 應用的性能優(yōu)化一直是前端工程實踐中不可避免的問題，而模塊的異步加載以及預加載等機制能有效地優(yōu)化 Web 應用的加載速度。Mozilla 的另一位雇員 James Burke 是討論組的活躍成員，他在 Dojo 1.7 版本中引入了異步模塊機制，并且在 2009 年開發(fā)了 require.js 框架。James 的核心思想在于不應該以同步方式加載模塊，而應該充分利用瀏覽器的并發(fā)加載能力;James 按照其設計理念開發(fā)出的模塊工具就是 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 關鍵字聲明了該模塊以及外部依賴;當我們執(zhí)行該模塊代碼時，也就是執(zhí)行 define 函數(shù)的第二個參數(shù)中定義的函數(shù)功能，其會在框架將所有的其他依賴模塊加載完畢后被執(zhí)行。這種延遲代碼執(zhí)行的技術也就保證了依賴的并發(fā)加載。從我個人而言，AMD 及其相關技術對于前端開發(fā)的工程化進步有著非常積極的意義，不過隨著以 npm 為主導的依賴管理機制的統(tǒng)一，越來越多的開發(fā)者放棄了使用 AMD 模式。

UMD

AMD 與 CommonJS 雖然師出同源，但還是分道揚鑣，關注于代碼異步加載與最小化入口模塊的開發(fā)者將目光投注于 AMD;而隨著 Node.js 以及 Browserify 的流行，越來越多的開發(fā)者也接受了 CommonJS 規(guī)范。令人扼腕嘆息的是，符合 AMD 規(guī)范的模塊并不能直接運行于實踐了 CommonJS 模塊規(guī)范的環(huán)境中，符合 CommonJS 規(guī)范的模塊也不能由 AMD 進行異步加載，整個 JavaScript 生態(tài)圈貌似分崩離析。2011 年中，UMD，也就是 Universal Module Definition 規(guī)范正是為了彌合這種不一致性應運而出，其允許在環(huán)境中同時使用 AMD 與 CommonJS 規(guī)范。Q 算是 UMD 的***規(guī)范實現(xiàn)，其能同時運行于瀏覽器環(huán)境(以腳本標簽形式嵌入)與服務端的 Node.js 或者 Narwhal(CommonJS 模塊)環(huán)境中;稍后，James 也為 Q 添加了對于 AMD 的支持。我們將上述例子中的 greeting.js 改寫為同時支持 CommonJS 與 AMD 規(guī)范的模塊：

(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)，該函數(shù)會根據(jù)環(huán)境來判斷需要的參數(shù)類別，譬如在 CommonJS 環(huán)境下上述代碼會以如下方式執(zhí)行：

function (factory) { 
    module.exports = factory(); 
}  

而如果是在 AMD 模塊規(guī)范下，函數(shù)的參數(shù)就變成了 define。正是因為這種運行時的靈活性是我們能夠將同一份代碼運行于不同的環(huán)境中。

ES2015 Modules

JavaScript 模塊規(guī)范領域群雄逐鹿，各領風騷，作為 ECMAScript 標準的起草者 TC39 委員會自然也不能置身事外。ES2015 Modules 規(guī)范始于 2010 年，主要由 Dave Herman 主導;隨后的五年中 David 還參與了 asm.js，emscription，servo，等多個重大的開源項目，也使得 ES2015 Modules 的設計能夠從多方面進行考慮與權衡。而***的模塊化規(guī)范定義于 2015 年正式發(fā)布，也就是被命名為 ES2015 Modules。我們上述的例子改寫為 ES2015 Modules 規(guī)范如下所示：

// 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 官方標準，日漸成為了開發(fā)者的主流選擇。雖然我們目前還不能直接保證在所有環(huán)境(特別是舊版本瀏覽器)中使用該規(guī)范，但是通過 Babel 等轉化工具能幫我們自動處理向下兼容。此外 ES2015 Modules 還是有些許被詬病的地方，譬如導入語句只能作為模塊頂層的語句出現(xiàn)，不能出現(xiàn)在 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 語句會被提升到文件頂部執(zhí)行，也就是說在模塊初始化的時候所有的 import 都必須已經(jīng)導入完成：

import './module1.js'; 
 
alert('code1'); 
 
import module2 from './module2.js'; 
 
alert('code2'); 
 
import module3 from './module3.js'; 
 
// 執(zhí)行結果 
module1 
module2 
module3 
code1 
code2 

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

<script type="module" scr="PATH/file.js"></script> 

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

<!--index.html--> 
<!DOCTYPE html> 
<html> 
  <head> 
    <script type="module" src="main.js"></script> 
  </head> 
  <body> 
  </body> 
</html> 

main.js 的代碼實現(xiàn)如下：

// 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); 
    } 
}; 

我們可以發(fā)現(xiàn)，在 import 語句中我們提供了 .js 擴展名，這也是區(qū)別于打包工具的重要特性之一，往往打包工具中并不需要我們提供擴展名。此外，在瀏覽器中進行模塊的動態(tài)加載，也要求待加載文件具有正確的 MIME 類型。我們常用的正確的模塊地址譬如：

https://example.com/apples.js 
http:example.com\pears.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 協(xié)議，跨域加載其他域中的腳本。在瀏覽器中加載進來的模塊與直接加載的腳本的作用域也是不一致的，并且不需要 use strict 聲明其也默認處于嚴格模式下：

var x = 1; 
 
alert(x === window.x);//false 
alert(this === undefined);// true 

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

【本文是51CTO專欄作者“張梓雄 ”的原創(chuàng)文章，如需轉載請通過51CTO與作者聯(lián)系】

戳這里，看該作者更多好文