npm, yarn, pnpm의 차이점을 비교해보자

 

자바스크립트 패키지 매니저 npm, yarn, pnpm의 차이를 알아보자.

 

패키지 매니저란?

 

💁🏻‍♂️ 패키지란?  npm에 등록된 node 모듈.

 

이러한 패키지들을 사용하기 위해서는 다운로드, 설치, 업데이트, 의존성 관리, 제거 등 복잡한 상황들이 많이 생기는데 패키지 매니저는 이러한 과정들을 자동화하여 편리하고 안전하게 수행할 수 있도록 해준다.

 

패키지 매니저의 등장 이전: 프로그램의 dependencies를 수동으로 다운로드 하고 관리
등장 이후: 패키지 매니저를 사용해 dependencies를 다운로드 및 관리

---

모든 패키지 매니저에서 통용되는 개념들은 다음과 같다.

• package.json은 프로그램의 메타데이터를 가지고 있다.
• node_modules 폴더에 dependencies를 설치한다.
• lock 파일에는 각 dependency의 정확한 버전이 기재되어 있다. lock 파일을 통해 모든 팀원이 정확히 동일한 버전의 dependency를 설치할 수 있다.

 

모든 패키지 매니저에서 공통적으로 제공하는 기능들은 다음과 같다.

• metadata의 작성 및 관리
• dependencies의 설치, 업데이트, 삭제
• 스크립트 실행
• 패키지 퍼블리쉬
• 보안 검사

npm - yarn - pnpm 순으로 큼지막한 차이점들을 살펴보도록 하자.

npm v.s. yarn

👉 패키지 설치 방식의 차이
npm: 패키지를 순차적으로 설치한다.
yarn: 여러 패키지를 동시에 가져와 병렬적으로 설치한다.
→ 속도 측면에서 yarn이 더 우세하다. (다만 npm의 업데이트로 인해 현재는 그 차이가 근소하다고 한다.)

npm, yarn v.s. pnpm

👉 node_modules의 structure 차이

npm, yarn: flat structure
pnpm: flat structure의 문제점을 해결한 symlinked structure

flat structure란?

패키지 A,B,C가 있다고 가정해보자. 패키지 A,C는 모두 패키지 B에 의존한다. 이러한 상황을 가정했을 때 npm@3 이전의 node_modules 구조는 다음과 같았다.

 

해당 디렉토리 구조는 다음의 문제점을 가진다.

• depth가 지나치게 깊어질 수 있다.
• depth가 깊어짐에 따라 directory path 또한 길어진다.
• 동일한 패키지에 대한 중복된 파일들이 생성된다.

이러한 문제를 해결하기 위해 npm은 flat structure를 도입했다. yarn 또한 flat structure를 사용한다. flat structure는 아래 이미지처럼 생겼다. 

flat structure

flat 하다는 말이 이제 이해가 되는가? 보면 모든 패키지의 depth가 동일하다. 패키지 A,C의 하위에 있던 B가 top으로 호이스팅 되었으므로, 이를 패키지 호이스팅 방식이라고도 부른다. 하지만 만약 패키지 A,C가 서로 다른 버전의 패키지 B를 필요로 한다면 어떻게 될까? 패키지 A-C 순으로 설치했다면 다음과 같은 구조가 된다. 

a/
b/ # v1.0.0
c/
└── node_modules/
	└── b/  # v2.0.0

패키지 A 설치 시 B를 호이스팅 해 top에 설치한다. C 설치 시 top에 이미 v1.0.0의 B가 있으므로 C 하위에 v.2.0.0의 B를 설치한다. 즉 패키지의 설치 순서에 따라 node_modules의 구조가 달라진다. 

flat structure의 문제점

• ghost dependency 
  = modules can access packages they don't depend on 모든 패키지가 호이스팅 되어 있기 때문에 다른 패키지의 dependency에 접근할 수 있게 된다.
• 한 패키지의 여러 버전이 필요할 경우 동일한 패키지의 파일이 여러 곳에 복사되어야 한다.

pnpm의 symlinked structure

위에서 기술한 flat structure의 문제점을 해결하고자, pnpm은 symlinked structure를 사용한다.

 

pnpm의 node_modules 폴더는 nested 형태이다.(=flat 하지 않다) 그러나 우리는 위에서 이미 nested node_modules의 문제점에 대해 살펴봤었다. pnpm은 어떻게 nested과 flat의 문제점을 동시에 해결했을까?

 

우선 모~든 패키지들은 .pnpm-store 폴더에 저장된다. 필요한 모든 패키지의 모든 버전이 해당 폴더에 물리적으로 저장되고, node_modules에서는 해당 폴더에 대한 hard link와 symbolic link를 통해 패키지에 접근한다. 각 패키지가 한 번만 저장되기 때문에 single source of truth를 지킬 수 있으며, 디스크 공간을 절약할 수 있다. link를 사용하므로 동일한 패키지가 여러 곳에 복사될 일이 없다. 또 구조적으로 nested하기 때문에 각 패키지의 의존 관계를 명확히 파악할 수 있으며, ghost dependency 문제 또한 발생하지 않는다.

 참고로 pnpm은 npm의 drop-in replacement로서 npm만 있다면 바로 사용할 수 있다.

* drop-in replacement: 설정을 바꿀 필요 없이 바로 사용 가능한, 속도와 안정성 등 다양한 기능 향상이 이뤄지는 대체품

 

참고 링크

Switch from NPM to pnpm

https://blog.outsider.ne.kr/1230

https://medium.com/pnpm/why-should-we-use-pnpm-75ca4bfe7d93