지금 당장 pnpm으로 넘어가야 하는 이유

📒 지금 당장 pnpm으로 넘어가야 하는 이유

---

안전빵이란 이유로 계속해서 npm을 고집해 오다 최근에 pnpm으로 넘어갔습니다.

마이그레이션을 마친 지금 생각해보면 "왜 이제야 넘어갔을까"라고 생각이 됩니다.

아직 npm과 classic yarn을 사용하시는 분들께 npm의 단점부터 pnpm의 장점, 마이그레이션, 사용법까지 전부 소개합니다.

 

📌 pnpm이란?

pnpm은 Performant Node Package Manager의 약자로, 기존 npm의 단점을 보완하기 위해 탄생한 패키지 매니저입니다.

사내에서 기존부터 npm을 사용했었는데, 시간이 지날수록 부각되는 단점들에 의해 패키지 매니저 변경을 결정했습니다.

현존하는 여러 패키지 매니저 중 고민 끝에 pnpm을 사용하기로 했는데요.

pnpm을 선택한 가장 큰 이유는 낮은 러닝커브, 쉬운 마이그레이션, 준수한 성능을 갖추고 있었기 때문입니다.

그럼 npm의 문제점과 pnpm에서는 어떻게 개선 되었는지 소개합니다.

 

📌 npm의 문제점, flat tree

npm은 node_module 내부에 또 다른 node_module이 저장되는 비효율적인 중첩된 트리 구조를 해결하기 위해 v3부터 flat tree 구조를 도입하여 이러한 문제를 해결하려 했습니다.

flat tree 구조로 설치하는 npm은 package.json에 명시되는 의존성과 각 패키지들의 의존성을 분석합니다.

기본적으로 불필요한 디스크 공간 차지를 방지하기 위해 의존성들을 1 depth로 끌어올리는 호이스팅을 진행합니다.

그러나 서로 다른 패키지에서 동일한 의존성에 대한 다른 버전을 요구할 수 있기 때문에 충돌을 막기 위한 중첩된 패키지를 생성할 수 있습니다.

이 과정에서 다음과 같은 불편함이 발생합니다.

🔎 느리다

패키지가 많아 질수록 위와 같이 의존성을 분석하는 시간도 오래 걸리고 의존성 해결 과정에서 결정된 순서에 따라서 패키지들을 순차적으로 설치할 때도 있기 때문에 설치 속도가 꽤나 느린 편입니다.

🔎 용량 차지

의존성이 프로젝트마다 개별적으로 설치되기 때문에 갓 만든 프로젝트도 500mb가 기본적으로 넘어가버리고 어느 정도 규모가 갖춰진 프로젝트면 기가바이트 단위를 훌쩍 뛰어넘기 일쑤입니다.

테스트한다고 프로젝트 몇개 생성하다 보면 디스크 용량은 어느새 포화 직전입니다.

🔎 유령 의존성

모든 의존성을 끌어올려 설치하는 방식 때문에 직접적으로 설치하지 않은 패키지를 참조할 위험이 항상 존재합니다.

 

📌 pnpm이 해결한 방법

pnpm은 패키지를 전역 pnpm store에 설치하고,
심볼링 링크와 하드 링크를 사용하여 의존성의 중첩 구조를 생성합니다.

디바이스에 저장된 전역 pnpm store

pnpm install 시 전역 store에 패키지들이 해시 값으로 저장된 것을 확인할 수 있습니다.

node_modules/.pnpm 에는 전역으로 하드 링크가 걸린 1 depth 형태 모든 의존성들이 존재하고,
node_modules 아래 의존성들은 최종적으로 .pnpm에 심볼릭 링크가 걸리게 됩니다.

node_modules/.pnpm

$ ls -li ./node_modules

이와 같은 방식으로 의존성을 설치하며 기존 npm의 문제점들은 다음과 같이 개선되었습니다.

🔎 빠르다

패키지 별 설치 순서를 계산할 필요가 없기에 병렬로 설치됩니다.

게다가 모든 패키지를 몰아서 설치한 후 프로젝트의 의존성 트리와 똑같은 형태로 링크만 걸어주는 형태이기 때문에 설치 프로세스가 굉장히 빠릅니다.

🔎 용량 절감

같은 패키지를 여러 프로젝트에서 사용할 때 전역에 설치된 패키지를 참조하기 때문에 엄청난 용량 절감이 가능합니다.

🔎 완벽한 의존성 트리

pnpm은 특정 패키지를 여러 곳에서 사용해도 하나만 참조하기 때문에 용량에 대한 걱정이 없습니다.

프로젝트의 모든 의존성 트리가 완벽한 중첩 구조로 이뤄져 있습니다.

그렇기에 직접적으로 의존하는 패키지만 참조할 수 있게 되어 유령 의존성 현상을 말끔히 해결했습니다.

 

📌 삽질

패키지는 전역으로 저장되니 node_modules는 용량이 없겠지?

라는 우연한 호기심에 node_modules 폴더를 확인하니 이게 웬걸, 몇백 메가바이트의 용량이 잡혀있었습니다.

그래서 전역 pnpm store를 확인해 보니 비슷한 용량이 잡혀있었고 폴더와 파일명은 해시 값으로 저장되기 때문에 정확히 어떤 패키지인지 확인도 되지 않았습니다.

거기서부터 반나절 삽질 끝에 알아낸 결과를 먼저 말씀드리자면 전역으로 저장되는 것이 맞다는 겁니다.

제가 가진 의문점 두 가지는 다음과 같이 해소되었습니다.

🔎 왜 node_modules 용량이 잡히지?

이건 그냥 제가 하드 링크와 심볼릭 링크를 정확히 몰라서 생긴 문제 었습니다.

• 하드 링크
  • 파일 시스템 내에서 동일한 파일 내용을 가리키는 두 개 이상의 파일 이름입니다.
  • 하나의 파일에 대해 두 개의 하드 링크가 있을 때, 하나의 하드 링크를 삭제해도 원본 파일은 삭제되지 않습니다.
    파일 데이터는 모든 하드 링크가 삭제될 때까지 파일 시스템에 유지됩니다.
  • pnpm store에 저장된 패키지나, node_modules/.pnpm에 저장된 패키지나 동일한 파일을 참조하고 있습니다.
  • 어디서나 동일한 용량을 표시하지만 결국에는 참조하는 단 하나의 파일만큼의 용량을 차지합니다.
• 심볼릭 링크 (소프트 링크)
  • 특정 파일이나 디렉토리를 가리키는 파일입니다.
  • 심볼릭 링크는 원본 파일의 경로를 저장하며, 원본 파일이 이동되거나 삭제되면 더 이상 유효하지 않게 됩니다.
  • 윈도우의 바로 가기 파일과 비슷하게 생각할 수 있습니다.

🔎 pnpm store와 프로젝트 의존성의 하드 링크는 정말 같은가?

하나의 파일에 대해 여러 하드링크가 있을 때 동일한 파일인지 확인하려면 inode를 확인하면 됩니다.

• inode
  inode는 파일의 메타데이터(권한, 소유자, 파일 사이즈 등)와 실제 데이터의 위치 정보를 포함합니다.
  파일 시스템은 이 inode 정보를 기반으로 파일에 접근합니다.
  파일 이름은 사용자가 inode에 저장된 데이터에 접근하기 위해 사용하는 레이블이며, 이는 기본적으로 파일 데이터의 첫 번째 하드 링크를 형성합니다.

$ ls -i <위치>

이 명령어를 사용해 전역 스토어를 살펴보면 8자리 inode들이 쫙 펼쳐집니다.

저는 여기 있는 inode 정보를 프로젝트 node_modules에서 find 명령어와 inode를 찾는 옵션인 -inum으로 찾으면 당연히 나올 줄 알고 검색해 봤습니다.

$ find . -inum <inode 번호>

그런데 아무리 스토어 내부 폴더 inode와 내부 파일 inode로 검색을 해도 node_modules에서 동일한 inode가 발견되지 않았습니다.

하지만 포기할 수 없었습니다.

동일한 파일을 바라보고 있는 하드 링크라는 가정하에 다음과 같은 실험을 했습니다.

1. pnpm store 삭제, node_modules 존재
2. pnpm store 존재, node_modules 삭제
3. pnpm store 존재, node_modules 없는 상태에서 install로 추가

결과는 성공적이었습니다.

만약 두 하드 링크가 다른 파일을 바라보고 있다면 큰 폭으로 용량이 늘었다 줄었다 해야겠지만, 모든 경우에서 근소한 폭으로 용량이 변동되었습니다.

완벽히 inode가 같다는 걸 증명하지 못해 찝찝하지만 그래도 실험으로 어느 정도 해소 되었습니다.

확인 방법을 아시는 분은 댓글 부탁드립니다.

 

📌 pnpm 마이그레이션

🔎 pnpm 설치

$ npm i -g pnpm

node 버전에 따른 pnpm 설치 가능 버전은 위와 같습니다.

🔎 pnpm import

$ pnpm import

pnpm import는 프로젝트의 종속성을 pnpm 포맷으로 가져오는 데 사용됩니다.

프로젝트 루트에서 사용하면 자동으로 package.json을 인식해 의존성을 읽어옵니다.

과정을 마치면 위와 같이 lock 파일이 생성됩니다.

🔎 다른 패키지 매니저 lock 파일 삭제하기

package-lock.json이나 yarn.lock 같이 다른 패키지 매니저에 의해 생성된 lock 파일을 삭제해 줍니다.

🔎 pnpm으로 패키지 설치 강제하기

// package.json
{
    "scripts": {
        "preinstall": "npx only-allow pnpm"
    }
}

preinstall 스크립트는 패키지를 설치하기 전에 실행되는 사용자 정의 스크립트입니다.

only-allow라는 패키지를 사용하여 pnpm에 의해 패키지들이 설치되는지 확인합니다.

🔎 node_modules 폴더 삭제하기

기존 패키지 매니저로 설치한 node_modules 폴더를 삭제해 줍니다.

🔎 패키지 재설치

$ pnpm install

이제 설치하고 나면 심볼릭 링크와 하드 링크가 걸린 node_modules가 완성이 됩니다.

잘 설치가 되었다면 의존성에 위와 같은 화살표 표시로 심볼릭 링크가 걸렸다는 것을 확인할 수 있습니다.

 

📌 pnpm 기본 명령어

1. pnpm install
   패키지를 설치합니다.
   npm install과 유사하지만, pnpm은 공유 패키지 캐시를 사용하여 디스크 공간을 절약합니다.
2. pnpm add [package]
   새로운 패키지를 설치합니다
   npm install [package]와 유사하지만, pnpm은 공유 패키지 캐시를 사용합니다.
3. pnpm remove [package]
   패키지를 제거합니다.
4. pnpm update
   종속성을 최신 버전으로 업데이트합니다.
5. pnpm list
   프로젝트에 설치된 모든 패키지를 표시합니다.
6. pnpm [script]
   package.json 파일의 scripts 섹션에서 지정된 스크립트를 실행합니다.
7. pnpm link
   로컬에서 개발 중인 패키지를 프로젝트에 링크합니다.
8. pnpm unlink
   로컬 패키지의 링크를 제거합니다.
9. pnpm publish
   패키지를 npm 레지스트리에 게시합니다.