코드잇 사이트를 공부하면서 정리한 내용입니다.
모듈
npm: Node Package Module
package-lock.json : 설치된 서드 파티 모듈에 관한 정보
node_modules : 실제로 설치된 서드 파미 모듈의 디렉토리
디렉토리 하위 파일 이름들이 모듈의 이름이랑 같다. 모듈은 하나의 자바스크립트 파일인데 왜 디렉토리 파일 이름일까?
모듈의 이름이 파일 이름일 수도 있고 디렉토리 이름일 수도 있다.
노드에서 모듈이 검색되는 순서
경로가 있는지 없는지 판단.
만약 경로가 없다면
1. 코어 모듈은 경로를 작성하지 않고 require 한다.
2. 만약 코어 모듈에 require 하는 모듈 이름이 없으면 서드 모듈이라고 판단
3. node_module 디렉토리 내에 require 하는 이름의 디렉토리가 있나요~?
4. 디렉토리 안에 package.json 파일이 있나요?
- 무조건 서드 파티 모듈 해당사항 --> 4-1. main 필드에 적힌 파일 로드
- 디렉토리 안에 inde.js 파일이 있나요?
- package.json 파일이 존재하더라도 main 필드가 없으면, index.js 파일이 로드 된다.
중요 포인트: 서드 파디 모듈은 package.json 파일을 가진 디렉토리 형태로 존재하기 때문에 서드파티모듈 이름과 디렉토리 이름이 같은 것이다.
하나의 서드파티 모듈은 다른 서드 파티 모듈을 필요로하는 경우가 있는데 이를 dependency 라고 한다.
- pacakge.json 이라는 파일을 가진 디렉토리가 패키지다.
- 하나의 서드 파티 모듈은 하나의 패키지이다.
- 서드 파티 모듈을 관리할 때 쓰는 npm은 node package manager 의 줄임말이다.
서드 파티 모듈 -> 패키지
package.json
Semantic Version
각 패키지 옆에 버전이 적혀있는데 이를 Semantic version 이라고 한다.
예를 들어 1.3.7 과 같이 적혀있는데 x.y.z 로 보면
x는 메이저 버전, y를 마이너 버전, z를 패치 버전 이라고 한다.
z 패치 버전은 API 에 변화를 주지 않는 범위 내에서 변화가 이루어진 경우로 코드에 존재하는 버그 해결 및 알고리즘을 변경했을 때, 1.3.8 과 같이 변경한다.
y 마이너 버전은 이전 버전의 API와 호환되는 API 상의 변화가 발생했을 때, 1.3.7 에서 새로운 API를 추가하면 1.4.0으로 버전을 올리면 된다.
x 메인 버전은 이전 버전의 API와 호환되지 않는 API 상의 변화가 발생했을 때 업데이트. 기존의 API를 아예 삭제했거나 이름이 변경 되는 것과 같은 상황이 발생했을 때.
Version Range Syntax
패키지가 다른 패키지의 어느 버전들을 요구하는지 나타낼 때 사용
-
Basic Syntax
"codeit":"2.3.1" -> 정확하게 2.3.1 버전 필요
"codeit" : ">2.3.1" -> 2.3.1 보다 높은 버전 필요
"codeit" : "2.3.1 || ≥2.5.0 <3.1.2" -> 2.3.1 버전 또는 2.5.0 이상 3.1.2 미만 버전 필요 -
Advanced Syntax
2-1) Hyphen Range
- "codeit" : "2.3.1 - 3.1.2" 2.3.1 이상 3.1.2 이하 버전
2-2) X-range
- "codeit" : "*" - 어떤 패키지도 상관 없다.
- "codeit" : "3.x" - x 는 어떤 버전이 들어가도 상관없다.
- "codeit" : "3.1.x" - 3.1 의 버전들은 다 된다.
2-3) 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 미만 버전
2-4) Caret Range
- "codeit" : "^1.2.3" - 1.2.3 이상 2.0.0 미만 버전
- "codeit" : "^0.2.3" - 0.2.3 이상 0.3.0 미만 버전
- "codeit" : "^0.0.3" - 0.0.3 이상 0.0.4 미만 버전
모듈을 패키지로 만들기
npm init
npm 공개 저장소에 올리기
1. npm login
2. npm whoami -> 나의 아이디가 출력되는지 확인
3. npm publish
4. npm version -> 버전 업데이트 할 때 ex) npm version 1.0.1
5. npm unpublish 패키지이름@버전
6. npm unpublish 패키지이름 --force
nodemoon 패키지
코드를 변경할 때마다 서버를 종료했다가 다시 시작해야하는 번거러움이 있다.
이를 해결하기 위해서 npm install -g nodemon 을 해보자!
만약 권한 문제가 있다면 error 가 발생할 것이다.
이럴 경우 sudo npm install -g nondemon 으로 설치하자!
파일을 nodemon main.js 로 실행해야한다
그러면 파일 코드를 수정하면 자동으로 수정이 되어 서버에 반영된다.
package.json / package-lock.json
패키지를 공유할 때, 패키지 안에 있는 node_modules 디렉토리는 공유하지 않는다,
node_moulde은 패키지의 내용들이 직접 설치된 곳으로 용량이 매우 크다.
그래서 공유하려는 패키지가 어떤 패키지에 의존하는지 작성되어 있는 package.json 파일을 공유한다.
여기서 하나의 문제점이 Version Range Syntax 때문에 패키지를 작업한 사람의 버전과 패키지를 다운 받은 사람의 버전이 다를 수 있다. 예를 들어 ^3.5.1로 되어 잇으면 작성한 사람은 3.5.1 버전을 사용했지만 다운 받은 사람은 3.5.1 부터 4.0.0 미만의 버전을 다운 받게 된다.
package-lock.json 은 실제로 설치된 패키지들의 정확한 버전이 기록 되어 있다,
즉,
package.json 은 '현재 패키지가 동작하기 위해 필요한 다른 패키지들의 버전 범위'
package-lock.json 은 '현재 패키지에 실제로 설치되어 있는 다른 패키지들의 버전'
두 개의 json 파일을 함게 공유해주면 좋다!
전역 설치
local mode 설치: 옵션 -g 를 사용하지 않고 설치하는 방법
패키지를 마치 하나의 실행 파일인 것처럼 사용하고 싶을 때 global mode install
다른 코드에서 require 함수로 패키지를 로드할 목적이라면 local mode install
cat package.json
패키지 정보 조회: npm info 패키지명
현재 패키지의 dependecies 조회: npm list
패키지 중 취약점 확인: npm audit
취약점이 발견되면 npm audit fix 또는 수동으로 필요한 조치를 실행
