PnP, zero-installs, constraints

Yarn Berry를 대표하는 세 가지 생각은 PnP, zero-installs, constraints야. 각각이 해결하는 문제를 구분해 보자.

Plug'n'Play(PnP). 수천 개 패키지를 node_modules에 풀어 놓는 대신 .yarn/cache/의 zip 파일로 보관해. 코드가 import foo from 'lodash'를 실행하면 생성된 .pnp.cjs가 캐시 zip 안의 정확한 바이트 범위로 연결해. 압축을 풀 필요가 없어 설치와 시작이 빨라지고, manifest에 없는 의존성은 즉시 실패해. 대신 PnP를 이해하지 못하는 일부 IDE와 오래된 bundler에는 SDK 보조 도구가 필요해.

PnP 대체 경로. PnP가 현재 도구 체계와 너무 많이 충돌한다면 .yarnrc.yml에 nodeLinker: node-modules를 설정해. Yarn은 전통적인 node_modules 배치로 돌아가면서 Berry의 다른 개선은 유지해. PnP를 채택하지 않아도 Berry를 쓸 수 있다는 뜻이야.

Zero-installs. .yarn/cache/를 Git에 포함하면 팀원과 CI 컴퓨터는 git clone만으로 준비가 끝나. 별도 설치 단계가 없어 CI의 설치 시간이 분에서 초로 줄어. 의존성이 많으면 저장소가 몇 GB까지 커질 수 있지만 CI 속도 향상도 그만큼 커.

Constraints. 프로젝트 전체의 규칙을 강제하는 JavaScript 기반 엔진이야. 모든 workspace가 같은 React 버전을 쓰게 하거나 lodash를 직접 의존하지 못하게 하는 규칙을 yarn.config.cjs에 정의하고, yarn constraints로 위반을 찾아. 한 팀이 머릿속으로 기억할 수 있는 규모를 넘어선 monorepo에서 특히 값져.

Code

도구 체계와 충돌할 때 PnP 끄기·yaml

# repo root 의 .yarnrc.yml
nodeLinker: node-modules

# Berry 가 이제 일반 node_modules 만들고 .pnp.cjs 건너뜀.
# Berry 의 다른 기능 (캐시, lockfile, workspaces, constraints) 유지
# 그치만 PnP 싫어하는 도구가 normal 작동.

Constraints로 workspace의 React 버전 통일·javascript

// yarn.config.cjs
module.exports = {
  constraints: async ({ Yarn }) => {
    for (const dep of Yarn.dependencies({ ident: 'react' })) {
      dep.update('19.0.0');
    }
  },
};

// 그 다음 돌려:
//   yarn constraints           — 체크
//   yarn constraints --fix     — 자동 적용

Exercise

Berry 프로젝트의 .yarnrc.yml에서 nodeLinker 설정을 확인해. PnP가 기본이라면 ZipFS 확장과 'yarn dlx @yarnpkg/sdks vscode'를 사용해 VS Code에 연결해 봐. 통합 비용이 너무 크다면 nodeLinker: node-modules로 전환해도 돼. PnP가 없는 Berry도 Classic보다 현대적인 선택이야.

Code

External links

Exercise

Progress

댓글 0