4. 패키지 [Node]

node를 다운 받았을 뿐인데,

사은품처럼 같이 설치된,

(JS의 폭발적인 성장을 이끈 패키지 매니저),

npm에 대해서 알아보자.

 

 

1. npm

npm이 등장하기 이전 패키지를 사용하기 위해 패키지를 설치하면, 패키지는 글로벌패키징의 형태로 설치되었다.

글로벌 패키징의 형태로 설치된 패키지는 시스템 전체에서 사용할 수 있었다.

 

이러한 방식은 하나의 패키지가 여러 프로젝트에서 사용될 때 문제가 발생한다.

버전에 따른 호환성 문제가 그것이다.

npm이전 이러한 문제를 해결하기 위해 개발자들은 프로젝트마다 수동으로 버전을 맞춰야 했다.

이러한 방식은 관리가 번거롭고 실수가 잦았다.

 

이러한 문제를 해결하기 위해

2010년 1월 npm이 등장하였다.

npm 덕분에 개발자는 로컬 패키징이 가능해졌다.

프로젝트 폴더 내에서만 사용할 수 있는 패키지를 설치할 수 있게 된 것이다.

개발자는 npm을 사용하여 프로젝트마다 독립적으로 패키지를 설치하고 관리할 수 있게 되었다.

 

npm : node package manager
패키지 : npm에 업로드된 노드 모듈

 

뿐만 아니라 npm은 오픈소스 생태계를 제공한다.

즉, 다른 사람들이 만든 소스코드를 모아둔 저장소로 볼 수 있다.

이를 이용하여 개발자는 남의 코드를 사용하여 프로그래밍이 가능하다.

이미 누군가 개발한 코드를 굳이 내가 다시 구현할 필요가 없어 효율적이다.

 

 

2. package.json

로컬패키징이 가능해진 이후 프로젝트 디렉토리에서만 사용될 패키지들을 관리하기 위한 무언가가 필요해졌다.

그 무언가가 package.json 파일이다.

 

package.json은 npm init 명령어를 통해 생성한다.

package.json 파일에는 현재 프로젝트에 대한 정보와 사용중인 패키지에 대한 정보가 담겨있다.

(프로젝트에 사용되는 패키지 정보는 dependencies, devDependencies에 적힌다.)

 

패키지에 대한 정보는 반드시 버전을 기록해야 한다.(같은 패키지라도 버전에 따라 기능이 다를 수 있다.)

 

패키지의 버전은 SemVer(유의적 버저닝)방식을 따른다.

 

a.b.c

a  : major, 주버전, 하위 호환이 되지 않는 변경사항

b  : minor, 부버전, 하위 호환이 되는 변경사항

c  : patch, 수버전, 간단한 버그 수정

주버전이 다르면 서로 호환되지 않는 수준의 변경이 버전간 존재한다고 보면 된다.

수버전일 수록 변경사항의 영향력이 낮다고 볼 수 있다.

 

^a.b.c  : 패키지 업데이트 시 major를 제외하고 업데이트 (b, c 업데이트) 

~a.b.c  : 패키지 업데이트 시 major와 minor를 제외하고 업데이트 (c 업데이트)

a.b.c  : 버전 고정

(+ 노드에서는 배포시 반드시 버전을 올려야 한다.)

 

 

3. node_modules

package.json파일은 필수가 아니다. package.json파일이 존재한다면,

npm i ⭐을 터미널에 입력하면

⭐이 package.json에는 작성되고, node_modules에는 설치된다.

node_modules폴더가 패키지들이 설치되는 폴더이다.

 

⭐ 패키지가 실질적으로 사용되기 위해서는 node_modules파일에 ⭐패키지가 설치되어 있어야 한다.

package.json파일은 프로젝트에 사용되는 패키지들에 대한 정보를 제공할 뿐이다.

 

node_modules의 크기는 크다.

따라서 배포시 삭제 후 배포한다. 

node_modules폴더는 npm i 명령어를 통해서 다시 생성할 수 있다.

(package.json파일을 기준으로 다시 패키지들을 설치한다.)

 

 

4. package-lock.json

패키지간 의존관계를 명확하게 하기 위한 파일 정도로 이해하면 된다.

패키지를 설치하면 자동으로 작성된다.

 

 

참고❤️

https://www.zerocho.com/book/1