乐趣区

关于node.js:nodejs端模块化方式comomjs详解

jiezi

nodejs 端实现模块化的形式通常是通过 commonjs，应用模块化能够复用 js 代码，使得逻辑构造更为清晰。

commonjs 的语法规定如下
通过 module.exports 或者 exports 导出，通过 require 函数来导入

// a.js 导出内容
const name = 'alice'
const age = 16
module.exports = {
  name,
  age
}

// b.js 导入
const obj = require('./a.js')
console.log(obj) // {name: 'alice', age: 16}

module.exports 和 exports 导出不同的书写形式

// a.js
const name = 'alice'
const age = 16
exports.age = age
module.exports.name = name

// b.js
const obj = require('./a.js')
console.log(obj) // {name: 'kiki', age: 16}

两者的不同之处在于，即便通过 exports.xxx 导出，其实最终也是通过 module.exports 这样的形式进行导出的，因为在 node 外部，初始化时先将一个空对象赋值给 exports，而后再将 exports 赋值给 module.exports，所以通过 exports.xxx 这样的模式就相当于在 module.exports 这个对象外面追加子元素

如果间接给 module.exports 赋值为一个新的对象，那么后果就不一样了

// a.js
const name = 'alice'
const age = 16
const hobby = 'singing'

exports.name = name
exports.age = age

module.exports = {hobby}

// b.js
const obj = require('./a.js')
console.log(obj) // {hobby: 'singing'}

从新将一个对象赋值给了 module.exports，module.exports 指向的内存空间曾经和 exports 不是同一个指向，所以最终的导出只有 module.exports 局部

为什么说是 exports 赋值给 module.exports 而不是反向赋值呢，一方面能够从源码中看到赋值的过程，另一方面扭转一下导出形式也能看到，如果 require 最终导入的内容由 exports 决定的话，那么此时输入应该为一个函数

// a.js
const sayHi = function(){console.log('hi')
}

exports = {sayHi}

// b.js
const obj = require('./a.js')
console.log(obj) // {}

此时只输入了一个空对象，所以说 require 的导出内容并不是 exports 而是 module.exports。
初始化的时候 exports 与 module.exports 都是指向了一个空对象的内存地址，当 exports 间接增加空对象的属性时，内存地址没有产生扭转，modulex.exports 能随着 exports 的赋值导出的内容发生变化。
然而这里当 exports 从新指向了另外的对象时，module.exports 还是指向原来的那个对象，module.exports 没有发生变化，所以导出的内容还是空对象。

理解完了 导出 这一部分，咱们来看看 require 导入，通过 require 来查找资源时，会有如下规定

1、导入是内置模块，比方 fs、http, 此时就会间接查找内置的模块
2、导入的模块蕴含门路, 比方 ./ 或 ../ 或 /
    ./ 示意以后门路，../ 示意上一层门路，/ 示意电脑的根目录
    如果有门路时，就会依照门路去查找
    此时分为两种状况，一种是当成文件，一种是文件夹
    (1) 文件
         如果文件写了后缀名，就会查找有该后缀名的文件，如果没有后缀名，就会依照 文件 / 文件.js / 文件.json/ 文件.node 的秩序查找
    (2) 文件夹
        顺次找查找文件夹的 index.js / index.json / index.node 
    如果通过门路没有找到，则会报错 Not Find
3、导出既不是内置模块也没有门路
    那么会从当前目录的 node_modules 开始，一层一层往上查找有没有对应的导入文件，如果没有找到 则报错 Not Find

那么 require 的模块加载过程是怎么样的呢~
首先来说, 只有应用了 require 函数来加载资源，肯定会被执行一次

// a.js
let name = 'kiki'
exports.name = name
console.log('a.js 文件被执行')

// b.js
require('./a.js')
// a.js 文件被执行

如果多个文件都导入同一个文件，也并不会让该文件屡次加载，在 module 内有一个 loaded 字段，来判断该资源是否被加载。
下图在 b.js 中打印的 module，能够看到子元素 a.js 文件的 loaded 曾经变成了 true，因为打印语句在 require 之后，而 commonjs 是同步执行，所以 a.js 曾经被加载实现，而打印的时候 b.js 还没有加载实现，所以 loaded 为 false

如果屡次循环调用也不须要放心，如果呈现了以下嵌套调用的状况，会依照深度优先算法来对文件进行执行。

首先从 main 对应的第一个顶点开始，一层一层往下找，找到底了之后，再往上一层查找，把上一层的元素查找完之后，再往上一层查找，也就是 main–>aaa–>ccc–>ddd—>eee。
此时 eee 没有指向的顶点，就退回到 ddd，ddd 除了 eee 也没有指向的顶点，再退回到 ccc，依此类推，始终退到 main，发现 main 还指向了另外一个顶点 bbb，所以执行 bbb，bbb 指向 ccc 和 eee，但因为这两个曾经加载过，所以不会从新加载，最初的执行程序为

main aaa ccc ddd eee bbb

此外，commonjs 的执行还有几个特点
1、同步加载，每次执行 js 代码都是须要将 js 文件下载下来，服务端解决文件通常都是执行本地文件，不会对性能造成很大的影响，然而如果用于浏览器端，同步执行代码就会对后续的 js 执行造成阻塞，使加载资源的工夫变得更长，所以 commonjs 大多都被用在服务端。

// a.js
let name = 'kiki'
exports.name = name
console.log('a.js 文件被执行')

// b.js
require('./a.js')
console.log('b.js 文件被执行') // a.js 文件被执行 b.js 文件被执行

2、运行时解析，这里就要说到 v8 引擎的执行流程，简略来说 js 的执行须要通过两个阶段，首先须要将 javascript 代码解析成字节码，而后再通过编译器执行，运行时解析就象征当函数调用之后，才会执行 commonjs 的代码，导入导出就能够应用一些条件判断语句或者动静的门路

// a.js
let name = 'kiki'
module.exports = {name}

// b.js
const path = './a.js'
const flag = true
if(flag){const { name} = require(path)
  console.log(name) // kiki
}

3、module.exports 与 require 的是同一个对象，也就是说如果间接更改 module.exports.xxx 的时候，require 的内容也会产生更改，批改 require，module.exports 的内容也会变动，上面演示一下批改导出的内容

// a.js
let name = 'kiki'

setTimeout(()=>{module.exports.name = 'hi'},1000)

module.exports = {name}

// b.js
const obj = require('./a.js')
console.log(obj)

setTimeout(()=>{console.log(obj)
}, 2000)

// 执行程序为 {name: 'kiki'} {name: 'hi'}

以上就是 commonjs 在 nodejs 中的应用详解，commonjs 是 node 实现模块化中十分重要的一部分内容，把它了解透能力更好的利用~
下一篇会介绍在浏览器端罕用的模块化形式 es module

退出移动版