Node의 모듈 구현 프로세스에 대한 자세한 소개(예제 포함)

이 기사는 Node의 모듈 구현 프로세스에 대한 자세한 소개를 제공합니다(예제 포함). 도움이 필요한 친구들이 참고할 수 있기를 바랍니다.

CommonJS는 모듈을 정의하고, 모듈 사양을 내보내고 요구합니다. 이 간단한 표준을 구현하기 위해 Node.js는 기본 C/C++ 내장 모듈부터 JavaScript 핵심 모듈까지, 경로 분석부터, 컴파일 및 실행에 대한 파일 위치 지정. Node 모듈의 원리를 간단히 이해하면 Node 기반 프레임워크를 다시 이해하는 데 도움이 됩니다.

1. CommonJS 모듈 사양

CommonJS 사양 또는 표준은 JavaScript가 클라이언트 애플리케이션을 개발할 뿐만 아니라 실행되는 서버 애플리케이션 및 명령을 개발할 수 있는 기능을 갖기를 기대합니다. 도구, 데스크탑 그래픽 인터페이스 애플리케이션 등

CommonJS 사양의 모듈 정의는 세 부분으로 나뉩니다.

모듈 정의

모듈 개체는 모듈 자체를 나타내기 위해 모듈에 존재하며 내보내기 메서드를 정의할 수 있습니다. 내보내기 객체에 메소드를 마운트합니다. 예:

    // math.js
   exports.add = function(){ //...}

모듈 참조

모듈은 외부 모듈의 API를 현재 컨텍스트에 도입하는 require() 메소드를 제공합니다.

   var math = require('math')

모듈 식별은 실제로 require() 메소드에 전달되는 매개변수는 문자열이라는 이름의 카멜 케이스(camelCase)일 수 있으며 파일 경로일 수도 있습니다.

Node.js는 CommonJS 사양, 특히 CommonJS의 모듈 사양을 활용하여 모듈 시스템을 구현하는 동시에 NPM은 CommonJS 모듈의 패키지 사양을 구현하여 Node 애플리케이션 개발의 기초를 형성합니다.

2. Node 모듈 로딩 원리

위의 모듈 사양은 모듈, 내보내기 및 요구만으로 매우 간단해 보이지만 Node는 어떻게 구현됩니까?

경로 분석(모듈의 전체 경로), 파일 위치(파일 확장자 또는 디렉터리), 컴파일 및 실행의 세 단계를 거쳐야 합니다.

2.1 경로 분석

Review require()는 모듈 식별자를 매개변수로 받아 모듈을 소개합니다. 노드는 이 식별자를 기반으로 경로 분석을 수행합니다. 다양한 식별자는 다양한 분석 방법을 채택하며 주로 다음 범주로 나뉩니다.

http, fs, path와 같은 Node에서 제공하는 핵심 모듈

핵심 모듈은 Node 소스 코드가 컴파일될 때 바이너리 실행 파일로 저장됩니다. 시작 시 메모리에 직접 로드되며 경로 분석에 우선순위가 부여되므로 로딩 속도가 매우 빠르고 후속 파일 위치 지정, 컴파일 및 실행이 필요하지 않습니다.

사용자 정의 http 모듈과 같이 핵심 모듈과 동일한 이름을 가진 사용자 정의 모듈을 로드하려면 다른 식별자를 사용하거나 대신 경로를 사용해야 합니다.

경로, ., .. 상대 경로 모듈 및 /절대 경로 모듈 형식의 파일 모듈

., .. 또는 /로 시작하는 식별자는 파일 모듈로 처리되며 Node는 require()에서 경로를 변환합니다. 실제 경로를 인덱스로 사용하여 컴파일하고 실행합니다.

파일 모듈이 파일 위치를 명확히 하기 때문에 경로 분석 시간이 단축되고, 로딩 속도도 코어 모듈보다 느릴 뿐입니다.

사용자 지정 모듈, 즉 경로가 아닌 형식의 파일 모듈

은 핵심 모듈도 아니고 경로 형식의 파일 모듈도 아닙니다. 사용자 지정 파일은 경로를 검색할 때 모듈 경로를 단계별로 검색합니다. 길.
모듈 경로 검색 전략의 예는 다음과 같습니다.

// paths.js
console.log(module.paths)

// Terminal
$ node paths.js
[ '/Users/tong/WebstormProjects/testNode/node_modules',
'/Users/tong/WebstormProjects/node_modules',
'/Users/tong/node_modules',
'/Users/node_modules',
'/node_modules' ]

위 예의 모듈 경로 배열 출력에서 ​​볼 수 있듯이 모듈을 검색할 때 node_modules 디렉터리는 다음까지 현재 경로를 따라 레벨별로 검색됩니다. JS 프로토타입 체인 또는 범위 체인과 유사하게 대상 경로에 도달합니다. 경로가 깊을수록 속도가 느려지므로 사용자 정의 모듈이 가장 느리게 로드됩니다.

캐시 우선 순위 메커니즘: 노드는 가져온 모듈을 캐시하여 성능을 향상시킵니다. 파일을 캐시하는 브라우저와 달리 노드는 컴파일되고 실행된 객체를 캐시하므로 require()는 동일한 모듈을 다시 로드합니다. 이 캐시 우선순위는 코어 모듈의 우선순위보다 높은 첫 번째 우선순위입니다!

2.2 파일 위치

모듈 경로 분석이 완료되면 파일 위치 분석이 완료되는데, 여기에는 주로 파일 확장자 분석, 디렉터리 및 패키지 처리가 포함됩니다. 보다 명확하게 표현하기 위해 파일 위치 지정은 4단계로 나뉩니다.

1단계: 확장자 추가

보통 require()의 식별자에는 파일 확장자가 포함되지 않습니다. 이 경우 Node는 .js를 따릅니다. .json, .node 확장을 보완하기 위해.

확장을 추가하려고 할 때 fs 모듈을 호출하여 파일이 존재하는지 동기적으로 차단하고 확인해야 하므로 여기서 성능을 향상시키는 약간의 트릭은 .json 및 .node 파일을 require()에 전달할 때 확장을 추가하는 것입니다. , 그러면 프로세스 속도가 빨라집니다.

2단계: 디렉터리 처리 및 pakage.json 검색

확장을 추가한 후 해당 파일을 찾을 수 없지만 디렉터리를 얻은 경우 Node는 해당 디렉터리를 패키지로 처리합니다. CommonJS 패키지 사양의 구현에 따라 Node는 디렉터리에서 pakage.json(패키지 설명 파일)을 검색하고 JSON.parse()를 통해 패키지 설명 개체로 구문 분석한 다음 기본 속성에 지정된 파일 이름을 가져옵니다. .

3단계: 기본적으로 색인 파일 계속 검색

如果没有pakage.json或者main属性指定的文件名错误，那 Node 会将 index 当做默认文件名，依次查找 index.js、index.json、index.node

step4: 进入下一个模块路径

在上述目录分析过程中没有成功定位时，自定义模块按路径查找策略进入上一层node_modules目录，当整个模块路径数组遍历完毕后没有定位到文件，则会抛出查找失败异常。

缓存加载的优化策略使得二次引入不需要路径分析、文件定位、编译执行这些过程，而且核心模块也不需要文件定位的过程，这大大提高了再次加载模块时的效率

2.3 编译执行

Node 中每个模块都是一个对象，在具体定位到文件后，Node 会新建该模块对象，然后根据路径载入并编译。不同的文件扩展名载入方法为：

.js 文件: 通过 fs 模块同步读取后编译执行.json 文件: 通过 fs 模块同步读取后，用JSON.parse()解析并返回结果.node 文件: 这是用 C/C++ 写的扩展文件，通过process.dlopen()方法加载最后编译生成的其他扩展名: 都被当做 js 文件载入

载入成功后 Node 会调用具体的编译方式将文件执行后返回给调用者。对于 .json 文件的编译最简单，JSON.parse()解析得到对象后直接赋值给模块对象的exports，而 .node 文件是C/C++编译生成的，Node 直接调用process.dlopen()载入执行就可以，下面重点介绍 .js 文件的编译：

在 CommonJS 模块规范中有module、exports 和 require 这3个变量，在 Node API 文档中每个模块还有 __filename、__dirname这两个变量，但是在模块中没有定义这些变量，那它们是怎么产生的呢？

事实上在编译过程中，Node 对每个 JS 文件都被进行了封装，例如一个 JS 文件会被封装成如下：

(function (exports, require, module, __filename, __dirname) {
    var math = require('math')
    export.add = function(){ //... }
})

首先每个模块文件之间都进行了作用域隔离，通过vm原生模块的runInThisContext()方法（类似 eval）返回一个具体的 function 对象，最后将当前模块对象的exports属性、require()方法、模块对象本身module、文件定位时得到的完整路径__filename和文件目录__dirname作为参数传递给这个 function 执行。模块的exports属性上的任何方法和属性都可以被外部调用，其余的则不可被调用。

至此，module、exports 和 require的流程就介绍完了。

曾经困惑过，每个模块都可以使用exports的情况下，为什么还必须用module.exports。

这是因为exports在编译过程中时通过形参传入的，直接给exports形参赋值只改变形参的引用，不能改变作用域外的值，例如：

let change = function (exports) {
  exports = 100
  console.log(exports)
}

var exports = 2
change(exports) // 100
console.log(exports) // 2

所以直接赋值给module.exports对象就不会改变形参的引用了。

编译成功的模块会将文件路径作为索引缓存在 Module._cache 对象上，路径分析时优先查找缓存，提高二次引入的性能。

三、Node 核心模块

总结来说 Node 模块分为Node提供的核心模块和用户编写的文件模块。文件模块是在运行时动态加载，包括了上述完整的路径分析、文件定位、编译执行这些过程，核心模块在Node源码编译成可执行文件时存为二进制文件，直接加载在内存中，所以不用文件定位和编译执行。

核心模块分为 C/C++ 编写的和 JavaScript 编写的两部分，在编译所有 C/C++ 文件之前，编译程序需要将所有的 JavaScript 核心模块编译为 C/C++ 可执行代码，编译成功的则放在 NativeModule._cache对象上，显然和文件模块 Module._cache的缓存位置不同。

在核心模块中，有些模块由纯 C/C++ 编写的内建模块，主要提供 API 给 JavaScript 核心模块，通常不能被用户直接调用，而有些模块由  C/C++ 完成核心部分，而 JavaScript 实现封装和向外导出，如 buffer、fs、os 等。

所以在Node的模块类型中存在依赖层级关系：内建模块（C/C++）—> 核心模块（JavaScript）—> 文件模块。

使用require()十分的方便，但从 JavaScript 到 C/C++ 的过程十分复杂，总结来说需要经历 C/C++ 层面内建模块的定义、（JavaScript）核心模块的定义和引入以及（JavaScript）文件模块的引入。

四、前端模块规范

对比前后端的 JavaScript，浏览器端的 JavaScript 需要经历从同一个服务器端分发到多个客户端执行，通过网络加载代码，瓶颈在于宽带；而服务器端 JavaScript 相同代码需要多次执行，通过磁盘加载，瓶颈在于 CPU 和内存，所以前后端的 JavaScript 在 Http 两端的职责完全不用。

Node 模块的引入几乎是同步的，而前端模块如果同步引入，那脚本加载需要太长的时间，所以 CommonJS 为后端 JavaScript 制定的规范不适合前端。而后出现 AMD 和 CMD 用于前端应用场景。

4.1 AMD 规范

AMD 即异步模块定义（Asynchronous Module Definition）,模块定义为：

define(id?, dependencies?, factory);

AMD 模块需要用define明确定义一个模块，其中模块id与依赖dependencies是可选的，factory的内容就是实际代码的内容。例如指定一些依赖到模块中：

define(['dep1', 'dep2'], function(){
    // module code
});

require.js 实现 AMD 规范的模块化，感兴趣的可以查看 require.js 的文档。

4.2 CMD 规范

CMD 模块的定义更加简单：

 define(factory);

定义的模块同 Node 模块一样是隐式包装，在依赖部分支持动态引入，例如：

 define(function(require, exports, module){
     // module code
 });

require、exports、module通过形参传递给模块，需要依赖模块时直接使用require()引入。

sea.js 实现 AMD 规范的模块化，感兴趣的可以查看 sea.js 的文档。

위 내용은 Node의 모듈 구현 프로세스에 대한 자세한 소개(예제 포함)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!