JavaScript模块化开发的前世今生

一个兜兜转转，从“北深”回到三线城市的小码农，热爱生活，热爱技术，在这里和大家分享一个技术人员的点点滴滴。欢迎大家关注我的微信公众号：果冻想

前言

现代化的编程语言，基本都支持模块化的开发，咱不说别的，就最原始的Shell，我们公司都整了一套模块化开发的框架，进行模块化开发。但是，日常在编写JavaScript代码，或者阅读别人的JavaScript代码时，总是看到require、import、export等等关键字，都说是JavaScript中的模块化的开发方式，这直接就把我整懵逼了，这怎么一个模块化的开发就搞出这么多的东西啊，这么多的关键词啊，入门即让人放弃？

无论是我这样的新手，还是一些老手，都对这个JavaScript中的模块化开发懵懵懂懂的，我就是这个样子的。那这里就通过一篇文章来把JavaScript模块化开发的前世今生给讲透了，让大家以后不再对这个知识点感到迷茫。

为啥需要模块化？

这就好比，动物园里一堆动物，是放在一个大院子里好管理呢，还是说每种动物用单间进行好管理。

比如，我们网页中引入JavaScript代码，经常是这样的。

<script src="./a.js"></script>  
<script src="./b.js"></script>  
<script src="./c.js"></script>

每个JS代码内容如下：

// a.js
var a = 1;setTimeout(() => console.log(a), 2000);// b.js
var a = 2;// c.js
var a = 3;

执行后，输出a = 3。虽然每个代码块处在不同的文件中，但是最终所有JS变量还是会处在同一个全局作用域下，这时候就需要额外注意由于作用域变量提升所带来的问题。

这就是说，虽然三段代码写在不同的文件中，但是因为运行时声明变量都在全局下，最终会产生冲突。同时，如果代码块之间有依赖关系的话，这将是一个非常棘手的问题，谁先加载，谁后加载，直接影响程序的运行。这么不智能的东西，在现代化的编程领域，是绝对不允许存在的。所以大佬们想的：

需要实现每个模块都要有自己单独的作用域，每个模块之间的内部变量不会产生冲突；
需要实现每个模块之间能通过某种规范或机制实现通信；
需要实现每个模块需要能导入其它模块的功能，也能导出自己的功能供其它模块调用。

好了，大佬们都有想法，纷争的时刻到了。

`CommonJS`规范

首先出厂的是CommonJS规范。其实我一开始是不知道这货的，只是在学习Node.js的时候，发现这货的。后来了解了下Node.js和CommonJS的关系。

即使你不会Node.js，你也会知道，Node.js这么大的一个生态体系，那肯定是众人拾柴火焰高的，肯定是不同的大神贡献了不同的包和模块的，那这些包和模块给我们，我们如何把他们组装在一起，而且还不出问题呢，这么头疼的问题，你想到了，我想到了，那Node.js的大佬肯定也想到了。

但是Node.Js刚出来的时候，没有官方的模块化规范，所以它就选择使用社区提供的CommonJS作为模块化规范。这下你就明白了这里面的缘由了。

作为一个模块化的规范，那肯定就要有导入和导出功能了。现在来看看CommonJS具体的规范内容：

使用exports导出模块，使用require导入模块；
如果JS文件中存在exports或者require关键字，那这个JS文件就是一个模块；
模块内的全部代码均为模块内部代码，包括全局变量、全局函数，这些全局的内容均不会对全局变量造成污染。

话不多说，上代码，使用CommonJS实现一个小模块，导出一些功能，并在index.js中导入这些功能。

// 这里定义一个模块
// 定义两个变量
var age = 0;
var name = "果冻想";// 定义一个函数
function getAge() {return age;
}// 向外暴漏
exports.getAge = getAge;
exports.name = name;

在main.js中进行模块引入：

// console.log(age); 抛出异常，age未定义，未导出的情况下，只能在模块内部可见
// console.log(name); 抛出异常，name未定义，导出的情况下，需要通过模块进行访问// 引入模块
var module = require("./module.js");console.log(module.getAge()); // 输出0
console.log(module.name); // 输出果冻想

通过上面的代码，所有在模块内部的变量或函数，如果没有导出，外部就都无法访问，这样就解决了全局变量被污染的问题了。同时，我们也发现了，CommonJS主要是在Node.js中使用，但是在Node.js中，为了让我们使用CommonJS时更舒服，隐藏了很多实现细节，下面我们来看看这些实现细节。

为了实现模块化，Node.js在引入模块时，它会将模块代码放到一个自执行函数中执行，以实现模块化的效果，从而保证不污染全局变量。就如下面这样：
```
(function (){// 模块中的代码
})()
```
为了保证高效的执行，仅加载必要的模块，Node.js只有执行到require函数时才会加载并执行模块（会运行模块内部的代码），并且默认开启了模块缓存，如果模块加载过一次后，会自动使用之前的导出结果；
在模块开执行前，会初始化一个值module.exports = {}；module.exports就是模块将要导出的内容；同时，为了方便开发者导出内容，又声明了一个变量exports = module.exports；这一顿骚操作，搞的很多兄弟们就傻傻分不清楚exports和module.exports有啥区别。所以，Node.js上来就给我们的模块添加了这样的一坨代码：

(function (){  module.exports = {};  var exports = module.exports;  // module.exports 和 exports指向的是同一个地方  // 模块中的代码......  return module.exports;  
})()

模块最后返回的是module.exports，而不是exports。我们在开发时，要么直接给module.exports赋值，进行导出；要么就给exports以添加字段的方式导出；切勿将一个对象直接赋值给exports，这样就会导致exports和module.exports不是指向同一片内存区域，导致模块无法导出。

AMD规范

其实就这样来看，使用CommonJS规范也没有多大问题，但是由于CommonJS是同步的，必须要等到加载完文件并执行完之后才能继续向后执行。每当一个模块require一个子模块的时候，都会停止当前模块的解析直到子模块读取解析并加载。这就导致在浏览器上很影响性能，很影响使用体验；同时，市面上的浏览器厂商五花八门，他们觉得CommonJS不是官方的标准，是社区的标准，所以不愿意支持。

这就导致AMD规范横空出世了，AMD规范专注于浏览器端。AMD全称是Asynchronous Module Definition，即异步模块加载机制，require.js实现了AMD规范。在AMD中，导入和导出模块都必须放在define函数中。

define([要依赖的模块列表], function(导入的模块名称列表){  // 模块内部的代码  return 导出的内容  
})

至于require.js的使用，这里就不展开细说了，后续会专门写篇文章进行总结。这里咱只要知道为啥有了这么个AMD规范，以及require.js实现了AMD规范即可。

CMD规范

CMD：Common Module Definition_，通用模块定义。与 AMD 规范类似，也是用于浏览器端，异步加载模块，一个文件就是一个模块，当模块使用时才会加载执行。其语法与 AMD 规范很类似。这里不做赘述了，如想了解详细内容，可以参考这篇文章：https://mp.weixin.qq.com/s/PysnsP3FnO4eCjXeUJruJw

ES6模块化

江湖嘛，总是会有统一的一天，JavaScript标准委员会也注意到这个模块的混乱问题，所以ES6 在语言标准的层面上，实现了模块功能，而且实现得相当简单，完全可以取代 CommonJS 和 AMD 规范，成为浏览器和服务器通用的模块解决方案。ES6模块化即是未来。至于这个ES6模块化语法，后续专文总结。

技术的演进

根据上面的总结，我们知道使用ES6模块化明显更符合JS的开发，随着web的发展，任何一个支持JS的环境，最终都将会支持ES6的模块化的标准。但是，web端受限于用户使用的浏览器版本，并不能随时使用JS的最新特性。为了能让新代码也能运行在用户的低版本了浏览器上，社区里也有很多工具，它们能静态将高版本规范的代码编译为低版本的代码，比较熟知的就是babel。

但是，对于模块化相关的import和export关键字，babel最终会将它编译为包含require和exports的CommonJs规范。

这就有了一个新的问题，这样带有模块化关键词的模块，编译折后还是没有办法直接运行在浏览器中，因为浏览器端并不能运行CommonJS的模块。为了能在web端直接使用CommonJS规范的模块，除了编译之外，我们还需要一个步骤，就是打包（bundle）。