javascript存在的缺点javascript
CommonJS规范的提出,弥补了javascript没有标准的缺陷,以达到像Python、Ruby、Java具有的开发大型应用的基础能力,这样javascript不单单能在客户端应用还能开发如下应用:java
使用require()来引入 ,接受一个模块标识。node
let math = require('math');
上下文提供里exports对象用于导出模块或变量,而且是惟一导出出口。在模块中存在一个module对象,表明模块自身,exports是它的一个属性。在nodejs中一个文件就是一个模块,把方法挂在exports对象上做为属性便可定义导出json
//math.js exports.add = function(){ let sum = 0, i = 0, args = arguments, l = args.length; while(i < l) { sum += args[i ++]; } return sum; }
在另外一个文件require使用windows
const math = require('./math'); let res = math.add(1, 2, 3); console.log(res) //6
模块标识为require()的参数必须是符合小驼峰命名的字符串,或以.、..开头的相对路径,或绝对路径,能够是没有.js后缀的js文件。
模块中定义的全局变量只做用于该文件内部,不污染其余模块。后端
Node中引入模块需经历如下步骤:缓存
Node中模块分为两类: 1.Node提供的 "核心模块",2.用户编写的 "文件模块"。
核心模块Node源码编译时已经编译成二进制执行文件,Node启动时直接加载进内存中,不须要文件定位和编译执行两个步骤,且在路径分析中优先判断,加载速度最快。工具
Node会对引入过的模块进行缓存,核心模块和文件模块相同的模块在二次加载时一概从缓存优先加载(第一优先级),核心模块缓存检测优先于文件模块缓存检测。单元测试
标识符分类:测试
console.log(module.paths) //[ 'c:\\Users\\maikuraki\\Desktop\\nodejs\\node_modules', 'c:\\Users\\maikuraki\\Desktop\\node_modules', 'c:\\Users\\maikuraki\\node_modules', 'c:\\Users\\node_modules', 'c:\\node_modules' ]
Node会逐个路径尝试知道找到目标文件,模块路径越深耗时越多。
标识符能够不包含文件扩展,这种状况下Node会安装.js、.json、.node次序补全扩展名。
若是是个包Node会检测里面的package.json文件Node经过JOSN.parse()解析出包的描述对象去除main属性指向的文件进行定位,若是没有该属性默认查找index.js、index.json、index.node。
在Node中每一个文件模块都是一个对象。
编译和执行是引入文件模块的最后一个阶段,定位到一个文件后,Node会新建一个模块对象,而后根据路径载入并编译。不一样扩展名载入方式:
在编译过程当中Node对获取的javascript文件进行的头尾包装
(function(exports, require, module, __filename, __dirname) { exports.add = (x, y) => { return x + y; } })
这样每一个模块文件直接都进行了做用域隔离,这就是Node对CommonJS规范的实现。
Node调用process.dlopen()来进行加载执行,windows和*nix平台下dlopen()经过不一样方式实现,经过libuv兼容层进行封装。
Node使用fs模块读取json文件内容,使用JSON.parse()获得对象而后给他赋给模块对象的exports属性。
核心模块分为C/C++编写和javascript编写,C/C++存放在Node项目的src文件下,javascript文件存在lib目录下。
核心模块中有些模块核心部分使用C/C++完成其余使用javascript实现包装导出。由纯C/C++编写的部分称为内建模块,例:buffer、crypto、evals、fs、os等模块部分使用C/C++编写。
依赖层关系: 内建模块(C/C++) ---> 核心模块(javascript)---> 文件模块
核心模块的引入流程
以os原生模块引入为例
NODE_MODULE(node_os,reg_func) ---> get_builtin_module('node_os') ---> process.binding('os') ---> NativeModule.require('os') ---> require('os')
Windows
C/C++源码 ---> VC++ --编译源码--> .dll文件 --生成.node文件--> 加载.dll文件 --dlopen()加载--> 导出给javascript使用
*nix
C/C++源码 ---> g++/gcc --编译源码--> .so文件 --生成.node文件--> 加载.so文件 --dlopen()加载--> 导出给javascript使用
require()引入.node文件过程
javascript(require('./hello.node')) ---> 原生模块(process.dlopen('./hello.node',exports)) ---> libuv(uv_dlopen()/uv_dlsym()) ---> [{*nix: dlopen()/dlsym(), Windows : loadLibraryExW()/GetProcAddress()}]
包结构:
AMD规范是CommonJS规范的一个延伸,定义模块方法:
define(id?, dependencies?, factory); define(function() { let exports = {}; exports.sayHello = () => { console.log(`hello form module: ${module.id}`); } return exports; })
CMD与AMD规范的主要区别在于定义模块和依赖引入的部分。AMD须要在声明的时候指定全部依赖,经过形参传递依赖到模块中:
define(['dep1', 'dep2'], function() { return function() {} })
于AMD规范相比,CMD模块更接近与Node对CommonJS规范的定义:
define(factory);
在依赖部分,CMD支持动态引入:
define(function(require, exports, module) { // module code })
require,exports,module经过形参传递给模块,在须要依赖模块时随时调用require()引入。
兼容多种模块规范
((name, definition) => { //检测是否为AMD或者CMD let hasDefine = typeof define === 'function', //检测是否为Node hasExports = typeof module !== 'undefined' && 'module.exports'; if(hasDefine) { //AMD或CMD环境 define(definition); }else if(hasExports) { //定义为普通Node模块 module.exports = definition(); }else { //将模块执行结果挂载在window对象下 this[name] = definition; } })('hello', function() { let hello = () => {}; return helllo; })