Node模块化开发
1. 认识模块化开发
1.1 什么是模块化
- 模块化开发最终的目的是将程序划分成一个个小的结构
- 这个结构中编写属于自己的逻辑代码,有自己的作用域,定义变量名时不会影响到其他作用域
- 这个结构可以将自己希望暴露的变量,函数,对象等导出给其他结构使用
- 也可以通过某种方式,导入另外结构中的变量,函数,对象等
上面说到的结构,就是模块,按照这种结构划分开发程序的过程,就是模块化开发的过程
无论你多么喜欢JS,以及它现在发展有多好,它都有很多缺陷:
- 比如var定义的变量作用域问题
- 比如JS的面向对象并不能像常规面向对象语言一样使用class
- 比如JS没有模块化的问题
1.2 模块化的历史
ECMAScript没有推出来自己的模块化方案之前,社区有 CommonJS/AMD/CMD几种方案
ES6(ES2015)推出自己的模块化方案: ESModule
- 在网页开发的早期,Brendan Eich开发JavaScript仅仅作为一种脚本语言,做一些简单的表单验证或动画实现等,那个时候代码还是很少的:
- 这个时候我们只需要将JavaScript代码写到
<script>标签中即可; - 并没有必要放到多个文件中来编写;甚至流行:通常来说JavaScript程序的长度只有一行。
- 这个时候我们只需要将JavaScript代码写到
- 但是随着前端和JavaScript的快速发展,JavaScript代码变得越来越复杂了:
- ajax的出现,前后端开发分离,意味着后端返回数据后,我们需要通过JavaScript进行前端页面的渲染;
- SPA的出现,前端页面变得更加复杂:包括前端路由,状态管理等等一系列复杂的需求需要通过JavaScript来实现;
- 包括Node的实现,JavaScript编写复杂的后端程序,没有模块化是致命的硬伤;
- 所以,模块化已经是JavaScript一个非常迫切的需求:
- 但是JavaScript本身,直到ES6(2015)才推出了自己的模块化方案;
- 在此之前,为了让JavaScript支持模块化,涌现出了很多不同的模块化规范:AMD、CMD、CommonJS等;
1.3 没有模块化带来的问题
- 早期没有模块化带来了很多的问题:比如命名冲突的问题
- 当然,我们有办法可以解决上面的问题:立即函数调用表达式(IIFE)
- IlFE (lmmediately Invoked Function Expression)
- 但是,我们其实带来了新的问题:
- 第一,我必须记得每一个模块中返回对象的命名,才能在其他模块使用过程中正确的使用;
- 第二,代码写起来混乱不堪,每个文件中的代码都需要包裹在一个匿名函数中来编写;
- 第三,在没有合适的规范情况下,每个人、每个公司都可能会任意命名、甚至出现模块名称相同的情况;
- 所以,我们会发现,虽然实现了模块化,但是我们的实现过于简单,并且是没有规范的。
- 我们需要制定一定的规范来约束每个人都按照这个规范去编写模块化的代码;
- 这个规范中应该包括核心功能:模块本身可以导出暴露的属性,模块又可以导入自己需要的属性;
- JavaScript社区为了解决上面的问题,涌现出一系列好用的规范,接下来我们就学习具有代表性的一些规范。
2. CommonJS和Node
2.1 CommonJS规范和Node关系
-
我们需要知道CommonJS是一个规范,最初提出来是在浏览器以外的地方使用,并且当时被命名为ServerJS,后来为了体现它的广泛性,修改为CommonJS,平时我们也会简称为CJS。
- Node是CommonJS在服务器端一个具有代表性的实现;
- Browserify是CommonJS在浏览器中的一种实现;
- webpack打包工具具备对CommonJS的支持和转换;
-
CommonJS规范
- 模块中要导出内容:exports
- 模块中要导入内容:require
-
所以,Node中对CommonJS进行了支持和实现,让我们在开发node的过程中可以方便的进行模块化开发:
- 在Node中每一个js文件都是一个单独的模块;
- 这个模块中包括CommonJS规范的核心变量:exports、module.exports、require;
- 我们可以使用这些变量来方便的进行模块化开发;
-
前面我们提到过模块化的核心是导出和导入,Node中对其进行了实现:
- exports和module.exports可以负责对模块中的内容进行导出;
- require函数可以帮助我们导入其他模块(自定义模块、系统模块、第三方库模块)中的内容;
2.2 exports导出
注意:exports是一个对象,我们可以在这个对象中添加很多个属性,添加的属性会导出;
exports.name = name
exports.age = age
exports.sayHello = sayHello
另外一个文件中可以导入:const bar = require('./bar');
上面这行完成了什么操作呢?理解下面这句话:
- 意味着main中的bar变量等于exports对象
- 也就是require通过各种查找方式,最终找到了exports这个对象
- 并且将这个exports对象赋值给了bar变量
- bar变量就是exports对象了
2.3 module.exports导出
-
但是Node中我们经常导出东西的时候,又是通过module.exports导出的:
- module.exports和exports有什么关系或者区别呢?
-
我们追根溯源,通过维基百科中对CommonJS规范的解析:
- CommonJS中是没有module.exports的概念的;
- 但是为了实现模块的导出,Node中使用的是Module的类,每一个模块都是Module的一个实例,也就是module;
- 所以在Node中真正用于导出的其实根本不是exports,而是module.exports;
- 因为module才是导出的真正实现者;
-
但是,为什么exports也可以导出呢?
- 这是因为module对象的exports属性是exports对象的一个引用;
- 也就是说module.exports= exports=main中的bar;
-
开发中常见的写法
module.exports = {
name,
age,
sayHello
}
这里module.exports不再引用exports对象了,那么修改export就没有意义了
2.4 require函数解析
2.4.1 require细节
我们现在已经知道,require是一个函数,可以帮助我们引入一个文件(模块)中导出的对象
- 那么,require的查找规则是怎么样的呢?
- 这里我总结比较常见的查找规则:
- 导入格式如下:require(X)
2.4.1.1 情况1 导入的是node提供的内置模块
- X是一个Node核心模块,比如path、http
- 直接返回核心模块,并且停止查找
// 情况1,导入的是node内置模块
const path = require("path")
const http = require("http")
console.log(path, http)
2.4.1.2 情况2 导入的是自定义的模块
X是以./或../或/(根目录)开头的
第一步:将X当做一个文件在对应的目录下查找;
-
1.如果有后缀名,按照后缀名的格式查找对应的文件
-
2.如果没有后缀名,会按照如下顺序: 1>直接查找文件X 2>查找Xjs文件 3>查找X.json文件 4>查找X.node文件
第二步:没有找到对应的文件,将X作为一个目录
-
查找目录下面的index文件 1>查找X/index.js文件 2>查找X/index.json文件 3>查找X/index.node文件
如果没有找到,那么报错:not found
// 情况2, 导入的是自己定义的模块
const {name, formatCount, formatDate} = require("./utils")
console.log(name)
console.log(formatDate())