JavaScript模块化-CommonJS规范

刺骨的言语ヽ痛彻心扉 2023-09-28 14:23 94阅读 0赞

#### 文章目录 ####

*   *  认识模块化开发
     *   *  什么是模块化
         *  模块化的历史
         *  没有模块化带来的问题
     *  CommonJS规范
     *   *  CJS规范在Node的实现
         *  模块化简单案例
         *  exports和require本质
         *  module.exports导出
         *  require细节
         *  模块的加载过程
         *  CommonJS规范缺点

### 认识模块化开发 ###

> 我们先来思考一个问题, 通过script便签引入不同的js文件是模块化吗?
> 
>  *  其实并不是模块化开发
>  *  我们在不同的js文件中定义相同的变量或者函数, 引入到同一个html文件中, 是会有命名冲突问题的
>  *  而模块化开发是想要做到, 不同js文件的变量不会有命名冲突问题

#### 什么是模块化 ####

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

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

**上面说提到的结构，就是模块；按照这种结构划分开发程序的过程，就是模块化开发的过程；**

**无论你多么喜欢JavaScript，以及它现在发展的有多好，它都有很多的缺陷**：

*  比如var定义的变量作用域问题；
 *  比如JavaScript的面向对象并不能像常规面向对象语言一样使用class；
 *  比如JavaScript没有模块化的问题；

**对于早期的JavaScript没有模块化来说，确确实实带来了很多的问题；**

#### 模块化的历史 ####

**在网页开发的早期，BrendanEich开发JavaScript仅仅作为一种脚本语言，做一些简单的表单验证或动画实现等，那个时候代码还是很少的**：

*  这个时候我们只需要讲JavaScript代码写到<script>标签中即可；
 *  并没有必要放到多个文件中来编写；甚至流行：通常来说 JavaScript 程序的长度只有一行。

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

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

**所以，模块化已经是JavaScript一个非常迫切的需求**：

*  但是JavaScript本身，直到ES6（2015）才推出了自己的模块化方案；
 *  在此之前，为了让JavaScript支持模块化，涌现出了很多不同的模块化规范：AMD、CMD、CommonJS等；

**我会详细讲解JavaScript的模块化，尤其是CommonJS和ES6的模块化。**

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

**早期没有模块化带来了很多的问题：比如命名冲突的问题**

**当然，我们有办法可以解决上面的问题：通过立即函数调用表达式（IIFE）**

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

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

**所以，我们会发现，虽然实现了模块化，但是我们的实现过于简单，并且是没有规范的。**

*  我们需要制定一定的规范来约束每个人都按照这个规范去编写模块化的代码；
 *  这个规范中应该包括核心功能：模块本身可以导出暴露的属性，模块又可以导入自己需要的属性；
 *  JavaScript社区为了解决上面的问题，涌现出一系列好用的规范，接下来我们就学习具有代表性的一些规范。

### CommonJS规范 ###

#### CJS规范在Node的实现 ####

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

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

**所以，Node中对CommonJS进行了支持和实现，让我们在开发node的过程中可以方便的进行模块化开发**：

*  p在Node中每一个js文件都是一个单独的模块；
 *  这个模块中包括CommonJS规范的核心变量：exports、module.exports、require；
 *  我们可以使用这些变量来方便的进行模块化开发；

**前面我们提到过模块化的核心是导出和导入，Node中对其进行了实现**：

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

#### 模块化简单案例 ####

有一个foo模块我们需要对其导出

const NAME = "kaisa"
    let age = 18
    
    function sayHello() {
        
      console.log("Hello" + " " + NAME)
    }
    
    // 导出
    exports.NAME = NAME
    exports.age = age
    exports.sayHello = sayHello

在其他模块中我们就可以导入, 使用这些导出的属性

// 导入require函数返回的是一个对象
    const foo = require("./foo.js")
    
    console.log(foo) // { NAME: 'kaisa', age: 18, sayHello: [Function: sayHello] }
    console.log(foo.NAME) // kaisa
    console.log(foo.age) // 18
    foo.sayHello() // Hello kaisa

既然require函数返回的是一个对象, 那么我们导入的时候, 是可以直接对对象进行结构的, 这也是开发中常用写法, 如下:

// 导入的同时进行解构
    const {
         NAME, age, sayHello } = require("./foo.js")
    
    console.log(NAME) // kaisa
    console.log(age) // 18
    sayHello() // Hello kaisa

node中运行结果

![在这里插入图片描述][635b37222c104344bab4f5c5593159d7.png_pic_center]

**注意: 案例实在node中运行的, 浏览器中不可运行, 浏览器并没有实现CommonJS**

#### exports和require本质 ####

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

// 向exports对象上添加多个属性, 并且添加的属性会被导出
    exports.name = name;
    exports.age = age;
    exports.sayHello = sayHello;

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

const foo = require("./foo.js")

**上面这行完成了什么操作呢？理解下面这句话，Node中的模块化一目了然**

*  **意味着main中的foo变量等于exports对象；**
 *  **也就是require通过各种查找方式，最终找到了exports这个对象, 并且将这个exports对象赋值给了foo变量；**
 *  **此时foo变量就是exports对象了, 或者说, foo和exports在栈内存中保存的是同一个堆内存中的地址, 也就是指向同一个对象；**

#### module.exports导出 ####

**在实际开发中, 我们并不是使用exports导出的**

**Node中我们经常导出东西的时候，又是通过module.exports导出的**：

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

**但是，为什么exports也可以导出呢？**

*  这是因为module对象的exports属性是exports对象的一个引用；
 *  也就是说 module.exports = exports = require函数的返回值；

**所以本质上module.exports和exports指向的是同一个对象**

const NAME = "kaisa"
    let age = 18
    
    function sayHello() {
        
      console.log("Hello" + " " + NAME)
    }
    
    // 通过导出module.exports导出
    module.exports.NAME = NAME
    module.exports.age = age
    module.exports.sayHello = sayHello

// 再导入
    const {
         NAME, age, sayHello } = require("./foo.js")
    
    console.log(NAME) // kaisa
    console.log(age) // 18
    sayHello() // Hello kaisa

但是大家一定很好奇, 这样做的意义是什么呢? 不用纠结并没有意义, 这也不是我们开发中的写法, 开发中的写法如下

*  创建一个新的对象导出

const NAME = "kaisa"
    let age = 18
    
    function sayHello() {
        
      console.log("Hello" + " " + NAME)
    }
    
    // 导出创建一个新的对象
    module.exports = {
        
      // 对象的增强写法
      NAME,
      age,
      sayHello
    }

**此时module.exports不再引用exports对象了，那么修改export就没有意义了？**

#### require细节 ####

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

**那么，require的查找规则是怎么样的呢？**

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

**情况一：X是一个Node核心模块(内置模块)，比如path、http**

*  直接返回内置模块，并且停止查找

const path = require("path")
    const http = require("http")

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

**第一步：将X当做一个文件在对应的目录下查找；**

1.如果**有x后缀名，按照后缀名的格式查找对应的文件**

2.如果没有后缀名，会按照如下顺序：

*  直接查找文件X
 *  查找X.js文件
 *  查找X.json文件
 *  查找X.node文件

**第二步：没有找到对应的文件，将X作为一个目录**

查找目录下面的index文件

*  查找X/index.js文件
 *  查找X/index.json文件
 *  查找X/index.node文件

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

**情况三：直接是一个X（并不是路径），并且X不是一个核心模块**

**那么会去node\_modules文件夹中去寻找**

例如我们直接导入一个不存在的, 那么一定是会报错的

const aaa = require("aaa")
    console.log(aaa) // 报错

但是, 如果我们创建一个node\_modules文件夹, 并且在文件夹中创建一个aaa文件夹, 在aaa中在创建一个index.js, 那么就不会报错, 并且执行这个index.js

![在这里插入图片描述][e7e9acf1e33346a0a82ce6f38f3b6d0d.png_pic_center]

// 再导入不会报错, 并且执行
    const aaa = require("aaa") // aaa中index执行了

**如果当前文件夹没找到node\_modules文件夹, 就会去上层文件夹找, 一层一层的寻找, 以此类推, 找不到就会报错**

#### 模块的加载过程 ####

**结论一：模块在被第一次引入时，模块中的js代码会被运行一次**

**结论二：模块被多次引入时，会缓存，最终只加载（运行）一次**

*  为什么只会加载运行一次呢？
 *  这是因为每个模块对象module都有一个属性：loaded。
 *  为false表示还没有加载，为true表示已经加载；

**结论三：如果有循环引入，那么加载顺序是什么？**

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

*  这个其实是一种数据结构：图结构；
 *  图结构在遍历的过程中，有深度优先搜索（DFS, depth first search）和广度优先搜索（BFS, breadth first search）；
 *  **Node采用的是深度优先算法**：main -> aaa -> ccc -> ddd -> eee ->bbb

![在这里插入图片描述][71dfef48f437412383a59e8030556e34.png_pic_center]

#### CommonJS规范缺点 ####

**CommonJS加载模块是同步的**:

*  同步的意味着只有等到对应的模块加载完毕，当前模块中的内容才能被运行；
 *  这个在服务器不会有什么问题，因为服务器加载的js文件都是本地文件，加载速度非常快；

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

*  浏览器加载js文件需要先从服务器将文件下载下来，之后再加载运行；
 *  那么采用同步的就意味着后续的js代码都无法正常运行，即使是一些简单的DOM操作；

**所以在浏览器中，我们通常不使用CommonJS规范**:

*  当然在webpack中使用CommonJS是另外一回事；
 *  因为它会将我们的代码转成浏览器可以直接执行的代码；
 *  在早期为了可以**在浏览器中使用模块化，通常会采用AMD或\*\*\*\*CMD**：
 *  但是目前一方面现代的浏览器已经支持ES Modules，另一方面借助于webpack等工具可以实现对CommonJS或者ES Module代码的转换；
 *  **AMD和CMD已经使用非常少了；**

[635b37222c104344bab4f5c5593159d7.png_pic_center]: https://img-blog.csdnimg.cn/635b37222c104344bab4f5c5593159d7.png#pic_center
[e7e9acf1e33346a0a82ce6f38f3b6d0d.png_pic_center]: https://img-blog.csdnimg.cn/e7e9acf1e33346a0a82ce6f38f3b6d0d.png#pic_center
[71dfef48f437412383a59e8030556e34.png_pic_center]: https://img-blog.csdnimg.cn/71dfef48f437412383a59e8030556e34.png#pic_center