콘텐츠 주소 저장소, 엄격한 node_modules, workspaces

pnpm을 떠받치는 세 개념은 콘텐츠 주소 저장소, 엄격하게 중첩된 node_modules, 일급 workspaces 지원이야. 이 셋을 합치면 npm에서 옮길 이유가 분명해져.

콘텐츠 주소 저장소. 각 패키지 버전은 SHA256으로 식별되어 ~/.pnpm-store/에 한 번만 저장돼. 프로젝트의 node_modules에 설치할 때 파일을 복사하지 않고 저장소를 가리키는 hard link를 만들어. 여러 경로가 inode 수준에서 같은 실제 파일을 공유하므로 디스크 사용량이 전체적으로 50~70% 줄고, 이미 있는 바이트를 재사용해 설치도 훨씬 빨라.

엄격하게 중첩된 node_modules. 각 패키지의 의존성은 자체 node_modules 아래에 들어가고, package.json에 직접 선언한 패키지만 프로젝트 루트로 올라와. 코드는 선언한 패키지만 불러올 수 있으므로 phantom dependencies가 생기지 않아. import x from 'lodash'라고 썼는데 pnpm add lodash를 하지 않았다면 즉시 실패해. 엄격함 자체가 기능인 셈이야.

Workspaces. pnpm은 뛰어난 monorepo 지원을 제공해. 저장소 루트의 pnpm-workspace.yaml에 하위 패키지를 선언하고 루트에서 pnpm install을 실행하면 모두의 의존성을 설치하면서 공통 패키지는 저장소를 통해 공유해. pnpm -r build는 모든 workspace에서 스크립트를 실행하고, pnpm --filter web dev는 이름이 web인 패키지만 대상으로 해. 콘텐츠 주소 저장소와 결합하면 큰 monorepo 설치가 npm보다 훨씬 빨라져.

Code

pnpm workspace 구성·yaml

# repo root 의 pnpm-workspace.yaml
packages:
  - 'apps/*'
  - 'packages/*'

# 그 다음 root 에서:
pnpm install               # 모든 거 install
pnpm -r build              # 모든 workspace 빌드
pnpm --filter web dev      # apps/web/ 에서만 'dev' 실행
pnpm --filter './apps/*' test  # apps/ 에서만 test 실행

엄격한 의존성 구조 확인·bash

# pnpm install 후 어떻게 organized 됐나 봐
ls node_modules/
# .pnpm/        <- 실제 중첩 deps 가 여기, store 에서 hard-link
# react/        <- top-level, 선언된 deps 만 여기로 hoist
# react-dom/
# express/

# 패키지의 transitive deps 는 top-level 에서 보이지 않음 — by design.

Exercise

pnpm 프로젝트의 node_modules/에서 .pnpm/ 하위 디렉터리를 찾아 구조를 살펴봐. 이어서 프레임워크의 하위 의존성처럼 직접 선언하지 않은 전이 의존성을 코드에서 불러와 봐. pnpm이 거부하며 보여 주는 오류 메시지를 읽는 것까지가 연습이야.

Code

External links

Exercise

Progress

댓글 0