深入了解CommonJS, AMD, CMD, UMD, ES6 Module的前世今生

概要

JS模块化不是一蹴而就的，而是经历了长长的历史变迁。了解JS模块化思想的诞生与变迁历程是深入理解现代前端项目工程化的基础，只有在了解历史的基础上，我们才能更好地展望未来。相信你和我一样，已经迫不及待要了解这段神秘的发展史了，让我们一起开始这段神奇的旅程。

模块化出现之前

在ajax还未提出之前，JS主要用来进行一些简单的表单校验、只能实现非常简单的一些动画效果等等。因此，这是并没有前端工程师这个概念，因此并没有很复杂的业务逻辑需要处理，后端工程师基层就可以搞定这些简单的需求。那个年代的前端代码大概如下所示：

if (xx条件) {
  // do something
} else {
  // do another
}

for (var i = 0; i < arr.length; i++) {
  // do something
}

element.onclick = function () {}

简简单单的代码逻辑。只需要按照顺序，从上至下依次执行即可。

模块化思想萌芽阶段

2006年，ajax的概念被提出，前端拥有了主动向服务端发送请求并操作返回数据的能力，由于Google公司将此概念发扬光大，传统的网页功能已不能满足日常的需求，前端的业务逻辑越来越多，业务场景越来越复杂，因此代码量爆炸式增长，由此一系列问题逐渐暴露出来，亟待解决。
主要面临如下问题：

1、全局变量灾难
2、函数命名冲突
3、复杂依赖关系（如，jquery插件依赖jquery，就必须在引入插件之前引入jquery。当项目越来越大时，要理清这些插件的依赖关系简直脑壳疼）

假如现在项目依赖三个模块， module_a.js, modulle_b.js, index.js
index.html代码如下：

<html>
  <head></head>
  <body>
    <script src="./module_a.js"></script>
    <script src="./module_b.js"></script>
    <script src="./index.js"></script>
  </body>
</html>

module_a.js代码如下：

var a = [1, 2, 3]

module_b.js代码如下:

var b = [4, 5, 6]

index.js 代码如下：

var c = a.concat(b)

如下我们现在要在index.js中定义一个a变量，那么就会造成a变量全局污染（因为这些模块中的变量或者方法都是暴露于全局的）
那么萌芽阶段是如何解决这个问题的呢

用自执行函数来包装代码

moduleA = function(){
   var a,b; //变量a、b外部不可见
   return {
      add : function(){
         return a + b;
      }
   }
}()

优点：function内部的变量对全局隐藏了，达到了封装的目的。

缺陷：moduleA这个变量还是暴露到全局了，随着模块的增多，全局变量还是会越来越多。

使用java风格的命名空间
为了避免全局变量造成的冲突，人们想到或许可以用多级命名空间来进行管理，于是，代码就变成了这个风格：

app.utils.moduleA= xxx;
app.tools.moduleA= xxx;
app.tools.moduleA.format = xxx;

Yahoo的YUI早期就是这么做的。但是这样调用函数的使用感觉不是很爽，不够轻快。

jQuery风格的匿名自执行函数

(function(window){
  //代码
  window.jQuery = window.$ = jQuery;//通过给window添加属性而暴露到全局
})(window);

jQuery的封装风格曾经被很多框架模仿，通过匿名函数包装代码，所依赖的外部变量传给这个函数，在函数内部可以使用这些依赖，然后在函数的最后把模块自身暴露给window。
如果需要添加扩展，则可以作为jQuery的插件，把它挂载到$上。
这种风格虽然灵活了些，但并未解决根本问题，所需依赖还是得外部提前提供、还是增加了全局变量。

模块化要解决的问题

以上是模块化萌芽阶段的一些尝试，可以看出要解决的主要问题如下：

1、如何安全的包装一个模块的代码？（不污染模块外的任何代码）
2、如何唯一标识一个模块？
3、如何优雅的把模块的API暴露出去？（不能增加全局变量）
4、如何方便的使用所依赖的模块？

CommonJs（源自NodeJS规范）

如果说浏览器端的js即便没有模块化也可以勉强忍受的话，那服务端是万万不能的。高手云集且富有创造力的CommonJs社区在长期的酝酿中发力，制定了Modules/1.0规范，首次定义了一个模块应该长啥样。2009年，NodeJS横空出世，开创了JS发展史的一个崭新纪元，人们可以用js来编写服务端的代码了。

具体来说，Modules/1.0规范包含以下内容：

1、模块的标识应遵循的规则（书写规范）
2、定义全局函数require，通过传入模块标识来引入其他模块，执行的结果即为别的模块暴露出来的API
3、如果被require函数引入的模块中也包含依赖，那么依次加载这些依赖
4、如果引入模块失败，那么require函数应该报一个异常
5、模块通过变量exports来向往暴露API，exports只能是一个对象，暴露的API须作为此对象的属性。

此规范一出，立刻产生了良好的效果，由于其简单而直接，在NodeJS中，这种模块化方案被迅速广泛推广。

下面是CommonJS规范的应用dmeo:

//math.js
exports.add = function() {
  var sum = 0, i = 0, args = arguments, l = args.length;
  while (i < l) {
    sum += args[i++];
  }
  return sum;
};

// increment.js
var add = require('math').add;
exports.increment = function(val) {
  return add(val, 1);
};

// program.js
var inc = require('increment').increment;
var a = 1;
inc(a); // 2

Modules/1.0规范由服务端向前端进军

``Modules/1.0`规范源于服务端，无法直接用于浏览器端，原因表现为:

外层没有function包裹，变量全暴露在全局。如上面例子中increment.js中的add。
资源的加载方式与服务端完全不同。服务端require一个模块，直接就从硬盘或者内存中读取了，消耗的时间可以忽略。而浏览器则不同，需要从服务端来下载这个文件，然后运行里面的代码才能得到API，需要花费一个http请求，也就是说，require后面的一行代码，需要资源请求完成才能执行。由于浏览器端是以插入<script>标签的形式来加载资源的（ajax方式不行，有跨域问题），没办法让代码同步执行，所以像commonjs那样的写法会直接报错。

所以，社区意识到，要想在浏览器环境中也能模块化，需要对规范进行升级。顺便说一句，CommonJs原来是叫ServerJs，从名字可以看出是专攻服务端的，为了统一前后端而改名CommonJs。
而就在社区讨论制定下一版规范的时候，内部发生了比较大的分歧，出现了三个主要的流派:
Modules/1.x派

这个流派认为，在现有基础上进行改进即可满足浏览器端的需要，既然浏览器端需要function包装，需要异步加载，那么新增一个方案，能把现有模块转化为适合浏览器端的就行了。基于这个主张，制定了Modules/Transport规范，提出了先通过工具把现有模块转化为适合浏览器环境使用的模块，然后再使用的方案。

browserify就是这样一个工具，可以把nodejs的模块编译成浏览器可用的模块。

目前的最新版是Modules/1.1.1，增加了一些require的属性，以及模块内增加module变量来描述模块信息，变动不大。

Modules/Async派

这个流派有点像“革新派”，他们认为浏览器与服务器环境差别太大，不能沿用旧的模块标准。既然浏览器必须异步加载代码，那么模块在定义的时候就必须指明所依赖的模块，然后把本模块的代码写在回调函数里。模块的加载也是通过下载-回调这样的过程来进行，这个思想就是AMD的基础，由于“革新派”与“保皇派”的思想无法达成一致，最终从CommonJs中分裂了出去，独立制定了浏览器端的js模块化规范AMD（Asynchronous Module Definition）

Modules/2.0派

这个流派有点像“中间派”，既不想丢掉旧的规范，也不想像AMD那样推到重来。他们认为，Modules/1.0固然不适合浏览器，但它里面的一些理念还是很好的，（如通过require来声明依赖），新的规范应该兼容这些，AMD规范也有它好的地方（例如模块的预先加载以及通过return可以暴露任意类型的数据，而不是像commonjs那样exports只能为object），也应采纳。最终他们制定了一个Modules/Wrappings规范，此规范指出了一个模块应该如何“包装”，包含以下内容：

全局有一个module变量，用来定义模块
通过module.declare方法来定义一个模块
module.declare方法只接收一个参数，那就是模块的factory，参数factory可以是函数也可以是对象，如果是对象，那么模块输出就是此对象。
块的factory函数传入三个参数：require,exports,module，用来引入其他依赖和导出本模块API
如果factory函数最后明确写有return数据（js函数中不写return默认返回undefined），那么return的内容即为模块的输出。

如下所示是该规范的使用demo：

// 可以使用exprots来对外暴露API
module.declare(function(require, exports, module)
{
  exports.foo = "bar";
});


// 也可以直接return来对外暴露数据
module.declare(function(require)
{
  return { foo: "bar" };
});

AMD/RequireJs的崛起与妥协

AMD的思想正如其名，异步加载所需的模块，然后在回调函数中执行主逻辑。这正是我们在浏览器端开发所习惯的方式，其作者亲自实现了符合AMD规范的requirejs，AMD/RequireJs迅速被广大开发者所接受。

AMD规范包含以下内容：

用全局函数define来定义模块，用法为：define(id?, dependencies?, factory);
id为模块标识，遵从CommonJS Module Identifiers规范
dependencies为依赖的模块数组，在factory中需传入形参与之一一对应
如果dependencies的值中有”require”、”exports”或”module”，则与commonjs中的实现保持一致
如果dependencies省略不写，则默认为["require", "exports", "module"]，factory中也会默认传入require,exports,module
如果factory为函数，模块对外暴露API的方法有三种：return任意类型的数据、exports.xxx=xxx、module.exports=xxx
如果factory为对象，则该对象即为模块的返回值

基于以上几点基本规范，我们便可以用这样的方式来进行模块化组织代码了：

// a.js
define(function(){
   console.log('a.js执行');
   return {
      hello: function(){
         console.log('hello, a.js');
      }
   }
});

// b.js
define(function(){
   console.log('b.js执行');
   return {
      hello: function(){
         console.log('hello, b.js');
      }
   }
});

// main.js
require(['a', 'b'], function(a, b){
   console.log('main.js执行');
   a.hello();
   $('#b').click(function(){
      b.hello();
   });
})

上面的main.js被执行的时候，会有如下的输出：

a.js执行
b.js执行
main.js执行
hello, a.js

在点击按钮后，会输出：

hello, b.js

从执行结果看，大体上没什么问题，因为两个hello方法都正确执行了。

但是如果仔细观察会发现，b.js被预先加载并且预先执行了，（第二行输出），b.hello这个方法是在点击了按钮之后才会执行，如果用户压根就没点，那么b.js中的代码应不应该执行呢？

这其实也是AMD/RequireJs被吐槽的一点，预先下载没什么争议，由于浏览器的环境特点，被依赖的模块肯定要预先下载的。问题在于，是否需要预先执行？如果一个模块依赖了十个其他模块，那么在本模块的代码执行之前，要先把其他十个模块的代码都执行一遍，不管这些模块是不是马上会被用到。这个性能消耗是不容忽视的。

另一点被吐槽的是，在定义模块的时候，要把所有依赖模块都罗列一遍，而且还要在factory中作为形参传进去，要写两遍很大一串模块名称，像这样：

define(['a', 'b', 'c', 'd', 'e', 'f', 'g'], function(a, b, c, d, e, f, g){  ..... })

编码过程略有不爽。
好的一点是，AMD保留了commonjs中的require、exprots、module这三个功能（上面提到的第4条）。你也可以不把依赖罗列在dependencies数组中。而是在代码中用require来引入，如下：

define(function(){
   console.log('main2.js执行');
   require(['a'], function(a){
      a.hello();    
   });
   $('#b').click(function(){
      require(['b'], function(b){
           b.hello();
      });
   });
});

我们在define的参数中未写明依赖，那么main2.js在执行的时候，就不会预先加载a.js和b.js，只是执行到require语句的时候才会去加载，上述代码的输出如下：

main2.js执行
a.js执行
hello, a.js

可以看到b.js并未执行，从网络请求中看，b.js也并未被下载。只有在按钮被点击的时候b.js才会被下载执行，并且在回调函数中执行模块中的方法。这就是名副其实的“懒加载”了。
这样的懒加载无疑会大大减轻初始化时的损耗（下载和执行都被省去了），但是弊端也是显而易见的，在后续执行a.hello和b.hello时，必须得实时下载代码然后在回调中才能执行，这样的用户体验是不好的，用户的操作会有明显的延迟卡顿。
但这样的现实并非是无法接受的，毕竟是浏览器环境，我们已经习惯了操作网页时伴随的各种loading。。。

但是话说过来，有没有更好的方法来处理问题呢？

资源的下载阶段还是预先进行，资源执行阶段后置，等到需要的时候再执行。这样一种折衷的方式，能够融合前面两种方式的优点，而又回避了缺点。

这就是Modules/Wrappings规范，还记得前面提到的“中间派”吗？

在AMD的阵营中，也有一部分人提出这样的观点，代码里写一堆回调实在是太恶心了，他们更喜欢这样来使用模块：

var a = require('a');
a.hello();
$('#b').click(function(){
    var b = require('b');
    b.hello();
});

于是，AMD也终于决定做出妥协，兼容Modules/Wrappings的写法，但只是部分兼容，例如并没有使用module.declare来定义模块，而还是用define，模块的执行时机也没有改变，依旧是预先执行。因此，AMD将此兼容称为Simplified CommonJS wrapping，即并不是完整的实现Modules/Wrappings。

作了此兼容后，使用requirejs就可以这么写代码了：

// d.js
define(function(require, exports, module){
   console.log('d.js执行');
   return {
      helloA: function(){
         var a = require('a');
         a.hello();
      },
      run: function(){
         $('#b').click(function(){
              var b = require('b');
              b.hello();
         });
      }
   }
});

注意定义模块时候的轻微差异，dependencies数组为空，但是factory函数的形参必须手工写上require,exports,module，（这不同于之前的dependencies和factory形参全不写），这样写即可使用Simplified CommonJS wrapping风格，与commonjs的格式一致了。

虽然使用上看起来简单，然而在理解上却给后人埋下了一个大坑。因为AMD只是支持了这样的语法，而并没有真正实现模块的延后执行。什么意思呢？上面的代码，正常来讲应该是预先下载a.js和b.js，然后在执行模块的helloA方法的时候开始执行a.js里面的代码，在点击按钮的时候开始执行b.js中的方法。实际却不是这样，只要此模块被别的模块引入，a.js和b.js中的代码还是被预先执行了。

我们把上面的代码命名为d.js，在别的地方使用它：

require(['d'], function(d){

});

上面的代码会输出

a.js执行
b.js执行
d.js执行

可以看出，尽管还未调用d模块的API，里面所依赖的a.js和b.js中的代码已经执行了。AMD的这种只实现语法却未真正实现功能的做法容易给人造成理解上的困难，被强烈吐槽。

在requirejs2.0中，作者声明已经处理了此问题（https://github.com/jrburke/requirejs/wiki/Upgrading-to-RequireJS-2.0#delayed）

兼容并包的CMD/seajs

既然require.js存在上述各种不是很优雅的地方，所以必然会有新东西来完善它，这就是后起之秀sea.js。

seajs的作者是国内大牛淘宝前端步道者玉伯。seajs全面拥抱Modules/Wrappings规范，不用requirejs那样回调的方式来编写模块。而它也不是完全按照Modules/Wrappings规范，seajs并没有使用declare来定义模块，而是使用和requirejs一样的define，或许作者本人更喜欢这个名字吧。（然而这或多或少又会给人们造成理解上的混淆），用seajs定义模块的写法如下：

// a.js
define(function(require, exports, module){
   console.log('a.js执行');
   return {
      hello: function(){
         console.log('hello, a.js');
      }
   }
});

// b.js
define(function(require, exports, module){
   console.log('b.js执行');
   return {
      hello: function(){
           console.log('hello, b.js');
      }
   }
});

// main.js
define(function(require, exports, module){
   console.log('main.js执行');
   var a = require('a');
   a.hello();    
   $('#b').click(function(){
      var b = require('b');
      b.hello();
   });
});

定义模块时无需罗列依赖数组，在factory函数中需传入形参require,exports,module，然后它会调用factory函数的toString方法，对函数的内容进行正则匹配，通过匹配到的require语句来分析依赖，这样就真正实现了commonjs风格的代码。

上面的main.js执行会输出如下：

main.js执行
a.js执行
hello, a.js

a.js和b.js都会预先下载，但是b.js中的代码却没有执行，因为还没有点击按钮。当点击按钮的时候，会输出如下：

b.js执行
hello, b.js

可以看到b.js中的代码此时才执行。这样就真正实现了“就近书写，延迟执行“，不可谓不优雅。

如果你一定要挑出一点不爽的话，那就是b.js的预先下载了。你可能不太想一开始就下载好所有的资源，希望像requirejs那样，等点击按钮的时候再开始下载b.js。本着兼容并包的思想，seajs也实现了这一功能，提供require.async API，在点击按钮的时候，只需这样写：

var b = require.async('b');
b.hello();

b.js就不会在一开始的时候就加载了。这个API可以说是简单漂亮。

关于模块对外暴露API的方式，seajs也是融合了各家之长，支持commonjs的exports.xxx = xxx和module.exports = xxx的写法，也支持AMD的return写法，暴露的API可以是任意类型。

你可能会觉得seajs无非就是一个抄，把别人家的优点都抄过来组合了一下。其实不然，seajs是commonjs规范在浏览器端的践行者，对于requirejs的优点也加以吸收。看人家的名字，就是海纳百川之意。（再论起名的重要性~），既然它的思想是海纳百川，讨论是不是抄就没意义了。

鉴于seajs融合了太多的东西，已经无法说它遵循哪个规范了，所以玉伯干脆就自立门户，起名曰CMD（Common Module Definition）规范，有了纲领，就不会再存在非议了。

UMD

UMD是AMD和CommonJS的糅合
AMD是以浏览器第一的原则发展的，异步加载模块。
而CommonJS以服务器第一原则进行发展，为同步加载，它的模块无需包装(unwrapped modules)。

这迫使人们又想出另一个更通用的模式UMD （Universal Module Definition）。希望解决跨平台的问题。
UMD先判断是否支持Node.js的模块（exports）是否存在，存在则使用Node.js模块模式。
再判断是否支持AMD（define是否存在），存在则使用AMD方式加载模块。
无导入导出规范，只有如下的一个常规写法：

(function (root, factory) {
    if (typeof define === 'function' && define.amd) {
        //AMD
        define(['jquery'], factory);
    } else if (typeof exports === 'object') {
        //Node, CommonJS之类的
        module.exports = factory(require('jquery'));
    } else {
        //浏览器全局变量(root 即 window)
        root.returnExports = factory(root.jQuery);
    }
}(this, function ($) {
    //方法
    function myFunc(){};
    //暴露公共方法
    return myFunc;
}));

ES6 module

ES6 module 是一个独立的文件，该文件内部的变量，外部无法获取，里面并不包含module关键字，像普通的js文件一样，但有两点不同：ES6 Module 是自动严格模式，即使没有显式声明use strict;
可以对Module进行导入import和导出export

export 导入
默认情况下，模块内声明的所有内容都是模块的内部变量。如果你希望模块中声明的内容是公共的，以便其他模块使用，则必须export输出该变量。

export 使用
使用 export 关键字导出功能，可以 export 任何顶层的function, class, var, let, const
由于代码是模块而不是脚本，因此所有声明都将作用于该模块，而不是在所有脚本和模块中全局可见

// kittydar.js - Find the locations of all the cats in an image.
export function detectCats(canvas, options) {
  var kittydar = new Kittydar(options);
  return kittydar.detectCats(canvas);
}

export class Kittydar {
  //... several methods doing image processing ...
}

// This helper function isn't exported.
function resizeCanvas() {
  ...
}

//... other function

我们可以在其他的js文件中，导入使用 detectCats 函数：

// demo.js - Kittydar demo program

import {detectCats} from "kittydar.js";

function go() {
    var canvas = document.getElementById("catpix");
    var cats = detectCats(canvas);
    drawRectangles(canvas, cats);
}

也可以从模块中导入多个：

import {detectCats, Kittydar} from "kittydar.js";

import 会有几个过程：

首先加载导入的模块
然后遍历执行模块每个主体
如果有已执行的主体，将会跳过

export import 用法
导出列表
用大括号包含要导出的所有名称，export 在顶级作用域中任何位置都可以，不一定在文件开头。

export {detectCats, Kittydar}

// 在具体的主体就不需要export关键字了
function detectCats (canvas, options) { ... }
class Kittydar { ... }

重命名导入
在实际项目中，随着应用的扩大，导入的名称碰巧与其他名称有冲突，ES6允许你导入时重命名

// 这些模块都声明导出了 `flip`，需要重命名
import {flip as flipOmelet} from "eggs.js";
import {flip as flipHouse} from "real-estate.js";
也可以在export时重命名，如果两个不同名称下导出相同的值，这也很多有用
function v1() { ... }
function v2() { ... }

export {
  v1 as streamV1,
  v2 as streamV2,
  v2 as StreamLatestVersion
};

默认导出
ES6 新标准旨在与现有的CommonJs和AMD模块兼容，假设你已经node依赖 npm install lodash , 可以导入各个函数：

import {each, map} from "lodash";
each([3, 2, 1], x => console.log(x));

如果你已经习惯了使用Lodash的_.each，你可以导入模块：

import _ from "lodash";

// 这等价于

import {default as _ } from "lodash";

所有符合CommonJS和AMD规范的，他们都具有 default 导出功能
如果一些js插件没有ES6支持，可以直接将其导入ES6代码：

import tooltip from "bootstrap/tooltip";

// 等同于
var tooltip = require("bootstrap/tooltip");

让ES6模块具有默认导出功能
可以使用重命名语法

let myObject = {
  field1: value1,
  field2: value2
};

export {myObject as default};
简写：

export default {
  field1: value1,
  field2: value2
}

导出模块命名空间
如果你想让模块导出的主体具有命名空间，则可以使用 * 语法

// cows.js
import * as cows from "cows";

/** 
 * app.js
 * if cows has moo()
 */
cows.moo()

JS引擎在运行一个模块时，有以下几个步骤：

解析：读取模块的源代码并检查语法错误
加载：递归加载所有导入的模块
作用域：创建模块作用域，并使用模块中声明的主体填充，包括从其他模块导入的主体
实行每个新加载模块主体中的语句

posted @ 2021-08-22 22:19 Elwin0204 阅读(144) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

Elwin

Always believe that something good is about to happen