在CommonJS没有被提出之前，
JavaScript一直使用的是官方规范 ECMAScript，
但是JavaScript在实际环境中，表现能力始终都取决于宿主环境对API的支持程度
在缓慢の进化过程中的JS酱，常常因为这些原因被后端开发拒之门外：

• 没有模块系统
• 标准库较少
• 没有标准接口
• 缺乏包管理系统

但是在引入CommonJS之后，JS酱终于具备了跨宿主环境执行的能力。
于是除了客户端应用，JavaScript此后还能开发以下应用：

• 服务器端JavaScript应用程序
• 命令行工具
• 桌面图形界面应用程序
• 混合应用

• 浏览器： HTML、 CSS 、 JavaScript 的运行环境
• W3C： 对 BOM 和 DOM 进行规范化
• ECMAScript： 对 JavaScript 进行规范化
• CommonJS： 对 JavaScript 进行脱离宿主环境规范化
• Node： 同时兼容 ECMAScript 和 CommonJS 规范的js服务器端语言

下面这行代码就好像叫你的下属 Node酱 给你找一份叫做 myModule 的东西出份材料：

1

let myModule = require('myModule')

和大多数被Boss搞蒙圈的社畜一样，Node酱一上来就是三个问题：

1. 路径分析
   Node：我上哪去取这个东西呢？
2. 文件定位
   Node：你说的这个myModule，它是个什么东西？
3. 编译执行
   Node：我怎么用这个东西出材料呢？

• 核心模块
  • Node提供
  • 静态内存加载
  • 速度快
• 文件模块
  • 用户编写
  • 动态加载
  • 速度慢

Node会对引入过的模块进行缓存，以减少二次引入时的开销

浏览器缓存策略也差不多：

• 浏览器：缓存文件
• Node：缓存编译和执行之后的对象

优先级遵循两个顺序：

• 缓存优先
  • 教科书式废话，要不然干嘛引入缓存策略
• 核心模块优先于文件模块

把这两个原则缝合一下就得出了完整的缓存优先级排序：

缓存核心模块 > 缓存文件模块 > 核心模块 > 文件模块

Node:我上哪去取呢（挠头）？

1

let myModule = require('./myModule')

万物可对象，每个文件模块也是作为对象包装的：

1
2
3
4
5
6
7
8
9
10
11
12

function Module(id, parent){ 
    this.id = id
    this.exports = {}
    this.parent = parent
    if (parent && parent.children) {
        // parent喜当爹
        parent.children.push(this) 
    }
    this.filename = null
    this.loaded = false
    this.children = [] 
}

万物可对象(这话好像刚才说过)，连编译载入的方法也被作为对象包装在require中：

不同文件的加载方式放在了 require.extensions 中

1

console.log(require.extensions);

输出结果：

1
2
3
4
5

{
  '.js': [Function (anonymous)],
  '.json': [Function (anonymous)],
  '.node': [Function (anonymous)]
}

也可以通过对 require.extensions 的扩展来实现自定义扩展名文件的加载：

1
2
3

require.extensions['.duck'] = function(module, filename){
 // 加载.duck文件   
}

1
2
3
4
5
6

(function (exports, require, module, __filename, __dirname){ //包装头
    let math = require('math');
    exports.area = function (radius){
        return Math.PI * radius * radius;
    }
}); // 包装尾

• C/C++文件
  • 放在src目录下
• JavaScript文件
  • 放在lib目录下（lib/*.js）
  • src目录下的node.js（src/node.js）

• 单一模式
  • 全部由C/C++编写
• 复合模式
  • C++实现核心部分
  • JavaScript实现封装
  • Node提高性能的常用模式

由 纯C/C++ 编写的部分又称为 内建模块，

1
2
3
4
5
6
7
8

struct node_module_struct {
    int version;
    void *dso_handle;
    const char *filename;
    // 模块的具体初始化方法
    void (*register_func) (v8::Handle<v8::Object> target);
    const char *modname;
}

1
2
3
4
5
6
7
8
9

#define NODE_MODULE(modename, regfunc)
    extern "C" {
        NODE_MODULE_EXPORT node::node_module_struct modname ## _module = 
        {
            NODE_STANDARD_MODULE_STUFF,
            regfunc,
            NODE_STRINGIFY(modename)
        }
    }

1

exports = Object::New();

1

modp = get_builtin_module(*module_v);

1

modp->register_func(exports);

1

binding_cache->Set(module, exports);

1

NativeModule._source = process.binding('natives');

之前提到C/C++扩展模块会预先编译为 .node 文件，
这就存在一个问题，就是这个 .node 后缀只是个包装，
包装之下的内容实际如下：

• windows系统下是 .dll
• *nix系统下是 .so

dlopen方法实际上对两种文件分别进行处理。

• 核心模块
  • C/C++内建模块：最底层的模块
  • JavaScript模块：
    • 作为内建模块的 封装层和桥阶层
    • 供文件模块调用
• 文件模块
  • C/C++扩展模块
  • JavaScript模块：纯粹功能模块

包和NPM就是将模块联系起来的一种机制，

就像是将不同生物联系到一起的食物链

CommonJS包规范规定包由两个部分组成：

• 包描述文件
• 包结构文件

• package.json 包描述文件
• lib 可执行二进制文件目录
• bin JavaScript文件目录
• doc 文档目录
• test 单元测试用例目录

package.json位于包的根目录下，
CommonJS为其定义了一些描述字段：

与搭建镜像站方式几乎一样，
附录D待补充

安全检查的难点主要在于 C/C++扩展模块，

对于模块安全的检查，Isaac Z. Schlueter 提出了一个有趣的词：Kwalitee

“Kwalitee” is something that looks like quality, sounds like quality,
but is not quite quality.

意思就是很多模块表面看上去很优质，但也不一定真正是高质量模块。

比较常用的考查点可以参考下面这些：

• 覆盖率较高的测试模块
• 文档
• 编码规范