二、Javascript的模块化开发【CommonJS和ESModule模块化开发】

Lyk 2022/8/15 前端工程化CommonJS模块规范CMD规范了解AMD规范了解ESModule模块规范

# 1、什么是模块化？

到底什么是模块化、模块化开发呢？
- 事实上模块化开发最终的目的是将程序划分成一个个小的结构；
- 这个结构中编写属于自己的逻辑代码，有自己的作用域，定义变量名词时不会影响到其他的结构；
- 这个结构可以将自己希望暴露的变量、函数、对象等导出给其结构使用；
- 也可以通过某种方式，导入另外结构中的变量、函数、对象等；
上面说提到的结构，就是模块；按照这种结构划分开发程序的过程，就是模块化开发的过程；
无论你多么喜欢JavaScript，以及它现在发展的有多好，它都有很多的缺陷：
- 比如var定义的变量作用域问题；
- 比如JavaScript的面向对象并不能像常规面向对象语言一样使用class；
- 比如JavaScript没有模块化 的问题；
对于早期的JavaScript没有模块化来说，确确实实带来了很多的问题；

# 2、模块化的历史

在网页开发的早期，Brendan Eich开发JavaScript仅仅作为一种脚本语言，做一些简单的表单验证或动画实现等，那个时候代码还是很少的：
- 这个时候我们只需要将JavaScript代码写到script标签中即可；
- 并没有必要放到多个文件中来编写；甚至流行：通常来说 JavaScript 程序的长度只有一行。
但是随着前端和JavaScript的快速发展，JavaScript代码变得越来越复杂了：
- ajax的出现，前后端开发分离，意味着后端返回数据后，我们需要通过JavaScript进行前端页面的渲染；
- SPA的出现，前端页面变得更加复杂：包括前端路由、状态管理等等一系列复杂的需求需要通过JavaScript来实现；
- 包括Node的实现，JavaScript编写复杂的后端程序，没有模块化是致命的硬伤；
所以，模块化已经是JavaScript一个非常迫切的需求：
- 但是JavaScript本身，直到ES6（2015）才推出了自己的模块化方案ESMoudle；
- 在此之前，为了让JavaScript支持模块化，涌现出了很多不同的模块化规范：AMD、CMD、CommonJS等；
在我们的学习过程中，我们将详细学习JavaScript的模块化，尤其是CommonJS和ES6的模块化。

# 3、没有模块化带来的问题

早期没有模块化带来了很多的问题：比如命名冲突的问题
当然，我们有办法可以解决上面的问题：立即函数调用表达式（IIFE）
- (function(){})()->创建单个js文件自己的作用域
- IIFE (Immediately Invoked Function Expression)

const sum = (function(){
  const name = "kobe"
  const age = 18
  const age1 = 39
  return function sum(n,m) {
    return n + m
  }
})()

1
2
3
4
5
6
7
8

但是，我们其实带来了新的问题：
- 第一，我必须记得每一个模块中返回对象的命名，才能在其他模块使用过程中正确的使用；
- 第二，代码写起来混乱不堪，每个文件中的代码都需要包裹在一个匿名函数中来编写；
- 第三，在没有合适的规范情况下，每个人、每个公司都可能会任意命名、甚至出现模块名称相同的情况；
所以，我们会发现，虽然实现了模块化，但是我们的实现过于简单，并且是没有规范的。
- 我们需要制定一定的规范来约束每个人都按照这个规范去编写模块化的代码；
- 这个规范中应该包括核心功能：模块本身可以导出暴露的属性，模块又可以导入自己需要的属性；
- JavaScript社区为了解决上面的问题，涌现出一系列好用的规范，接下来我们就学习具有代表性的一些规范。

# 4、模块化规划：CommonJS

# 4.1.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函数可以帮助我们导入其他模块（自定义模块、系统模块、第三方库模块）中的内容；

# 4.2.模块化案例

我们来看一下两个文件：

# 4.3.exports导出

注意：exports是一个对象，我们可以在这个对象中添加很多个属性，添加的属性会导出；

另外一个文件中可以导入：

上面这行完成了什么操作呢？理解下面这句话，Node中的模块化一目了然
- 意味着main中的bar变量等于exports对象；
- 也就是require通过各种查找方式，最终找到了exports这个对象；
- 并且将这个exports对象赋值给了bar变量；
- bar变量就是exports对象了；

# 4.4.module.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对象的一个引用；
- 也就是说 module.exports = exports = main中的bar（用exports进行导出的情况下）；

# 4.5.改变代码发生了什么?

如果我将exports的导出方式变成module.exports导出。会有什么区别呢？发生了什么？

我们这里从几个方面来研究修改代码发生了什么？

1.在两者者项目引用的情况下，修改exports中的name属性到底发生了什么？

2.在两者引用的情况下，修改了main中的bar的name属性，在bar模块中会发生什么？

3.如果module.exports不再引用exports对象了，那么修改export还有意义吗？
先画出在内存中发生了什么，再得出最后的结论。
- 用exports导出的情况：module对象的exports属性（module.exports）是exports对象的一个引用
  - 即修改export对象有意义；如下图
- 用module.exports导出的情况：module.exports不再引用exports对象了;
  - 即修改export对象无意义；如下图
  - 如下图：如果你在bar.js中设置一个定时器，6秒后获取module.exports.name的值；那么该值会是：curry
为了更加深入的理解exports跟module.exports的关系，可以根据下面代码创建两个文件：main.js和bar.js;然后本地执行node main.js ；看具体打印结果来进行进一步理解

//main.js文件内容
const bar = require('./bar')
const {name, age, sayHello} = bar

console.log('main 全局 name:',name)//main 全局 name: kobe

setTimeout(() => {
  console.log("require('./bar')函数拿到的bar对象的name:",bar.name)//require('./bar')函数拿到的bar对象的name: kobe
},2000)

setTimeout(() => {
  bar.name = 'curry'
  exports.name = 'rose'
},3000)

setTimeout(() => {
  const {name} = bar
  console.log('main 局部 name:',name)//main 局部 name: curry
  console.log('main module.export.name:',module.exports.name)//main module.export.name: rose
}, 8000);

setTimeout(() => {
  console.log('main 全局 name:',name)//main 全局 name: kobe
}, 9000);

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

//bar.js文件内容
const name = 'kobe'
const age = 39
function sayHello(name) {
  console.log("Hello" + name)
}
setTimeout(() => {
  exports.name = 'lyk'
}, 1000);
setTimeout(() => {
  console.log('bar exports.name:',exports.name)//bar exports.name: lyk
},4000)
setTimeout(() => {
  console.log('bar module.export.name:',module.exports.name)//bar module.export.name: curry
  console.log('bar 全局 name:',name)//bar 全局 name: kobe
},6000)
module.exports = {
  name,
  age,
  sayHello
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

//本地执行main.js后，打印结果如下：
//main 全局 name: kobe
//require('./bar')函数拿到的bar对象的name: kobe
//bar exports.name: lyk
//bar module.export.name: curry
//bar 全局 name: kobe
//main 局部 name: curry
//main module.export.name: rose
//main 全局 name: kobe

1
2
3
4
5
6
7
8
9

# 4.6.require细节

我们现在已经知道，require是一个函数，可以帮助我们引入一个文件（模块）中导出的对象。
那么，require的查找规则是怎么样的呢？
- 这里我总结比较常见的查找规则：
- 导入格式如下：require(X)

# 4.6.1.情况一：X是一个Node核心模块，比如path、http

require('path')直接返回核心模块，并且停止查找

# 4.6.2.情况二：X是以 ./ 或 ../ 或 /（根目录）开头的

第一步：将X当做一个文件在对应的目录下查找；require('./utils')
1. 如果有后缀名，按照后缀名的格式查找对应的文件
2. 如果没有后缀名，会按照如下顺序：
  1. 直接查找文件X ./utils
  2. 查找X.js文件./utils.js
  3. 查找X.json文件./utils.json
  4. 查找X.node文件./utils.node
第二步：没有找到对应的文件，将X作为一个目录
- 查找目录下面的index文件./utils/index
  1. 查找X/index.js文件./utils/index.js
  2. 查找X/index.json文件./utils/index.json
  3. 查找X/index.node文件./utils/index.node
如果没有找到，那么报错：not found

# 4.6.3.情况三：直接是一个X（没有路径），并且X不是一个核心模块

/Users/coderwhy/Desktop/Node/TestCode/04_learn_node/05_javascript-module/02_commonjs/main.js中编写 require('why')
找每个目录下的node_modules文件夹

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

# 4.7.模块的加载过程

结论一：模块在被第一次引入时，模块中的js代码会被运行一次
结论二：模块被多次引入时，会缓存，最终只加载（运行）一次
- 为什么只会加载运行一次呢？
- 这是因为每个模块对象module都有一个属性：loaded。
- 为false表示还没有加载，为true表示已经加载；
结论三：如果有循环引入，那么加载顺序是什么？
如果出现下图模块的引用关系，那么加载顺序是什么呢？
- 这个其实是一种数据结构：图结构；
- 图结构在遍历的过程中，有深度优先搜索（DFS, depth first search）和广度优先搜索（BFS, breadth first search）；
- Node采用的是深度优先算法：main -> aaa -> ccc -> ddd -> eee ->bbb

# 4.8.CommonJS规范缺点

CommonJS加载模块是同步的：
同步的意味着只有等到对应的模块加载完毕，当前模块中的内容才能被运行；
这个在服务器不会有什么问题，因为服务器加载的js文件都是本地文件，加载速度非常快；
如果将它应用于浏览器呢？
浏览器加载js文件需要先从服务器将文件下载下来，之后再加载运行；
那么采用同步的就意味着后续的js代码都无法正常运行，即使是一些简单的DOM操作；
所以在浏览器中，我们通常不使用CommonJS规范：
当然在webpack中使用CommonJS是另外一回事；
因为它会将我们的代码转成浏览器可以直接执行的代码；
在早期为了可以在浏览器中使用模块化，通常会采用AMD或CMD：
但是目前一方面现代的浏览器已经支持ES Modules，另一方面借助于webpack等工具可以实现对CommonJS或者ESModule代码的转换；
AMD和CMD已经使用非常少了；

# 5、AMD规范（了解）

# 5.1.了解AMD规范

AMD主要是应用于浏览器的一种模块化规范：
- AMD是Asynchronous Module Definition（异步模块定义）的缩写；
- 它采用的是异步加载模块；
- 事实上AMD的规范还要早于CommonJS，但是CommonJS目前依然在被使用，而AMD使用的较少了；
我们提到过，规范只是定义代码的应该如何去编写，只有有了具体的实现才能被应用：
AMD实现的比较常用的库是require.js和curl.js；

# 5.2.require.js的使用

第一步：下载require.js
- 下载地址：下载地址 (opens new window)
- 找到其中的require.js文件；
第二步：定义HTML的script标签引入require.js和定义入口文件：
- data-main属性的作用是在加载完src的文件后会加载执行该文件
  
  <script src="./lib/require.js" data-main="./index.js"></script>

# 6、CMD规范（了解)

# 6.1.了解CMD规范

CMD规范也是应用于浏览器的一种模块化规范：
CMD 是Common Module Definition（通用模块定义）的缩写；
它也采用的也是异步加载模块，但是它将CommonJS的优点吸收了过来；
但是目前CMD使用也非常少了；
CMD也有自己比较优秀的实现方案：
- SeaJS

# 6.2.SeaJS的使用

第一步：下载SeaJS
- 下载地址：下载地址 (opens new window)
- 找到dist文件夹下的sea.js
第二步：引入sea.js和使用主入口文件
- seajs是指定主入口文件的

# 7、模块化规范：ES Module

# 7.1.认识 ES Module

JavaScript没有模块化一直是它的痛点，所以才会产生我们前面学习的社区规范：CommonJS、AMD、CMD等，所以在ECMA推出自己的模块化系统时，大家也是兴奋异常。
ES Module和CommonJS的模块化有一些不同之处：
- 一方面它使用了import和export关键字；
- 另一方面它采用编译期的静态分析，并且也加入了动态引用的方式；
ES Module模块采用export和import关键字来实现模块化：
- export负责将模块内的内容导出；
- import负责从其他模块导入内容；
了解：采用ES Module将自动采用严格模式：use strict

# 7.2.案例代码结构组件

这里我在浏览器中演示ES6的模块化开发：

<script src="./modules/foo.js" type="module">
</script> <script src="main.js" type="module"></script>

1
2

注意：在浏览器用模块化开发，在html文件中需要引入script标签；并且把script标签的type属性设置为module；这样才算引入了一个模块；每个模块都会有自己的作用域；
- 如果不设置type属性，浏览器在解析js文件时，会抛出相应的错误：无法在模块外使用import语句或捕获的语法错误：意外的标记“export”等
如果直接在浏览器中运行代码，会报如下错误：

这个在MDN上面有给出解释：
- Module规范mdn参考 (opens new window)
- 你需要注意本地测试 — 如果你通过本地加载Html 文件 (比如一个 file:// 路径的文件), 你将会遇到 CORS 错误，因为Javascript 模块安全性需要；
- 你需要通过一个服务器来测试；
- 我这里使用的VSCode插件：Live Server 来开启一个本地服务；就可以正常运行模块化的代码啦

# 7.3.exports关键字

export关键字将一个模块中的变量、函数、类等导出；
我们希望将其他中内容全部导出，它可以有如下的方式：
- 方式一：在语句声明的前面直接加上export关键字（弊端：该方式导出 -> 不可取别名）
- 方式二：将所有需要导出的标识符，放到export后面的 {}中
  - 注意：这里的 {}里面不是ES6的对象字面量的增强写法，{}也不是表示一个对象的；
  - 所以： export {name: name}，是错误的写法；
- 方式三：导出时给标识符起一个别名
  - 通过as关键字起别名

// 1.方式一：在语句声明的前面直接加上export关键字
export const age = 39
// 2. 方式二：将所有需要导出的标识符，放到export后面的 {}中
//   - 注意：这里的 {}里面不是ES6的对象字面量的增强写法，{}也不是表示一个对象的；
//   - 所以： export {name: name}，是错误的写法；
//   - 即这里的export {} 是一种特殊语法 
const name = 'kobe'
function sum(n,m) {
  console.log(n+m)
}
export {name,sum}

// 3. 方式三：导出时给标识符起一个别名
//   - 通过as关键字起别名
const address = '北京'
export {
  address as ar
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

上面3种导出方式（实际两种），可以在同一个模块中混用；
- 导出语句可以写在任意位置，因为浏览器在解析执行js模块时，最后才会执行export语句

# 7.4.import关键字

import关键字负责从另外一个模块中导入内容
导入内容的方式也有多种：
- 方式一：import {标识符列表} from '模块'；
  - 注意：这里的{}也不是一个对象，里面只是存放导入的标识符列表内容；
- 方式二：导入时给标识符起别名
  - 通过as关键字起别名
- 方式三：通过 * 将模块功能放到一个模块功能对象（a module object）上

// 1. 方式一：import {标识符列表} from '模块'；
//   - 注意：这里的{}也不是一个对象，里面只是存放导入的标识符列表内容；
import {name, sum,age,ar} from './foo.js'
console.log(name)//kobe
sum(20,500)//520
console.log(ar)//北京
console.log(age)//39

// 2. 方式二：导入时给标识符起别名
//   - 通过as关键字起别名
import {name as newName,sum as mainSum,ar as newAddress} from './foo.js'
console.log(newName)//kobe
mainSum(20,80)//100
console.log(newAddress)//北京

// 3. 方式三：通过 * 将模块功能放到一个模块功能对象（a module object）上
import * as obj from './foo.js'
console.log(obj)//Module {Symbol(Symbol.toStringTag): 'Module'}
console.log(obj.name,obj.age,obj.ar)//kobe 39 北京
obj.sum(30,30)//60

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

上面3种导入方式(实际两种)，可以在同一个模块中混用
- 导入语句可以写在任意位置，因为浏览器在解析执行js模块时，最先执行import语句

# 7.5.export和import结合使用

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

# 7.6.default export用法

前面我们学习的导出功能都是有名字的导出（named exports）：
- 在导出export时指定了名字；
- 在导入import时需要知道具体的名字；
还有一种导出叫做默认导出（default export）
- 默认导出export时可以不需要指定名字；
- 在导入时不需要使用 {}，并且可以自己来指定名字；
- 它也方便我们和现有的CommonJS等规范相互操作；
注意：在一个模块中，只能有一个默认导出（default export）；

//main.js加上如下语句：
//如果你在main.js中拿到bar.js导出的所有值；你会发现下面obj对象的有这些属性：address,age,default,name;
//这样你就可以通过obj.default拿到bar.js模块，默认导出的函数sum了
import * as obj from './bar.js'
console.log(obj)
console.log(obj.defalut)//f sum(n,m)

//import {default} from './bar.js' //当然这种获取方式是不可以的哦；浏览器会抛出错误：意外保留字

1
2
3
4
5
6
7
8

# 7.7.import函数

通过import加载一个模块，是不可以在其放到逻辑代码中的，比如：

为什么会出现这个情况呢？
- 这是因为ES Module在被JS引擎解析时，就必须知道它的依赖关系；
- 由于这个时候js代码没有任何的运行，所以无法在进行类似于if判断中根据代码的执行情况；
- 甚至拼接路径的写法也是错误的：因为我们必须到运行时能确定path的值；
但是某些情况下，我们确确实实希望动态的来加载某一个模块：
- 如果根据不懂的条件，动态来选择加载模块的路径；
- 这个时候我们需要使用 import() 函数来动态加载；
  - import函数返回一个Promise，可以通过then获取结果；

上图import函数导入foo.js模块，如果foo.js模块有导出内容，那么调用import函数返回的promise会立即调用自己then方法中的回调函数，在回调函数中拿到对应foo.js模块导出的内容；
- 具体分析：首先将foo.js模块导出的内容（sum函数）加入到模块功能对象``Module {Symbol(Symbol.toStringTag): 'Module'} 中；然后返回的promise会将该模块功能对象通过resolve函数回调出去，这样我们返回的promise的then方法中的回调函数就会被执行且可以拿到这个模块功能对象，然后就可以通过模块功能对象(sum.sum) 拿到foo.js模块导出的内容；即sum函数；

# 7.8.import meta

import.meta是一个给JavaScript模块暴露特定上下文的元数据属性的对象。
- 它包含了这个模块的信息，比如说这个模块的URL；
- 在ES11（ES2020）中新增的特性；

//main.js
console.log(import.meta)//{url: 'http://127.0.0.1:5500/ESModule%E8%A7%84%E8%8C%83/import%E5%87%BD%E6%95%B0/main.js'}

1
2

# 7.9.ES Module的解析流程

ES Module是如何被浏览器解析并且让模块之间可以相互引用的呢？
- 官方详细了解 (opens new window)
ES Module的解析过程可以划分为三个阶段：
- 阶段一：构建（Construction），根据地址查找js文件，并且下载，将其解析成模块记录（Module Record）；
- 阶段二：实例化（Instantiation），对模块记录进行实例化，并且分配内存空间，解析模块的导入和导出语句，把模块指向对应的内存地址。
阶段三：运行（Evaluation），运行代码，计算值，并且将值填充到内存地址中；

# 7.10.阶段一：构建阶段

# 7.11.阶段二和三：实例化阶段 – 求值阶段

一、初识Nodejs开发三、前端开发常用的包管理工具(npm,yarn,pnpm,cnpm,npx)深入学习

Lyk-Blog

Choose mode

二、Javascript的模块化开发【CommonJS和ESModule模块化开发】

二、Javascript的模块化开发【CommonJS和ESModule模块化开发】

# 1、什么是模块化？

# 2、模块化的历史

# 3、没有模块化带来的问题

# 4、模块化规划：CommonJS

# 4.1.CommonJS规范和Node关系

# 4.2.模块化案例

# 4.3.exports导出

# 4.4.module.exports导出

# 4.5.改变代码发生了什么?

# 4.6.require细节

# 4.6.1.情况一：X是一个Node核心模块，比如path、http

# 4.6.2.情况二：X是以 ./ 或 ../ 或 /（根目录）开头的

# 4.6.3.情况三：直接是一个X（没有路径），并且X不是一个核心模块

# 4.7.模块的加载过程

# 4.8.CommonJS规范缺点

# 5、AMD规范（了解）

# 5.1.了解AMD规范

# 5.2.require.js的使用

# 6、CMD规范（了解)

# 6.1.了解CMD规范

# 6.2.SeaJS的使用

# 7、模块化规范：ES Module

# 7.1.认识 ES Module

# 7.2.案例代码结构组件

# 7.3.exports关键字

# 7.4.import关键字

# 7.5.export和import结合使用

# 7.6.default export用法

# 7.7.import函数

# 7.8.import meta

# 7.9.ES Module的解析流程

# 7.10.阶段一：构建阶段

# 7.11.阶段二和三：实例化阶段 – 求值阶段