JS本身是一個(gè)多才多藝的語言，一個(gè)可以用自己編譯自己的自由度極高的語言。正因?yàn)檫@份自由，出現(xiàn)了天花亂墜的規(guī)范與框架們，其中最基礎(chǔ)的一塊便是Module。

來來來，baby們，做個(gè)小測(cè)試： CommonJS·AMD·CMD·UMD·ES6，這些模塊規(guī)范，大家熟悉幾個(gè)？

注意注意：本文乃筆者主觀寫出的歡快脫線認(rèn)知，也許和真正的模塊形成的歷史有所區(qū)別。

一切的根源

JS是一個(gè)自由度極高的語言，即使沒有模塊的概念。也可以通過IIFE，new一個(gè)對(duì)象來實(shí)現(xiàn)類似與模塊的概念。也可以實(shí)現(xiàn)可復(fù)用，作用域獨(dú)立，易維護(hù)。這樣散裝的，無法維護(hù)各個(gè)模塊之間依賴。在一個(gè)JS文件中，模塊一多，也許就是修羅場(chǎng)。

Module的誕生

于是JS Module，一個(gè)令人又愛又恨的名詞誕生了。JS本身設(shè)計(jì)上就沒有模塊的概念，之后為了讓JS變成一個(gè)功能強(qiáng)大的語言，業(yè)界大佬們各顯神通，定了一個(gè)名為CommonJS的規(guī)范，實(shí)現(xiàn)了一個(gè)名為模塊的東西。可惜大多瀏覽器并不支持，只能用于nodejs，于是CommonJS開始分裂，變異了一個(gè)名為AMD規(guī)范的模塊，可以用于瀏覽器端，而由于AMD與CommonJS規(guī)范相去甚遠(yuǎn)，于是AMD自立門戶，并且推出了requireJS這個(gè)框架，用于實(shí)現(xiàn)并推廣AMD規(guī)范。正因?yàn)锳MD與CommonJS如此不同，且用于不同的環(huán)境，為了能夠兼容兩個(gè)平臺(tái)，UMD應(yīng)運(yùn)而生，不過筆者認(rèn)為僅僅是一個(gè)polyfill，以兼容兩個(gè)平臺(tái)。此時(shí)，CommonJS的擁護(hù)者認(rèn)為，瀏覽端也可以實(shí)現(xiàn)CommonJS的規(guī)范，于是稍作改動(dòng)，形成了CMD規(guī)范，并且推出了seajs這個(gè)框架。正在AMD與CMD打得火熱的時(shí)候，ECMAScript6給JS本身定了一個(gè)模塊加載的功能，ES6表示“你們也別爭(zhēng)了，JS模塊有原生的語法了”。

真正的規(guī)范

對(duì)于眾多規(guī)范中，只有CommonJS和ES6 import/export是真正的規(guī)范，其余的是利用JS現(xiàn)有的支持的方法模擬出的環(huán)境，以實(shí)現(xiàn)各自的規(guī)范。

至于為什么說CommonJS和ES6 import/export是真正的規(guī)范呢？因?yàn)橹挥性С炙麄兊恼Z法，才能實(shí)現(xiàn)他們的規(guī)范。

對(duì)于CommonJS而言，運(yùn)行環(huán)境中，必須有require和module.exports的支持，才能運(yùn)行。這就是瀏覽器與CommonJS無緣的主要原因。

至于ES6，失去對(duì)import和export關(guān)鍵字的支持，便一切都是零。比如，nodejs就不支持import和export，明明nodejs支持其他的ES6語法，怎么就對(duì)import和export如此不友好，筆者認(rèn)為nodejs是為了實(shí)現(xiàn)commonJS的規(guī)范，因此不能接受ES6的模塊擾亂nodejs的模塊規(guī)范。

所以說CommonJS和ES6的模塊才是真正的規(guī)范。

關(guān)于CommonJS和ES6模塊，筆者曾經(jīng)寫過一篇關(guān)于他們的文章，這里不多做贅述,移步至讀懂CommonJS的模塊加載。

有關(guān)瀏覽器實(shí)現(xiàn)CommonJS模塊的原理

既然瀏覽器缺少CommonJS的兩個(gè)關(guān)鍵字導(dǎo)致，模塊不成立，那么就創(chuàng)建一個(gè)模塊環(huán)境。使用define這個(gè)方法，將函數(shù)內(nèi)部模擬成CommonJS的環(huán)境，提供require和module.export的方法。無論是seajs還是requirejs都是通過define模擬環(huán)境的辦法，實(shí)現(xiàn)module的。

自立門戶的AMD

筆者之前正在DIY臺(tái)式機(jī)，挑選顯卡的時(shí)候，在A卡和N卡之間猶豫了一下，之后果斷選A卡，因?yàn)锳卡便宜一點(diǎn)。這里的A卡指的是AMD，那么和此處JS的AMD有社么關(guān)系嗎？沒有任何關(guān)系！只是因?yàn)镴S模塊的AMD這個(gè)縮寫和人家美國(guó)的AMD公司的名字一致而已，這只是一個(gè)美麗的巧合。

AMD的全稱是Asynchronous Module Definition，中文名是異步模塊定義，不同于CommonJS的按需加載，也就是require了之后才加栽，AMD是將所有的潛在需要用到的包都加載運(yùn)行了，也就是傳說中的高配，至于是否用得到就不再AMD的考慮范圍之內(nèi)了。requirejs就是AMD的代表：

來自AMD的暴擊：

define("module1",function(require) {
 'use strict';
 console.log("cccc")
});
define("module2",function(require) {
 'use strict';
 console.log("aaaa")
 if(false){
  console.log(require("module1"))
 }
 console.log("bbbb")
});

require(["module2"])

此時(shí)打印cccc,aaaa,bbbb，由此可見AMD是將所有的模塊，在模塊執(zhí)行之前，就全部加載完畢了，所以AMD還有一種寫法是將所有的依賴模塊寫頭部。

define("module1",function(require) {
 'use strict';
 console.log("cccc")
});
define("module2",[module1],function(module1) {
 'use strict';
 console.log("aaaa")
 if(false){
  console.log(require("module1"))
 }
 console.log("bbbb")
});

瀏覽一下requirejs的源碼：

requirejs有兩種獲取依賴的方法，一種是配置，一種是利用正則匹配出所有的require的內(nèi)容，然后加入依賴。當(dāng)調(diào)用當(dāng)前模塊的時(shí)候，就先檢查依賴的模塊是否運(yùn)行了。

cjsRequireRegExp = /[^.]\s*require\s*\(\s*["']([^'"\s]+)["']\s*\)/g,

已經(jīng)定義完成的模塊，會(huì)被緩存在一個(gè)對(duì)象之中，以模塊的名字為唯一健值，之后若再次調(diào)用此緩存的模塊，則無需再次執(zhí)行。

執(zhí)行之后緩存結(jié)果

defined[id] = exports;

二次執(zhí)行，先檢查是否已存在，若存在怎不重復(fù)執(zhí)行。

function callGetModule(args) {
 //Skip modules already defined.
 if (!hasProp(defined, args[0])) {
  getModule(makeModuleMap(args[0], null, true)).init(args[1], args[2]);
 }
}

若是遠(yuǎn)程依賴，則創(chuàng)建一個(gè)script，加載遠(yuǎn)程資源，并將script加入頭部。

req.createNode = function (config, moduleName, url) {
 var node = config.xhtml ?
   document.createElementNS('http://www.w3.org/1999/xhtml', 'html:script') :
   document.createElement('script');
 node.type = config.scriptType || 'text/javascript';
 node.charset = 'utf-8';
 node.async = true;
 return node;
};

那么UMD是個(gè)什么樣的存在

第一次接觸到UMD，是在webpack的打包之中，想要生成一個(gè)library，有好多個(gè)選項(xiàng)，CommonJS，amd，umd。當(dāng)時(shí)一下子有點(diǎn)懵，UMD是什么？在不知情的情況下，又出現(xiàn)了一個(gè)模塊規(guī)范，這讓筆者的頭很大啊。

來自webpack的凝視：

output: {
 path: path.join(__dirname),
 filename: 'index.js',
 libraryTarget: "umd",//此處是希望打包的插件類型
 library: "Swiper",
}

看一眼打包后的效果：

!function(root,callback){
"object"==typeof exports&&"object"==typeof module?//判斷是不是nodejs環(huán)境
 module.exports=callback(require("react"),require("prop-types"))
 :
 "function"==typeof define&&define.amd?//判斷是不是requirejs的AMD環(huán)境
  define("Swiper",["react","prop-types"],callback)
  :"object"==typeof exports?//相當(dāng)于連接到module.exports.Swiper
   exports.Swiper=callback(require("react"),require("prop-types"))
   :
   root.Swiper=callback(root.React,root.PropTypes)//全局變量
}(window,callback)

這樣一個(gè)polyfill，瞬間就兼容了CommonJS，AMD和全局的一個(gè)模塊。這就是UMD，比起規(guī)范，不如說它是一個(gè)兼容，polyfill，支持多個(gè)模塊規(guī)范。

where is CMD？

眼尖的小伙伴應(yīng)該發(fā)現(xiàn)了，CMD不知去向，webpack的打包中也沒有CMD模塊的一個(gè)選項(xiàng)。CMD其實(shí)就是按照CommonJS規(guī)范，然后進(jìn)行改造，從而使之支持瀏覽器端的一種規(guī)范。

主要說說他和AMD的主要區(qū)別吧：

require關(guān)鍵字引入內(nèi)容的執(zhí)行順序。AMD是一個(gè)依賴提前加載的概念，而CMD是同步執(zhí)行，遇到require之后再執(zhí)行當(dāng)前的一個(gè)模塊。

define("c",function(require, exports, module) {
 console.log("bbb")
});
define("b",function(require, exports, module) {
 console.log("aaa")
 require("c")
 console.log("ccc")
});
seajs.use("b")

這樣打印的就是 aaa，bbb，ccc。按照代碼出現(xiàn)的順序執(zhí)行。

當(dāng)然這個(gè)是同步代碼的區(qū)別，至于異步代碼，CMD和AMD都是通過script，append到head加載，存入模塊對(duì)象之中，然后根據(jù)id調(diào)用。不過CMD有一點(diǎn)不同，加了一個(gè)小小的優(yōu)化：

if (!data.debug) {
 head.removeChild(node)
}

當(dāng)代碼加載完畢之后，并且緩存在模塊之中之后，便在head之中刪除了這個(gè)script。

后記

借用魯迅的一句話“世上本沒有路，走的人多了也就成了路”。JS MODUDLE的規(guī)范也是如此，用的人多了也就是默認(rèn)的解決方案了。

JS MODULE大戰(zhàn)就寫到這邊吧，大家都不曉得這些模塊的規(guī)范能夠存活多久，但是概念都很好。所以好好學(xué)習(xí)概念，以后就算有新的規(guī)范出來了，和老規(guī)范一對(duì)比，找出不同點(diǎn)，加以分析，便能夠輕松上手！

參考地址

不能忘記幫助筆者認(rèn)知模塊的文章們，謝謝大佬們：

requirejs：requirejs的官網(wǎng)對(duì)于AMD產(chǎn)生歷史的解釋。
前端模塊化開發(fā)那點(diǎn)歷史 ：seajs的大佬對(duì)模塊這一塊的看法，梳理了筆者對(duì)于AMD的困惑
overflow上對(duì)于AMD和requirejs的一個(gè)解釋

以上所述是小編給大家介紹的js module詳解整合，希望對(duì)大家有所幫助，如果大家有任何疑問請(qǐng)給我留言，小編會(huì)及時(shí)回復(fù)大家的。在此也非常感謝大家對(duì)腳本之家網(wǎng)站的支持！

最新評(píng)論