[코드잇] 서드파티 모듈과 npm 제대로 배우기

1. Node.js에서 모듈이 검색되는 순서 

 

- 모듈의 이름은 어떤 파일의 이름일 수도 있고 디렉토리의 이름일 수도 있음

- require 인자에 경로 표시가 있는 문자열을 넣으면 노드는 그 경로에 파일이 있는지 찾음

- 만약에 있다면 그 파일을 그대로 로드 

- 없다면 같은 이름의 디렉토리가 있는지 찾음

- 만약에 있다면 그 디렉토리 안에서 package.json 이라는 파일이 있는지 찾음

- package.json 파일이 있다면 그 내용을 읽어서 그중에 main  필드를 찾음

- main 필드의 값으로는 어떤 파일 이름이 써 있음. 그 파일을 로드 

- package.json 파일이 없다면 디렉토리 안에서 index.js파일을 찾아서 로드 

 

- require 함수의 경로 표시 없이 모듈의 이름만 있는 경우 

- require 함수는 그것이 코어 모듈이거나 서드 파티 모듈이라고 판단

- 같은 이름의 코어 모듈이 존재한다면 그 코어 모듈을 그대로 로드 

- 같은 이름의 코어 모듈이 없다면 require 함수는 해당 모듈이 서드 파티 모듈이라고 판단

- 현재 디렉토리 안에 있는 node_modules 디렉토리를 찾음

- node_modules 디렉토리는 서드 파티 모듈들이 실제로 설치되는 디렉토리 

- node_moudles 디렉토리에서 같은 이름의 파일을 찾아서 있으면 로드 

- 없다면 같은 이름의 디렉토리를 찾음

 

- 서드 파티 모듈은 package.json 파일을 가진 디렉토리 형태로 존재 

 -> 서드 파티 모듈의 이름이 디렉토리 이름과 같음

 

 

2. package.json 파일을 가진 디렉토리가 패키지 

 

- 하나의 서드 파티 모듈을 설치하면 그것의 디펜던시들도 함께 설치됨

- package.json 파일을 가진 디렉토리를 패키지(packge)라고 함

- 모든 서드 파티 모듈이 하나의 패키지라는 뜻

- 서드 파티 모듈을 관리할 때 쓰는 npm은 node package maneger의 줄임말.

 

 

3. package.json 파일 간단히 살펴보기 

 

- package.json 파일은 해당 패키지에 관한 정보를 갖고 있는 파일 

- autor 필드에 패키지를 만든 사람의 이름과 이메일 정보가 들어 있음

- contributors 필드에 이 패키지를 만드는데 기여한 사람들의 정보가 있음

- dependencies 필드에 express 패키지가 필요로 하는 다른 패키지들의 이름과 버전 정보가 적혀 있음

- engines 필드는 express 패키지 안의 코드가 잘 실행되기 위한 노드의 버전 정보를 담고 있음

 

 

4. package.json 파일에서 알아야 할 필드 정리 

 

1) name

- 패키지의 이름 

 

2) version

- 패키지의 버전

- name 필드와 version 필드를 결합하면 특정 패키지의 특정 버전을 나타낼 수 있음

 

3) description

- 패키지에 대한 설명

- 패키지를 검색할 때 여기 있는 내용도 검색 기준으로 활용되기 때문에 자신의 패키지가 잘 검색되도록 하려면 여기에 앎자은 설명을 적어두는게 좋음 

 

4) keywords

- 패키지에 대한 키워드 

 

5) homeapage

- 패키지 관련 사이트의 URL

 

6) bugs

- 패키지를 사용하다가 발생하는 버그들을 신고할 수 있는 URL이나 이메일 주소가 적혀 있음

 

7)license

- 패키지의 라이센스 정보가 담겨 있음 

 

8) autor, contributors

- autor는 패키지를 만든 사람, contributors는 패키지를 만드는데 기여하는 사람들

 

9) main

"scripts" : { 
  "test" : "실행할 커맨드 A"
}

- require('패키지 이름')로 로드했을 때 실제로 로드되는 파일의 이름이 적혀 있는 필드 

 

10) man

- 패키지의 사용 설명서가 담긴 파일들의 경로가 적혀 있음

 

11) repository

- 이 패키지의 코드가 관리되고 있는 레포지토리의 주소를 나타냄 

- 버전 관리 시스템의 저장소 URL(GitHub URL)이 여기 적혀 있음 

 

12) scirpts

- npm으로 간편하게 실행할 수 있는 스크립트 파일들의 정보가 담겨 있음

"scripts" : { 
  "test" : "실행할 커맨드 A"
}

 - 터미널에서 npm run test라고 실행했을 때 '실행할 커맨드 A'가 실행됨 

 

13) dependencies

- 현재 패키지가 의존하고 있는 다른 패키지들이 나열되어 있는 필드 

- Node.js 패키지 생태계에서 핵심이 되는 필드 

 

 

5. Semantic Version과 Version Range Syntax

 

1) Semantic Version

- dependencies 필드에 있는 각 패키지 이름 옆의 버전은 Semantic Version이라고 함 

x: 메이저 버전(major version)

y: 마이너 버전(minor version)

z: 패치 버전 (patch version)

 

- 패키지의 버전을 업데이트할 때 일정한 규칙이 있음

- API (Application Programing Interface)는 외부에서 사용할 수 있도록 공개된 함수 

- Semantic Version에서는 API의 변화를 기준으로 버전을 업데이트해야 함 

 

- 패치 버전은 API에 변화를 주지 않는 범위내에서의 변화가 이루어진 경우에 업데이트 

- 마이너 버전은 이전 버전의 API와 호환되는 (backward-compatible) API 상의 변화가 발생했을 때 업데이트 

- 메이저 버전은 이전 버전의 API와 호환되지 않는 (not backward-compatible) API 상의 변화가 발생했을 때 업데이트 

 

 

2) Version Range Syntax

 

- Version Range Syntax는 Semantic Version을 기반을 패키지가 다른 패키지의 어느 버전들을 요구하는지를 나타낼 때 사용 

- Semantic Version 왼쪽에 물결 모양 기호(틸드 Tilde)

 

ex) codeit이라는 패키지가 존재하고, express 패키지가 codeit 패키지를 필요로 한다고 가정

 

● Basic Syntax

 

"codeit":"231"

- 정확히 2.3.1 버전의 codeit 패키지가 필요

 

"codeit":">2.3.1"

- 2.3.1보다 높은 버전의 codeit 패키지가 필요

 

"codeit":"2.3.1||>=2.5.0<3.1.2"

- 2.3.1 버전의 codeit 패키지 또는 2.5.0 버전 이상이면서 3.1.2 버전 미만의 codeit 패키지가 필요로 함 

 

● Advanced Syntax

 

Hyphen Range

"codeit":"2.3.1-3.1.2"

- 2.3.1 버전 이상 3.1.2 버전 이하의 codeit 패키지가 필요

 

X-range

"codeit":"*"

- 어느 버전의 codeit 패키지도 상관 없음

 

Tilde Range

- 틸드 (물결)를 사용한 표기법 

- 마이너 버전이 표시된 경우는 패치 버전 업데이트까지만 허용하고, 마이너 버전이 없으면 마이너 버전의 업데이트까지 허락

 

"codeit":"~3.1.2"

 - >=3.1.2 < 3.2.0  해석 

 

"codeit":"~3.1"

 - 패치 버전이 적혀 있지 않다면 >=3.1.0<3.2.0 해석 

 

"codeit":"~3"

 - 마이너 버전도 적혀 있지 않다면 >=3.0.0 < 4.0.0 해석 

 

Caret Range

- 메이저 버전, 마이너 버전, 패치 버전 중에서 현재 보이는 가장 왼쪽의 0이 아닌 버전이 바뀌지 않는 선에서의 버전 업데이트만을 허용 

 

"codeit" :"^1.2.3"

 - 가장 왼쪽의 0이 아닌 버전, 1이 바뀌지 않는 선에서의 버전 업데이트만 허용

 >=1.2.3<2.0.0

 

"codeit":"^0.2.3"

 - 가장 왼쪽의 0이 아닌 버전, 2가 바뀌지 않는 선에서의 버전 업데이트만 허용 

 >=0.2.3 < 0.3.0

 

"codeit":"^0.0.3"

 - 가장 왼쪽의 0이 아닌 버전, 3이 바뀌지 않는 선에서의 버전 업데이트만 허용 

 >=0.0.3 < 0.04

 

 

6. 내 모듈을 패키지로 만들어보기

 

- 현재 디렉토리 안에 패키지 package.json 파일을 만들면 됨

- 파일 내용을 일정한 형식에 맞춰서 작성해야 함

- npm init

 -> 현재 디렉토리를 하나의 패키지로 만들 때 쓰는 명령어

 -> 초기 내용을 설정

 

 

7. package.json과 package-lock.json의 차이 

 

1) 패키지를 공유할 때, 그 안의 node_modules 디렉토리는 공유하지 않음

 

- 패키지를 공유할 때는 그 안의 package.json 파일만 제대로 공유하면 됨

- npm install 이라고 쓰고 실행하면, npm이 package.json 파일의 dependencies 필드에 적힌 의존 패키지들의 이름과 Semantic Version /  Version Range Syntax를 보고 알맞은 패키지들을 자동 설치 해줌

 

- 패키지를 공유할 때 무거운 용량의 node_modules 디렉토리는 굳이 직접 공유하지 않고, 패키지를 공유받는 사람이 npm install 명령어를 실행해서 공유받은 package.json 파일을 기반으로 직접 생성하는 것

 

2) pacakge.json 파일과 package-lock.json 파일

 

- package-lock.json 파일은 맨 처음 패키지를 설치했을 때 생겼던 파일 

- package-lock.json 파일에는 dependencies 필드에, 현재 패키지 안에 어떤 패키지들이 설치되어 있는지 그 정보가 담겨 있음

- package.json 파일은 npm init 명령어를 사용해서  디렉토리를 하나의 패키지로 만들었을 때 생긴 파일

- package.json 파일에는 dependencies 필드가 있고, 여기에는 어떤 패키지들이 설치되어야 하는지에 대한 정보가 있음

package.lock.json	dependencies 필드에는 현재 패키지에 실제로 설치되어 있는 다른 패키지들의 버전이 적혀 있음
package.json	dependencies 필드에는 현재 패키지가 동작하기 위해 필요한 다른 패키지들의 버전 범위가 적혀 있음

 

 

8. nodemon 패키지를 전역 설치하기 

 

nodemon 패키지

- 파일의 코드 변화를 알아서 감시해서 자동으로 재실행해주는 패키지

- npm install -g nodemon

- -g: nodemon 패키지를 글로벌 모드로 설치 (전역 설치)

  -> 패키지를 하나의 실행파일로서 사용 가능 

 

 

9. npm의 중요성

 

1) 웹 프론트엔드 개발 세계에서도 중요한 npm

 

 웹 프론트엔드 개발시 필요한 작업

  - 코드가 잘 작동하는지를 검사하는 테스트 작업(testing) 

   ex) Mocha

 

  - 자바스크립트 코드가 가독성 좋은 포맷으로 잘 작성되었는지를 검사하고 수정하는 작업 (code formatting)

  ex) ESLint

 

  - 작성한 자바스크립트 코드가 자바스크립트 최신 표준을 지원하지 않는, 오래된 브라우저에서도 문제없이 동작할 수 있도록 변환하거나 자바스크립트의 단점을 보완한 언어 (ex: Typescript)로 작성한 코드를 다시 자바스크립트로 변환하는 트랜스파일 작업(transpiling) 

 ex) Babel

 

- 여러 자바스크립트 파일들과 CSS 파일 등을 하나의 파일로 묶는 번들링 작업 (bundling)

 ex) Webpack

 

- 번들링된 결과를 더 작은 용량으로 압축해주는 작업 (minifying)

 ex) Uglify-JS

 

- 이런 작업들을 한 번에 자동으로 실행할 수 있도록 설정하는 작업(Task Runner)

 ex) Gulp

 

-> 웹 프론트엔드 개발자들도 이런 툴들을 모두 npm 저장소에서 패키지로 다운받아서 사용