Content-Addressable Store, Strict node_modules, Workspaces

pnpm 의 세 load-bearing 개념이 content-addressable store, strict 중첩 node_modules, first-class workspaces. 합쳐서 npm 에서 마이그레이션 정당화.

Content-addressable store. 모든 패키지 버전이 SHA256 으로 식별, ~/.pnpm-store/ 에 한 번 살아. pnpm 이 패키지를 프로젝트 node_modules 에 install 할 때, 프로젝트에서 store 로 hard link 만듦 — 복사 아님. Hard link 가 inode 레벨로 디스크 공유; 파일이 물리적으로 디스크에서 같지만 여러 path 에서 reach. 결과: 전체 50-70% 적은 디스크 + 바이트 이미 있어서 극적으로 빠른 install.

Strict 중첩 node_modules. 각 패키지의 의존성이 자기 node_modules 서브폴더 아래 중첩, package.json 에 명시 선언된 패키지만 프로젝트 root 로 hoist. 코드가 오직 선언한 패키지만 import 가능 — phantom deps 없음. 코드가 import x from 'lodash' 하지만 pnpm add lodash 안 했으면 즉시 실패. Strictness 가 기능.

Workspaces. pnpm 이 best-in-class monorepo 지원. repo root 의 pnpm-workspace.yaml 이 어떤 sub-package 가 존재하는지 선언. root 의 pnpm install 이 모두에 deps install, store 통해 공통 deps 공유. pnpm -r build 가 모든 workspace 패키지에 스크립트 실행; pnpm --filter web dev 가 이름 붙은 패키지에서만. Store 와 결합되어 큰 monorepo install 이 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 실행

strict 구조 검증·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.

Content-Addressable Store, Strict node_modules, Workspaces

Code

External links

Exercise

Progress

댓글 0