pnpm에 대해

pnpm에 대해

 

• pnpm(performant npm)은 npm의 의존성을 더 효율적으로 관리하기 위해 만들어졌다. 실제로 내부적으로 어떻게 동작해서 기존보다 더 나은 환경을 제공하는지 살펴보자.

기존 npm에서 발생하는 이슈

디스크 공간 낭비

• npm 사용시, 사용하는 프로젝트마다 모두 의존성을 개별적으로 갖고 있으므로 중복되는 의존성으로 인해 디스크 공간의 낭비가 있다.

패키지 호이스팅의 부작용

• npm은 의존성 중복, 의존성 충돌등의 이슈를 해결하기 위해 패키지의 호이스팅으로 중복된 패키지들을 관리하기 위한 평탄화가 이루어진다. (npm 3버전 부터 적용) 하지만 이 과정에서 가장 가까운 node_modules부터 모듈을 로드하는 Node.js 규칙 때문에, 의도치 않게 설치한 패키지가 선택되어 의도되지 않은 동작을 할 경우가 생긴다. (설치하지 않은 의존성이 암묵적으로 사용이 가능해지는 유령 의존성 이슈)

만일 pnpm 을 도입을 하게 되면 어떤점들이 나아질까?

---

pnpm을 통해서 얻는 이점

패키지 중앙저장 통한 디스크 공간 절약

• Content addressable store 컨셉을 기조로 모든 패키지는 디스크상의 단일 위치에 저장이 되며, 하드링크로 인해 같은 버전의 의존성을 추가고자 할 경우 디스크의 추가 공간을 소비하지 않게된다.(다른 버전은 설치 진행)

실제로 로컬에서 pnpm store 내부를 확인하게 되면, 내가 설치한 의존성들이 해시 형태로 저장이 된것을 볼 수 있다.

하드 링크 & 심볼릭 링크

하드 링크(Hard Link)

• 파일 시스템에서 동일한 파일의 내용을 가리키는 또 다른 파일명
• 파일의 실제 데이터를 가리키는 직접적인 참조
• 원본 파일과 하드링크는 동일한 inode를 공유
• 원본 파일이 삭제되어도 하드링크를 통해 데이터에 접근 가능
• 디렉토리에 생성 불가

심볼릭 링크(Symbolic Link)

• 다른 파일이나 디렉토리의 경로를 가리키는 특별한 파일(일종의 바로가기)
• 원본 파일의 경로를 저장하는 간접적인 참조
• 원본과 다른 inode를 가짐(inode: 파일 시스템에서 파일이나 디렉토리의 메타데이터를 저장하는 데이터 구조, 파일시스템 내에서 고유한 값을 가지고 있음)
• 원본 파일이 삭제되면 심볼릭링크는 깨짐(dangling link)
• 디렉토리에도 생성 가능
• pnpm을 통해서 의존성을 설치하게 되면 프로젝트의 node_modules에는 실제 파일 대신 심볼릭 링크(경로 정보만 저장)가 생성된다. 정확히는 스토어제 실제로 저장된 패키지와 하드 링크된 .pnpm 내부로 심볼릭 링크가 지정된다.

node_modules 내부 구조

node_modules 내부 의존성들이 심볼릭 링크를 통해 .pnpm 폴더 내부 실제로 위치한 의존성들을 가리키고 있다.

inode값이 같음을 통해 .pnpm 내부 의존성이 스토어 내 의존성과 하드링크된 상태임을 알 수 있다.

의존성 트리 보존

평탄화를 하지 않으므로 유령의존성의 문제가

• pnpm은 강제 평탄화를 하지 않고, 패키지별 실제 트리 구조를 유지한다. 따라서 패키지의 호이스팅이 일어나지 않으므로 의도하지 않은 패키지 사용 문제인 유령 의존성 이슈를 방지할 수 있다.