前言

JavaScript 语言诞生至今，模块规范化之路曲曲折折。社区先后呈现了各种解决方案，包含 AMD、CMD、CommonJS 等，而后 ECMA 组织在 JavaScript 语言规范层面，减少了模块性能（因为该性能是在 ES2015 版本引入的，所以在下文中将之称为 ES6 module）。
明天咱们就来聊聊，为什么会呈现这些不同的模块标准，它们在所处的历史节点解决了哪些问题？

何谓模块化？

或依据性能、或依据数据、或依据业务，将一个大程序拆分成相互依赖的小文件，再用简略的形式拼装起来。

全局变量

演示我的项目

为了更好的了解各个模块标准，先减少一个简略的我的项目用于演示。

# 我的项目目录:├─ js              # js文件夹│  ├─ main.js      # 入口│  ├─ config.js    # 我的项目配置│  └─ utils.js     # 工具└─  index.html     # 页面html

Window

在刀耕火种的前端原始社会，JS 文件之间的通信根本齐全依附window对象（借助 HTML、CSS 或后端等状况除外）。

// config.jsvar api = 'https://github.com/ronffy';var config = {  api: api,}
// utils.jsvar utils = {  request() {    console.log(window.config.api);  }}
// main.jswindow.utils.request();
<!-- index.html --><!DOCTYPE html><html lang="en"><head>  <meta charset="UTF-8">  <meta name="viewport" content="width=device-width, initial-scale=1.0">  <title>小贼学生：【深度全面】JS模块标准进化论</title></head><body>  <!-- 所有 script 标签必须保障程序正确，否则会依赖报错 -->  <script src="./js/config.js"></script>  <script src="./js/utils.js"></script>  <script src="./js/main.js"></script></body></html>

IIFE

浏览器环境下，在全局作用域申明的变量都是全局变量。全局变量存在命名抵触、占用内存无奈被回收、代码可读性低等诸多问题。

这时，IIFE（匿名立刻执行函数）呈现了：

;(function () {  ...}());

用IIFE重构 config.js：

;(function (root) {  var api = 'https://github.com/ronffy';  var config = {    api: api,  };  root.config = config;}(window));

IIFE的呈现，使全局变量的申明数量失去了无效的管制。

命名空间

依附window对象承载数据的形式是“不牢靠”的，如window.config.api，如果window.config不存在，则window.config.api就会报错，所以为了防止这样的谬误，代码里会大量的充斥var api = window.config && window.config.api;这样的代码。

这时，namespace退场了，简洁版本的namespace函数的实现（只为演示，不要用于生产）：

function namespace(tpl, value) {  return tpl.split('.').reduce((pre, curr, i) => {    return (pre[curr] = i === tpl.split('.').length - 1      ? (value || pre[curr])      : (pre[curr] || {}))  }, window);}

用namespace设置window.app.a.b的值：

namespace('app.a.b', 3); // window.app.a.b 值为 3

用namespace获取window.app.a.b的值：

var b = namespace('app.a.b');  // b 的值为 3 var d = namespace('app.a.c.d'); // d 的值为 undefined

app.a.c值为undefined，但因为应用了namespace, 所以app.a.c.d不会报错，变量d的值为undefined。

AMD/CMD

随着前端业务增重，代码越来越简单，靠全局变量通信的形式开始顾此失彼，前端急需一种更清晰、更简略的解决代码依赖的形式，将 JS 模块化的实现及标准陆续呈现，其中被利用较广的模块标准有 AMD 和 CMD。

面对一种模块化计划，咱们首先要理解的是：1. 如何导出接口；2. 如何导入接口。

AMD

异步模块定义标准（AMD）制订了定义模块的规定，这样模块和模块的依赖能够被异步加载。这和浏览器的异步加载模块的环境刚好适应（浏览器同步加载模块会导致性能、可用性、调试和跨域拜访等问题）。

本标准只定义了一个函数define，它是全局变量。

/** * @param {string} id 模块名称 * @param {string[]} dependencies 模块所依赖模块的数组 * @param {function} factory 模块初始化要执行的函数或对象 * @return {any} 模块导出的接口 */function define(id?, dependencies?, factory): any

RequireJS

AMD 是一种异步模块标准，RequireJS 是 AMD 标准的实现。

接下来，咱们用 RequireJS 重构下面的我的项目。

在原我的项目 js 文件夹下减少 require.js 文件：

# 我的项目目录:├─ js                # js文件夹│  ├─ ...│  └─ require.js     # RequireJS 的 JS 库└─  ...
// config.jsdefine(function() {  var api = 'https://github.com/ronffy';  var config = {    api: api,  };  return config;});
// utils.jsdefine(['./config'], function(config) {  var utils = {    request() {      console.log(config.api);    }  };  return utils;});
// main.jsrequire(['./utils'], function(utils) {  utils.request();});
<!-- index.html  --><!-- ...省略其余 --><body>  <script data-main="./js/main" src="./js/require.js"></script></body></html>

能够看到，应用 RequireJS 后，每个文件都能够作为一个模块来治理，通信形式也是以模块的模式，这样既能够清晰的治理模块依赖，又能够防止申明全局变量。

更多 AMD 介绍，请查看文档。
更多 RequireJS 介绍，请查看文档。

特地阐明：
先有 RequireJS，后有 AMD 标准，随着 RequireJS 的推广和遍及，AMD 标准才被创立进去。

CMD和AMD

CMD 和 AMD 一样，都是 JS 的模块化标准，也次要利用于浏览器端。
AMD 是 RequireJS 在的推广和遍及过程中被发明进去。
CMD 是 SeaJS 在的推广和遍及过程中被发明进去。

二者的的次要区别是 CMD 推崇依赖就近，AMD 推崇依赖前置：

// AMD// 依赖必须一开始就写好define(['./utils'], function(utils) {  utils.request();});// CMDdefine(function(require) {  // 依赖能够就近书写  var utils = require('./utils');  utils.request();});

AMD 也反对依赖就近，但 RequireJS 作者和官网文档都是优先举荐依赖前置写法。

思考到目前支流我的项目中对 AMD 和 CMD 的应用越来越少，大家对 AMD 和 CMD 有大抵的意识就好，此处不再过多赘述。

更多 CMD 标准，请查看文档。
更多 SeaJS 文档，请查看文档。

随着 ES6 模块标准的呈现，AMD/CMD 终将成为过来，但毋庸置疑的是，AMD/CMD 的呈现，是前端模块化过程中重要的一步。

小贼学生-文章旧址

CommonJS

后面说了， AMD、CMD 次要用于浏览器端，随着 node 诞生，服务器端的模块标准 CommonJS 被创立进去。

还是以下面介绍到的 config.js、utils.js、main.js 为例，看看 CommonJS 的写法:

// config.jsvar api = 'https://github.com/ronffy';var config = {  api: api,};module.exports = config;
// utils.jsvar config = require('./config');var utils = {  request() {    console.log(config.api);  }};module.exports = utils;
// main.jsvar utils = require('./utils');utils.request();console.log(global.api)

执行node main.js，https://github.com/ronffy被打印了进去。
在 main.js 中打印global.api，打印后果是undefined。node 用global治理全局变量，与浏览器的window相似。与浏览器不同的是，浏览器中顶层作用域是全局作用域，在顶层作用域中申明的变量都是全局变量，而 node 中顶层作用域不是全局作用域，所以在顶层作用域中申明的变量非全局变量。

module.exports和exports

咱们在看 node 代码时，应该会发现，对于接口导出，有的中央应用module.exports，而有的中央应用exports，这两个有什么区别呢?

CommonJS 标准仅定义了exports，但exports存在一些问题（上面会说到），所以module.exports被发明了进去，它被称为 CommonJS2 。
每一个文件都是一个模块，每个模块都有一个module对象，这个module对象的exports属性用来导出接口，内部模块导入以后模块时，应用的也是module对象，这些都是 node 基于 CommonJS2 标准做的解决。

// a.jsvar s = 'i am ronffy'module.exports = s;console.log(module);

执行node a.js，看看打印的module对象：

{  exports: 'i am ronffy',  id: '.',                                // 模块id  filename: '/Users/apple/Desktop/a.js',  // 文件门路名称  loaded: false,                          // 模块是否加载实现  parent: null,                           // 父级模块  children: [],                           // 子级模块  paths: [ /* ... */ ],                   // 执行 node a.js 后 node 搜寻模块的门路}

其余模块导入该模块时：

// b.jsvar a = require('./a.js'); // a --> i am ronffy

当在 a.js 里这样写时：

// a.jsvar s = 'i am ronffy'exports = s;

a.js 模块的module.exports是一个空对象。

// b.jsvar a = require('./a.js'); // a --> {}

把module.exports和exports放到“明面”上来写，可能就更分明了：

var module = {  exports: {}}var exports = module.exports;console.log(module.exports === exports); // truevar s = 'i am ronffy'exports = s; // module.exports 不受影响console.log(module.exports === exports); // false

模块初始化时，exports和module.exports指向同一块内存，exports被从新赋值后，就切断了跟原内存地址的关系。

所以，exports要这样应用：

// a.jsexports.s = 'i am ronffy';// b.jsvar a = require('./a.js');console.log(a.s); // i am ronffy

CommonJS 和 CommonJS2 常常被混同概念，个别大家常常提到的 CommonJS 其实是指 CommonJS2，本文也是如此，不过不管怎样，大家通晓它们的区别和如何利用就好。

CommonJS与AMD

CommonJS 和 AMD 都是运行时加载，换言之：都是在运行时确定模块之间的依赖关系。

二者有何不同点：

  1. CommonJS 是服务器端模块标准，AMD 是浏览器端模块标准。
  2. CommonJS 加载模块是同步的，即执行var a = require('./a.js');时，在 a.js 文件加载实现后，才执行前面的代码。AMD 加载模块是异步的，所有依赖加载实现后以回调函数的模式执行代码。
  3. [如下代码]fs和chalk都是模块，不同的是，fs是 node 内置模块，chalk是一个 npm 包。这两种状况在 CommonJS 中才有，AMD 不反对。
var fs = require('fs');var chalk = require('chalk');

UMD

Universal Module Definition.

存在这么多模块标准，如果产出一个模块给其他人用，心愿反对全局变量的模式，也合乎 AMD 标准，还能合乎 CommonJS 标准，能这么全能吗？
是的，能够如此全能，UMD 闪亮退场。

UMD 是一种通用模块定义标准，代码大略这样(如果咱们的模块名称是 myLibName):

!function (root, factory) {  if (typeof exports === 'object' && typeof module === 'object') {    // CommonJS2    module.exports = factory()    // define.amd 用来判断我的项目是否利用 require.js。    // 更多 define.amd 介绍，请[查看文档](https://github.com/amdjs/amdjs-api/wiki/AMD#defineamd-property-)  } else if (typeof define === 'function' && define.amd) {    // AMD    define([], factory)  } else if (typeof exports === 'object') {    // CommonJS    exports.myLibName = factory()  } else {    // 全局变量    root.myLibName = factory()  }}(window, function () {  // 模块初始化要执行的代码});

UMD 解决了 JS 模块跨模块标准、跨平台应用的问题，它是十分好的解决方案。

小贼学生-文章旧址

ES6 module

AMD 、 CMD 等都是在原有JS语法的根底上二次封装的一些办法来解决模块化的计划，ES6 module（在很多中央被简写为 ESM）是语言层面的标准，ES6 module 旨在为浏览器和服务器提供通用的模块解决方案。久远来看，将来无论是基于 JS 的 WEB 端，还是基于 node 的服务器端或桌面利用，模块标准都会对立应用 ES6 module。

兼容性

目前，无论是浏览器端还是 node ，都没有齐全原生反对 ES6 module，如果应用 ES6 module ，可借助 babel 等编译器。本文只探讨 ES6 module 语法，故不对 babel 或 typescript 等可编译 ES6 的形式展开讨论。

导出接口

CommonJS 中顶层作用域不是全局作用域，同样的，ES6 module 中，一个文件就是一个模块，文件的顶层作用域也不是全局作用域。导出接口应用export关键字，导入接口应用import关键字。

export导出接口有以下形式：

形式1

export const prefix = 'https://github.com';export const api = `${prefix}/ronffy`;

形式2

const prefix = 'https://github.com';const api = `${prefix}/ronffy`;export {  prefix,  api,}

形式1和形式2只是写法不同，后果是一样的，都是把prefix和api别离导出。

形式3（默认导出）

// foo.jsexport default function foo() {}// 等同于：function foo() {}export {  foo as default}

export default用来导出模块默认的接口，它等同于导出一个名为default的接口。配合export应用的as关键字用来在导出接口时为接口重命名。

形式4（先导入再导出简写）

export { api } from './config.js';// 等同于：import { api } from './config.js';export {  api}

如果须要在一个模块中先导入一个接口，再导出，能够应用export ... from 'module'这样的简便写法。

导入模块接口

ES6 module 应用import导入模块接口。

导出接口的模块代码1：

// config.jsconst prefix = 'https://github.com';const api = `${prefix}/ronffy`;export {  prefix,  api,}

接口曾经导出，如何导入呢：

形式1

import { api } from './config.js';// or// 配合`import`应用的`as`关键字用来为导入的接口重命名。import { api as myApi } from './config.js';

形式2（整体导入）

import * as config from './config.js';const api = config.api;

将 config.js 模块导出的所有接口都挂载在config对象上。

形式3（默认导出的导入）

// foo.jsexport const conut = 0;export default function myFoo() {}
// index.js// 默认导入的接口此处刻意命名为cusFoo，旨在阐明该命名可齐全自定义。import cusFoo, { count } from './foo.js';// 等同于：import { default as cusFoo, count } from './foo.js';

export default导出的接口，能够应用import name from 'module'导入。这种形式，使导入默认接口很便捷。

形式4（整体加载）

import './config.js';

这样会加载整个 config.js 模块，但未导入该模块的任何接口。

形式5（动静加载模块）

下面介绍了 ES6 module 各种导入接口的形式，但有一种场景未被涵盖：动静加载模块。比方用户点击某个按钮后才弹出弹窗，弹窗里性能波及的模块的代码量比拟重，所以这些相干模块如果在页面初始化时就加载，切实浪费资源，import()能够解决这个问题，从语言层面实现模块代码的按需加载。

ES6 module 在解决以上几种导入模块接口的形式时都是编译时解决，所以import和export命令只能用在模块的顶层，以下形式都会报错：

// 报错if (/* ... */) {  import { api } from './config.js'; }// 报错function foo() {  import { api } from './config.js'; }// 报错const modulePath = './utils' + '/api.js';import modulePath;

应用import()实现按需加载：

function foo() {  import('./config.js')    .then(({ api }) => {    });}const modulePath = './utils' + '/api.js';import(modulePath);

特地阐明：
该性能的提议目前处于 TC39 流程的第4阶段。更多阐明，请查看TC39/proposal-dynamic-import。

CommonJS 和 ES6 module

CommonJS 和 AMD 是运行时加载，在运行时确定模块的依赖关系。
ES6 module 是在编译时（import()是运行时加载）解决模块依赖关系，。

CommonJS

CommonJS 在导入模块时，会加载该模块，所谓“CommonJS 是运行时加载”，正因代码在运行实现后生成module.exports的缘故。当然，CommonJS 对模块做了缓存解决，某个模块即便被屡次多处导入，也只加载一次。

// o.jslet num = 0;function getNum() {  return num;}function setNum(n) {  num = n;}console.log('o init');module.exports = {  num,  getNum,  setNum,}
// a.jsconst o = require('./o.js');o.setNum(1);
// b.jsconst o = require('./o.js');// 留神：此处只是演示，我的项目里不要这样批改模块o.num = 2;
// main.jsconst o = require('./o.js');require('./a.js');console.log('a o.num:', o.num);require('./b.js');console.log('b o.num:', o.num);console.log('b o.getNum:', o.getNum());

命令行执行node main.js，打印后果如下：

  1. o init
    模块即便被其余多个模块导入，也只会加载一次，并且在代码运行实现后将接口赋值到module.exports属性上。
  2. a o.num: 0
    模块在加载实现后，模块外部的变量变动不会反馈到模块的module.exports。
  3. b o.num: 2
    对导入模块的间接批改会反馈到该模块的module.exports。
  4. b o.getNum: 1
    模块在加载实现后即造成一个闭包。

ES6 module

// o.jslet num = 0;function getNum() {  return num;}function setNum(n) {  num = n;}console.log('o init');export {  num,  getNum,  setNum,}
// main.jsimport { num, getNum, setNum } from './o.js';console.log('o.num:', num);setNum(1);console.log('o.num:', num);console.log('o.getNum:', getNum());

咱们减少一个 index.js 用于在 node 端反对 ES6 module：

// index.jsrequire("@babel/register")({  presets: ["@babel/preset-env"]});module.exports = require('./main.js')

命令行执行npm install @babel/core @babel/register @babel/preset-env -D装置 ES6 相干 npm 包。

命令行执行node index.js，打印后果如下：

  1. o init
    模块即便被其余多个模块导入，也只会加载一次。
  2. o.num: 0
  3. o.num: 1
    编译时确定模块依赖的 ES6 module，通过import导入的接口只是值的援用，所以num才会有两次不同打印后果。
  4. o.getNum: 1

对于打印后果3，通晓其后果，在我的项目中留神这一点就好。这块会波及到“Module Records（模块记录）”、“module instance（模快实例）” “linking（链接）”等诸多概念和原理，大家可查看ES modules: A cartoon deep-dive进行深刻的钻研，本文不再开展。

ES6 module 是编译时加载（或叫做“动态加载”），利用这一点，能够对代码做很多之前无奈实现的优化：

  1. 在开发阶段就能够做导入和导出模块相干的代码查看。
  2. 联合 Webpack、Babel 等工具能够在打包阶段移除上下文中未援用的代码（dead-code），这种技术被称作“tree shaking”，能够极大的减小代码体积、缩短程序运行工夫、晋升程序性能。

后记

大家在日常开发中都在应用 CommonJS 和 ES6 module，但很多人只知其然而不知其所以然，甚至很多人对 AMD、CMD、IIFE 等概览还比拟生疏，心愿通过本篇文章，大家对 JS 模块化之路可能有清晰残缺的意识。
JS 模块化之路目前趋于稳定，但必定不会止步于此，让咱们一起学习，一起提高，一起见证，也心愿能有机会为将来的模块化标准奉献本人的一点力量。
自己能力无限，文中可能不免有一些舛误，欢送大家帮忙改良，文章github地址，我是小贼学生。

参考

AMD 官网文档
阮一峰：Module 的加载实现