什么是模块化？

到底什么是模块化、模块化开发呢？

事实上模块化开发最终的目的是将程序划分成一个个小的结构，这个结构中编写属于自己的逻辑代码，有自己的作用域，不会影响到其他的结构，这个结构可以将自己希望暴露的变量、函数、对象等导出给其结构使用，也可以通过某种方式，导入另外结构中的变量、函数、对象等。上面所提到的结构，就是模块；按照这种结构划分开发程序的过程，就是模块化开发的过程；

无论你多么喜欢JavaScript，以及它现在发展的有多好，它都有很多的缺陷，比如var定义的变量作用域问题，比如JavaScript的面向对象并不能像常规面向对象语言一样使用class，比如JavaScript没有模块化的问题。Brendan Eich本人也多次承认过JavaScript设计之初的缺陷，但是随着JavaScript的发展以及标准化，存在的缺陷问题基本都得到了完善。

模块化的历史

在网页开发的早期，Brendan Eich开发JavaScript仅仅作为一种脚本语言，做一些简单的表单验证或动画实现等，那个时候代码还是很少的，这个时候我们只需要将JavaScript代码写到<script>标签中即可，并没有必要放到多个文件中来编写；甚至流行：通常来说 JavaScript 程序的长度只有一行。

但是随着前端和JavaScript的快速发展，JavaScript代码变得越来越复杂了：

• ajax的出现，前后端开发分离，意味着后端返回数据后，我们需要通过JavaScript进行前端页面的渲染；
• SPA的出现，前端页面变得更加复杂：包括前端路由、状态管理等等一系列复杂的需求需要通过JavaScript来实现；
• 包括Node的实现，JavaScript编写复杂的后端程序，没有模块化是致命的硬伤；

所以，模块化已经是JavaScript一个非常迫切的需求，但是JavaScript本身，直到ES6（2015）才推出了自己的模块化方案，在此之前，为了让JavaScript支持模块化，涌现出了很多不同的模块化规范：CommonJS、AMD、CMD等，在我们的课程中，我将详细讲解JavaScript的模块化，尤其是CommonJS和ES6的模块化。

没有模块化带来的问题

早期没有模块化带来了很多的问题：比如命名冲突的问题，当然，我们有办法可以解决上面的问题：立即函数调用表达式IIFE (Immediately Invoked Function Expression)。

但是，我们其实带来了新的问题：

• 第一，我必须记得每一个模块中返回对象的命名，才能在其他模块使用过程中正确的使用；
• 第二，代码写起来混乱不堪，每个文件中的代码都需要包裹在一个匿名函数中来编写；
• 第三，在没有合适的规范情况下，每个人、每个公司都可能会任意命名、甚至出现模块名称相同的情况；

所以，我们会发现，虽然实现了模块化，但是我们的实现过于简单，并且是没有规范的，我们需要制定一定的规范来约束每个人都按照这个规范去编写模块化的代码，这个规范中应该包括核心功能：模块本身可以导出暴露的属性，模块又可以导入自己需要的属性。

JavaScript社区为了解决上面的问题，涌现出一系列好用的规范，接下来我们就学习具有代表性的一些规范。

总结

JS模块化开发就是将我们写的代码划分成一个个小的文件，每个文件是一个模块，在文件中我们将变量导出，其他模块使用的时候再导入就行，模块化开发避免了变量命名冲突、作用域相互影响产生的等等问题。

但是JS在ES6之后才推出自己的模块化方案，在此之前，CommonJS、AMD、CMD这些模块化方案用的最广泛。AMD、CMD我们基本上不使用了，现在在浏览器中我们使用的就是官方的ESModule，如果是在Node中，使用最多的还是CommonJS。

CommonJS规范和Node关系

我们需要知道CommonJS是一个规范，最初提出来是在浏览器以外的地方使用，并且当时被命名为ServerJS，后来为了体现它的广泛性，修改为CommonJS，平时我们也会简称为CJS。

• Node是CommonJS在服务器端一个具有代表性的实现；
• Browserify是CommonJS在浏览器中的一种实现；
• webpack打包工具具备对CommonJS的支持和转换；

所以，Node中对CommonJS进行了支持和实现，让我们在开发node的过程中可以方便的进行模块化开发，在Node中每一个js文件都是一个单独的模块。

这个模块中包括CommonJS规范的核心变量：exports、module.exports、require，我们可以使用这些变量来方便的进行模块化开发，前面我们提到过模块化的核心是导出和导入，Node中对其进行了实现。

• exports和module.exports可以负责对模块中的内容进行导出；
• require函数可以帮助我们导入其他模块（自定义模块、系统模块、第三方库模块）中的内容；

module.exports导出方案

const name = "why"
const age = 18

function sum(num1, num2) {
  return num1 + num2
}

// 1.导出方案 module.exports
module.exports = {
  // aaa: "hahahahaah",
  // bbb: "bbb"
  name,
  age,
  sum
}

require导入

// 使用另外一个模块导出的对象, 那么就要进行导入 require
// const { aaa, bbb } = require("./why.js")
const { name, age, sum } = require("./why.js")

// console.log(aaa)
// console.log(bbb)

console.log(name)
console.log(age)
console.log(sum(20, 30))

内部原理：require函数返回的对象就是module.exports对象，也是我们导出的那个对象，它们三者的内存地址是一样的，这就是它们内部的原理。

exports导出

使用exports导出的时候一定要用一个一个添加属性的方式，如下：

const name = "why"
const age = 18
function sum(num1, num2) {
  return num1 + num2
}

// 第二种导出方式
exports.name = name
exports.age = age
exports.sum = sum

为什么一定要用一个一个添加属性的方式呢？因为node的源码如下：

// 源码
module.exports = {}
exports = module.exports

先给module.exports创建一个空对象，然后让exports指向module.exports，如果我们让exports指向了一个新的对象，但是最终导出的都是module.exports，所以这种导出是不成功的。如下：

// 这种代码不会进行导出
exports = {
  name,
  age,
  sum
}

// 这种代码也不会进行导出
exports.name = name
exports.age = age
exports.sum = sum

module.exports = {

}

module.exports和exports的关系：他们是指向同一个对象，但是最终导出的一定是module.exports。

module.exports和exports的关系

但是Node中我们经常导出东西的时候，又是通过module.exports导出的，module.exports和exports有什么关系或者区别呢？

我们追根溯源，通过维基百科中对CommonJS规范的解析：

CommonJS中是没有module.exports的概念的，但是为了实现模块的导出，Node中使用的是Module的类，每一个模块都是Module的一个实例，也就是module，所以在Node中真正用于导出的其实根本不是exports，而是module.exports，因为module.exports才是导出的真正实现者。

但是，为什么exports也可以导出呢？这个上面源码已经讲过了。

三者引用分析

module.exports、exports、require的返回值其实指向的都是同一个对象，就是我们导出的那个对象，内存图如下：

但是最终导出的一定是module.exports，如果module.exports不再引用exports对象了，那么修改exports就没有任何意义了。

exports的出现是为了更加符合CommonJS规范，但是我们知道它的原理就是导出module.exports，所以我们现在使用exports的很少了，基本上都使用module.exports了。

require()查找规则

我们现在已经知道，require是一个函数，可以帮助我们引入一个文件（模块）中导出的对象。

那么，require的查找规则是怎么样的呢？nodejs.org/dist/latest…

这里我总结比较常见的查找规则：导入格式如下：require(X)

情况一：是个核心模块

X是一个Node核心模块，比如path、http，直接返回核心模块，并且停止查找。

情况二：是个路径

X是以 ./ 或 ../ 或 /（根目录）开头的（就是个路径），那么就按照如下流程来查找。

1. 将X当做一个文件在对应的目录下查找；

① 如果有后缀名，按照后缀名的格式查找对应的文件
② 如果没有后缀名，会按照如下顺序：

直接查找文件X

查找X.js文件

查找X.json文件

查找X.node文件

2. 没有找到对应的文件，将X作为一个目录，查找目录下面的index文件；

查找X/index.js文件

查找X/index.json文件

查找X/index.node文件

如果没有找到，那么报错：not found

情况三：既不是核心模块也不是路径

首先我们在如下路径文件中：

/Users/coderwhy/Desktop/Node/TestCode/04\_learn\_node/05\_javascript-module/02\_commonjs/main.js中

编写如下代码：

console.log(module.paths)
require('why’)

打印结果如下：

这时候执行require('why’)，因为why既不是核心模块也不是路径，就会在文件所在的文件夹中查找node_modules文件夹，然后在node_modules文件夹中查找why，同理也是先找文件再找文件夹，如果没有node_modules文件夹，就再去上层文件夹查找node_modules文件夹，以此类推，也就是上图从上往下的路径。

如果上面的路径中都没有找到，那么报错：not found

总结：

• 如果X是核心模块，直接返回核心模块
• 如果X是路径，就在这个路径下先找文件，后找文件夹，找不到就报错。
• 如果X既不是核心模块也不是路径，那么会在代码所在的文件夹中找node_modules，然后在node_modules里面再查找X，同样也是先找找文件，再找文件夹。如果找不到node_modules，那么就再去上层文件夹查找node_modules，以此类推，找不到就报错。

CommonJS模块的加载过程

1. 模块在被第一次引入时，模块中的js代码会被加载（运行） 一次
2. 模块被多次引入时，会缓存，最终只加载（运行）一次

为什么只会加载运行一次呢？

这是因为每个js文件都有一个module实例，module都有一个属性：loaded，为false表示还没有加载，为true表示已经加载。

3. 多个模块相互引用，模块加载顺序采用的是深度优先算法，加载过的模块是不会重新被加载的

比如，如果出现下图模块的引用关系，那么加载顺序是什么呢？

• 这个其实是一种数据结构：图结构。
• 图结构在遍历的过程中，有深度优先搜索（DFS, depth first search）和广度优先搜索（BFS, breadth first search），Node采用的是深度优先算法。

解释：首先执行main的代码，发现main引用了aaa，就会加载aaa，加载aaa的时候发现aaa又引用了ccc，所以再去加载ccc，同理再加载ddd、eee，eee没有引用其他模块，这时候加载aaa的操作算完成了，继续执行main的代码，发现下一行又引用了bbb，然后就加载bbb，发现bbb又引用了ccc，但是ccc已经被加载过了，所以不会再被加载，所以模块加载顺序是：main -> aaa -> ccc -> ddd -> eee -> bbb

• 深度优先算法：上面的解释就是深度优先算法
• 广度优先算法：广度优先算法就是，加载main的时候，会把main加载的所有模块aaa、bbb都加载完毕，这就是广度优先算法

CommonJS规范缺点

CommonJS加载模块是同步的，同步的意味着只有等到对应的模块加载完毕，当前模块中的内容才能被运行。 当我们通过require('./aaa.js')加载模块的时候，这个在服务器不会有什么问题，因为服务器加载的js文件都是本地文件，加载速度非常快；

如果将它应用于浏览器呢？

当我们通过require('./aaa.js')加载模块的时候，这时候aaa.js文件是在服务端的，就需要先从服务器将文件下载下来，之后再加载运行，那么采用同步的就意味着后续的js代码都无法正常运行，即使是一些简单的DOM操作，所以在浏览器中，我们通常不使用CommonJS规范。

当然在webpack中使用CommonJS是另外一回事，因为webpack会将我们的代码转成浏览器可以直接执行的异步函数代码。

在早期为了可以在浏览器中使用模块化去异步加载模块，通常会采用AMD或CMD。但是目前一方面现代的浏览器已经支持ES Modules，另一方面借助于webpack等工具可以实现对CommonJS或者ESModule代码的转换，AMD和CMD已经使用非常少了，所以这里我们只进行简单的演练。

AMD规范

AMD主要是应用于浏览器的一种模块化规范，AMD是Asynchronous Module Definition（异步模块定义）的缩写，它采用的是异步加载模块。

事实上AMD的规范还要早于CommonJS，但是CommonJS目前依然在被使用，而AMD使用的较少了。

我们提到过，规范只是定义代码的应该如何去编写，只有有了具体的实现才能被应用：AMD实现的比较常用的库是require.js。

require.js的使用

1. 下载require.js

• 下载地址：github.com/requirejs/r…
• 找到其中的require.js文件；

2. index.html的script标签引入require.js和入口文件：

• <script src="./lib/require.js" data-main="./main.js"></script>
• 注意：data-main属性的作用是保证在加载完src的文件后会加载执行该文件，因为我们使用的是AMD规范，所以一定要等require.js加载完毕后再加载其它模块

3. 使用define函数去定义我们导出的东西，然后返回一个对象

4 . 首先要通过require.config去注册模块（这个require就是require.js里面的函数），然后就可以使用require使用模块，在第二个参数的回调函数中拿到模块导出内容

CMD规范

CMD规范也是应用于浏览器的一种模块化规范，CMD 是Common Module Definition（通用模块定义）的缩写。

它也采用了异步加载模块，但是它将CommonJS的优点吸收了过来，但是目前CMD使用也非常少了，CMD也有自己比较优秀的实现方案：SeaJS。

1. 下载SeaJS

• 下载地址：github.com/seajs/seajs
• 找到dist文件夹下的sea.js

2. 引入sea.js和使用主入口文件

<script src="./lib/sea.js"></script>
<script>
  // 也可以使用 data-main="./src/main.js" 指定入口文件，但是官方的案例是使用seajs.use指定入口文件
  seajs.use("./src/main.js")
</script>

3. 通过define定义模块，define接受一个函数作为参数，这个函数有三个参数，分别是import、exports、module，我们就可以使用这三个参数进行导入和导出：

main.js

define(function(require, exports, module) {
  // 这个函数会有三个参数，使用这三个参数就可以进行导入和导出了 和common.js有点像
  const foo = require("./foo")
  console.log("main:", foo)
})

foo.js

define(function(require, exports, module) {
  // 这个函数会有三个参数，使用这三个参数就可以进行导入和导出了 和common.js有点像
  const name = "why"
  const age = 18
  function sum(num1, num2) {
    return num1 + num2
  }

  // exports.name = name
  // exports.age = age

  module.exports = {
    name,
    age,
    sum
  }
});

总结：

• AMD规范代表的库是require.js，CMD代表的库是sea.js，它们都是异步加载模块
• require.js使用define定义模块，然后返回。其它模块使用的时候要先用require.config注册，然后再通过require使用
• sea.js直接使用define定义模块，define参数的回调函数中会拿到inport、exports、module，我们再拿到这三个参数进行导入和导出，和CommonJS有点像

认识 ES Module

JavaScript没有模块化一直是它的痛点，所以才会产生我们前面学习的社区规范：AMD、CMD、CommonJS等，所以在ES推出自己的模块化系统时，大家也是兴奋异常。

ES Module和CommonJS的模块化有一些不同之处：

• 一方面它使用了import导入和export导出关键字；
• 另一方面它采用编译期的静态分析，并且也加入了动态引用的方式；

ES Module模块采用export和import关键字来实现模块化：

export负责将模块内的内容导出；

import负责从其他模块导入内容；

了解：采用ES Module将自动采用严格模式：use strict

如果你不熟悉严格模式可以简单看一下MDN上的解析：developer.mozilla.org/zh-CN/docs/…

ES Module模块化基本使用

html文件引入main.js文件：

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Document</title>
</head>
<body>
  <script src="./main.js" type="module"></script>
</body>
</html>

main.js文件使用了从foo.js导入的变量：

import { name, age } from "./foo.js"
console.log(name)
console.log(age)

foo.js文件导出了变量：

export const name = "why"
export const age = 18

最后运行代码，打印：

why
18

注意点1：通过script标签引入main.js的文件的时候一定要加上type="module"，否则会报错如下，错误的意思是：不能在模块外使用import语句。

注意点2：如果直接使用浏览器打开上面的index.html会报错如下：

这个在MDN上面有给出解释：developer.mozilla.org/zh-CN/docs/…

如果你通过本地加载Html 文件 (比如一个 file:// 路径的文件)，你将会遇到 CORS 错误，因为Javascript模块安全性需要，不允许加载file://开头的文件。

所以你需要通过一个本地服务器来测试。我这里使用的VSCode，VSCode中有一个插件：Live Server，我们安装这个插件，然后右键通过Live Server打开index.html文件即可。

export导出方式

export关键字将一个模块中的变量、函数、类等导出；

• 方式一：在语句声明的前面直接加上export关键字
• 方式二：将所有需要导出的标识符，放到export后面的 {}中
• 方式三：导出时给标识符起一个别名

// 1.第一种方式: export 声明语句
export const name = "why"
export const age = 18

export function foo() {
  console.log("foo function")
}

export class Person {

}

// 2.第二种方式: export 导出 和 声明分开
const name = "why"
const age = 18
function foo() {
  console.log("foo function")
}

// 注意:这里的{}不是对象,只是export特定的语法
// 所以,这里的{}里面不是ES6的对象字面量的增强写法，{}也不是表示一个对象的，所以： export {name: name}，是错误的写法；
export {
  name,
  age,
  foo
}

// 3.第三种方式: 第二种导出时起别名
export {
  name as fName,
  age as fAge,
  foo as fFoo
}

第一种第二种使用的比较多，如果真的有命名冲突，我们一般也不会使用第三种方式在导出的时候起别名，我们一般在导入的时候再起别名。

import导入方式

import关键字负责从另外一个模块中导入内容，导入内容的方式也有多种：

• 方式一：import { 标识符列表 } from '模块'；
• 方式二：导入时给标识符起别名
• 方式三：将导出的所有内容放到一个标识符中

// 1.导入方式一: 普通的导入
// 这里的{}也不是一个对象，里面只是存放导入的标识符列表内容；
import { name, age, foo } from "./foo.js"
import { fName, fAge, fFoo } from './foo.js'

// 2.导入方式二: 起别名
import { name as fName, age as fAge, foo as fFoo } from './foo.js'

// 3.导入方式三: 将导出的所有内容放到一个标识符中
import * as foo from './foo.js'

// 使用的时候就要foo.name 
console.log(foo.name)
console.log(foo.age)
foo.foo()

这三种方式都使用的比较多。

export和import结合使用

在开发和封装一个功能库时，通常我们希望将暴露的所有接口放到一个文件中，这样方便指定统一的接口规范，也方便阅读，这个时候，我们就可以使用export和import结合使用。

比如utils文件夹里面是我们的工具库，里面有format.js和math.js它们的代码如下：

// format.js
function timeFormat() {
  return "2222-12-12"
}

function priceFormat() {
  return "222.22"
}

export {
  timeFormat,
  priceFormat
}

// math.js
function add(num1, num2) {
  return num1 + num2
}

function sub(num1, num2) {
  return num1 - num2
}

export {
  add,
  sub
}

当main.js使用这些工具库的时候要一个一个导入，这就很麻烦。

import { add, sub } from './utils/math.js'
import { priceFormat, timeFormat } from './utils/format.js'

console.log(add(10, 20))
console.log(sub(10, 20))
console.log(priceFormat())
console.log(timeFormat())

所以一般我们就在utils文件夹中再创建一个index.js，然后统一导出，这时候我们的main.js的代码就如下：

import { add, sub, priceFormat, timeFormat } from './utils/index.js'

console.log(add(10, 20))
console.log(sub(10, 20))
console.log(priceFormat())
console.log(timeFormat())

所以我们就需要在index.js文件中导入其他文件代码，然后再统一导出，有三种方式，第二种、第三种方式就是import和export结合使用的。

// 1.导出方式一:
import { add, sub } from './math.js'
import { timeFormat, priceFormat } from './format.js'

export {
  add,
  sub,
  timeFormat,
  priceFormat
}

// 2.导出方式二:
export { add, sub } from './math.js'
export { timeFormat, priceFormat } from './format.js'

// 3.导出方式三:
export * from './math.js'
export * from './format.js'

export default用法

前面我们学习的导出功能都是有名字的导出（named exports）。就是在导出export时指定了名字，在导入import时需要知道具体的名字。

还有一种导出叫做默认导出（default export），默认导出export时可以不需要指定名字，在导入时不需要使用 {}，并且可以自己来指定名字，它也方便我们和现有的CommonJS等规范相互操作。

注意：在一个模块中，只能有一个默认导出（default export），默认导出有两种方式，第二种方式使用的最多。如下：

const name = "why"
const age = 18

const foo = "foo value"

export {
  name,
  age,
  // 1.默认导出的方式一:
  // foo as default
}

// 2.默认导出的方式二: 常见
export default foo

// 注意: 默认导出只能有一个

使用：

import { name, age } from './foo.js'

// 虽然看起来不需要名字,但是我们使用foo的时候也需要通过foo.name来使用,所以重命名
// import * as foo from './foo.js'

// 这时候why既不是name也不是age,而是导入的默认的导出foo
import why from './foo.js'
console.log(why)  // foo value

默认导出一般使用在导出的东西是特别重要的情况下。

import()函数

前面我们导入代码是这样的：

import { name, age, foo } from './foo.js'

console.log("后续的代码都是不会运行的~")

在foo.js被解析完之前，后面的代码是不会执行的，因为后面的代码有可能使用到foo.js模块的东西。

如果我们想要一边解析模块，后面的代码又不影响执行，我们可以使用import()函数，import()函数会返回一个Promise，我们可以在Promise的then回调中拿到这个解析的模块，然后使用。

// import函数返回的结果是一个Promise
import("./foo.js").then(res => {
  console.log("res:", res.name)
})

console.log("后续的代码会继续执行")

补充：import.meta

import.meta是一个给JavaScript模块暴露特定上下文的元数据属性的对象。

• 它包含了这个模块的信息，比如说这个模块的URL；
• 在ES11（ES2020）中新增的特性；

// ES11新增的特性
// meta属性本身也是一个对象: { url: "当前模块所在的路径" }
console.log(import.meta)

import.meta.url就是当前模块所在的路径。

ES Module的解析流程

回忆 - CommonJS内部原理：require函数返回的对象就是module.exports对象，也是我们导出的那个对象，它们三者的内存地址是一样的，这就是它们内部的原理。

ES Module是如何被浏览器解析并且让模块之间可以相互引用的呢？ hacks.mozilla.org/2018/03/es-…

ES Module的解析过程可以划分为三个阶段：

1. 构建阶段（Construction），根据地址查找js文件，并且下载（所以我们上面说的file://方式会报错），将其解析成模块记录（Module Record）；
2. 实例化阶段（Instantiation），对模块记录进行实例化，并且分配内存空间，解析模块的导入和导出语句，把模块指向对应的内存地址。
3. 运行阶段（Evaluation），运行代码，计算值，并且将值填充到内存地址中；

阶段一：构建阶段

1. 构建阶段就是下载JS文件，以及JS文件引用的其他JS文件，然后将每个js文件解析成Module Record，同一个js文件不会被重复下载，因为在Module Map中记录了每一个js文件，它有个loaded属性，会记录当前js文件有没有被下载过。

阶段二和三：实例化阶段 – 运行阶段

2. 实例化阶段就是对每个js文件进行实例化，然后解析其中的导入和导出。
3. 运行阶段才会真正执行js文件中的代码

总结：下载 -> 实例化 -> 运行

为什么模块导入不能放在代码执行中

知道ES Module的三个阶段之后，我们就能理解为什么下面代码会报错了：

if (true) {
    import sub from './modules/foo.js';
}

因为模块导入是在第二阶段，代码运行是在第三阶段，代码运行的时候，这个模块还没构建呢，所以会报错。

但是某些情况下，我们确确实实希望动态的来加载某一个模块，如果根据不同的条件，动态来选择加载模块的路径，这个时候我们需要使用 import() 函数来动态加载。

补充：关于CommonsJS和ESModule的相互调用

1. 在浏览器中，肯定不能相互调用，因为浏览器不支持CommonJS。
2. 在node中，node支持CommonJS是肯定的，但是以前的node版本不支持ESModule，最新的node版本才支持ESModule，所以这个和node版本有关。
3. 平常开发中，平常开发中我们都使用webpack，webpack对于CommonJS和ESModule都支持，所以支持相互调用。