Node.js_node.js의 모듈 메커니즘에 대한 연구 노트

Javascript가 탄생한 이후 누구도 Javascript를 프로그래밍 언어로 여기지 않았습니다. 웹 1.0 시대에 이 스크립팅 언어는 주로 양식 유효성 검사 및 웹 페이지 특수 효과에 사용되었습니다. 웹 2.0 시대가 되어서야 프론트엔드 엔지니어들이 웹 페이지의 사용자 경험을 크게 향상시키기 위해 JS를 사용했습니다. JS는 널리 평가되었습니다. JS가 점점 대중화되면서 도구 라이브러리, 구성 요소 라이브러리, 프런트엔드 프레임워크 및 프런트엔드 애플리케이션이 대략적으로 변경되었습니다. Javascript에는 본질적으로 모듈이라는 한 가지 기능이 부족하며 CommonJS 사양의 등장으로 이러한 단점이 보완되었습니다. 이 기사에서는 CommonJS 사양과 Node의 모듈 메커니즘을 소개합니다.

다른 고급 언어 중에서 Java에는 클래스 파일이 있고, Python에는 가져오기 메커니즘이 있으며, PHP에는 포함 및 요구 사항이 있습니다. JS가 태그를 통해 코드를 도입하는 방식은 지저분해 보입니다. 과거에는 사람들이 코드를 인위적으로 제한하기 위해 네임스페이스와 기타 방법을 사용해야 했습니다. CommonJS 사양이 등장하고 나서야 프런트엔드와 백엔드 Javascript가 통합될 수 있었습니다. Node는 CommonJS의 모듈 사양을 활용하여 매우 사용하기 쉬운 모듈 시스템을 구현합니다.

1. CommonJS 모듈 사양

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

1) 참조: require() 메서드를 통해 모듈의 API를 현재 컨텍스트에 도입하고 var math = require('math'); 2).모듈 정의: 내보내기 개체를 통해 현재 모듈의 메서드나 변수를 내보냅니다. 모듈에는 모듈 개체도 있으며 내보내기는 실제로 모듈의 속성입니다. Node에서 파일은 모듈이며 모듈 내의 "전역 변수"는 외부 세계에 표시되지 않습니다. = 3.1415926; 3) 모듈 식별: 실제로는 위의 'math'와 같이 require()에 전달되는 매개변수이며, 이는 낙타 명명법을 준수하는 문자열이거나 ".."로 시작하는 상대 경로여야 합니다. 또는 절대 경로, 파일 이름 접미사 ".js"를 가질 수 없습니다.

2. 노드 모듈 구현 과정

Node에서 모듈은 두 가지 범주로 나누어집니다. 하나는 Node 자체에서 제공하는 핵심 모듈이고, 다른 하나는 사용자가 작성한 파일 모듈입니다. Node 소스 코드를 컴파일하는 동안 코어 모듈의 일부가 바이너리 파일로 컴파일됩니다. 코어 모듈은 Node가 시작될 때 메모리에 직접 로드되므로 로딩 속도가 가장 빠릅니다. 파일 모듈은 런타임 시 동적으로 로드되며 경로 분석, 파일 위치, 컴파일 및 실행의 세 단계가 필요합니다. Node는 2차 도입 비용을 줄이기 위해 가져온 모듈을 캐시하고, 동일한 모듈의 2차 로딩에 대해 우선순위가 가장 높은 캐시에서 로딩하는 전략을 채택합니다.

2.1 경로 분석

경로 분석은 위에서 언급한 모듈 식별자를 주로 분석하며, 크게 다음과 같은 카테고리로 나뉩니다.

1) http, fs, path 등 핵심 모듈 2) .. 로 시작하는 상대 경로 파일 모듈 3) / 로 시작하는 절대 경로 파일 모듈 4) 파일 또는 패키지 형태일 수 있는 사용자 정의 파일 모듈. 노드는 모듈 경로 배열 module.paths에 따라 대상 파일을 하나씩 찾으려고 시도합니다. 일반적으로 루트 디렉터리까지 현재 디렉터리를 따라 node_modules라는 디렉터리를 단계별로 검색하므로 이 방법이 가장 시간이 많이 걸립니다. 그것을 찾기 위해.

2.2 파일 위치 지정

경로 분석을 기반으로 파일 위치는 다음 세부 사항에 주의해야 합니다.

1) 파일 확장자 분석: CommonJS 사양에서는 모듈 식별자가 확장자를 채우지 않도록 허용하므로 Node에서는 .js, .json, .node 순으로 확장자를 채우고 순차적으로 시도합니다 2) 디렉토리 분석 및 패키지 : 위 파일 확장자 분석 후 해당 파일은 발견되지 않았으나 디렉토리를 획득한 경우 Node는 해당 디렉토리를 패키지로 처리합니다

2.3 컴파일 및 실행

특정 파일을 찾은 후 Node는 새 모듈 객체를 생성하고 경로에 따라 로드하고 컴파일합니다. 확장 프로그램마다 로딩 방법이 다릅니다:

1), .js 파일 : fs 모듈을 통해 동기적으로 파일을 읽고 컴파일하고 실행합니다 2).node 파일: C/C로 작성되고 dlopen() 메소드를 통해 로드되는 확장 파일입니다 3).json 파일: fs 모듈을 통해 동기적으로 파일을 읽고 JSON.parse()를 사용하여 결과를 구문 분석하고 반환합니다 4) 기타 확장 파일: .js 파일로 로드됩니다

우리는 기본적으로 각 모듈 파일에 require, imports, module이라는 세 가지 변수가 있다는 것을 알고 있습니다. Node의 API 문서에서도 각 모듈에는 filename과 dirname이라는 두 가지 변수가 있다는 것을 알고 있습니다. Node의 모듈은 선언된 "전역 변수"가 실제로 다른 모듈을 오염시키지 않도록 어떻게 보장합니까? 실제로 Node는 JS 모듈을 컴파일하는 동안 파일 내용의 헤드와 테일을 래핑합니다. 다음은 헤드 및 테일 패키징이 포함된 JS 파일의 예입니다.

코드 복사 코드는 다음과 같습니다. (함수(내보내기, 요구, 모듈, __filename, __dirname) { /* 가운데가 JS 파일의 실제 내용입니다 */ var 수학 = require('math'); 수출.지역 = 함수(반경) { Math.PI * 반경 * 반경을 반환합니다. }; /* JS 파일의 실제 내용이 끝납니다 */ }); 이런 방식으로 각 모듈 파일은 범위가 격리되고 require, 내보내기, 모듈과 같은 변수도 모듈 컨텍스트에 주입됩니다. 이는 CommonJS 모듈 사양의 Node 구현입니다. C/C 모듈과 Node 코어 모듈의 컴파일 과정은 비교적 복잡하므로 자세히 설명하지 않습니다.

3. 모듈 호출 스택

아래 그림과 같이 Node에서 다양한 모듈의 호출 관계를 명확히 할 필요가 있습니다.

C/C 내장 모듈은 최하위 모듈로 핵심 모듈로 주로 자바스크립트 핵심 모듈과 타사 자바스크립트 파일 모듈을 호출할 수 있는 API를 제공합니다. Javascript 핵심 모듈에는 두 가지 주요 책임이 있습니다. 하나는 파일 모듈 호출을 위한 C/C 내장 모듈의 캡슐화 계층 및 브리징 계층 역할을 하는 것이고, 다른 하나는 다음을 처리할 필요가 없는 순전히 기능적인 모듈입니다. 하단 레이어. 파일 모듈은 일반적으로 일반 Javascript 모듈 및 C/C 확장 모듈을 포함하여 제3자가 작성합니다.

4. 패키지와 NPM

4.1 패키지 구조

패키지는 기본적으로 아카이브 파일(일반적으로 .zip 또는 .tar.gz)이며, 설치 후 압축을 풀고 디렉터리에 복원할 수 있습니다. CommonJS의 패키지 사양은 패키지 구조와 패키지 설명 파일의 두 부분으로 구성됩니다. CommonJS 사양을 완전히 준수하는 패키지 구조에는 다음 파일이 포함되어야 합니다.

1).package.json: 패키지 설명 파일 2).bin : 실행 가능한 바이너리 파일이 저장되는 디렉터리 3).lib: 자바스크립트 코드를 저장할 디렉터리 4).doc: 문서 저장 디렉터리 5).test: 단위 테스트 케이스를 저장하는 디렉토리

4.2 패키지 설명 파일

패키지 설명 파일은 패키지의 루트 디렉터리에 위치한 JSON 파일(package.json)로, 패키지의 중요한 부분으로, 패키지의 일반적인 정보를 설명하는 데 사용됩니다. 나중에 언급할 NPM의 모든 동작은 이 파일의 필드와 밀접하게 관련되어 있습니다. 다음은 잘 알려진 웹 프레임워크 익스프레스 프로젝트의 package.json 파일을 예로 사용하여 일부 공통 필드의 의미를 보여줍니다.

1).name: 패키지 이름 2).description : 패키지 소개 3).version : "의미론적 버전 관리"를 준수해야 하는 버전 번호, http://semver.org/ 참조 4).dependents: 현재 패키지를 사용하는데 필요한 패키지 목록입니다. 이 속성은 매우 중요합니다. NPM은 이 속성을 통해 종속 패키지를 자동으로 로드합니다 5).repositories: 소스코드가 호스팅되는 위치 목록

다른 필드의 사용법은 NPM package.json 설명을 참조하세요

4.3 NPM 공통 기능

NPM(노드 패키지 관리자), 일반적으로 노드 패키지 관리자라고 합니다. 주요 기능은 설치, 제거, 업데이트, 보기, 검색, 릴리스 등을 포함한 노드 패키지를 관리하는 것입니다.

4.3.1 NPM 패키지 설치

Node 패키지 설치에는 로컬 설치와 전역 설치의 두 가지 유형이 있습니다. 둘의 차이점은 다음과 같습니다.

1) 로컬 설치 npm install : 패키지가 현재 디렉터리에 다운로드되며 현재 디렉터리에서만 사용할 수 있습니다. 2) 전역 설치 npm install -g : 패키지가 특정 시스템 디렉터리에 다운로드되며, 설치된 패키지는 모든 디렉터리에서 사용할 수 있습니다.

4.3.2 NPM 패키지 관리

다음은 grunt-cli(grunt 명령줄 도구)를 예로 들어 일반적으로 사용되는 패키지 관리 명령을 나열합니다.

1).npm install: package.json 파일의 dependency 및 devDependency 필드에 선언된 모든 패키지를 설치합니다. 2).npm install grunt-cli@0.1.9: 특정 버전의 grunt-cli 설치 3).npm install grunt-contrib-copy --save: grunt-contrib-copy를 설치하고 package.json 파일에 대한 종속성을 저장합니다. 4).npm uninstall grunt-cli: 패키지 제거 5).npm 목록: 어떤 패키지가 설치되어 있는지 확인 6).npm 게시 : 패키지 게시