패키지 매니저 파묘🪦

Source: Dev.to

패키지 매니저의 역사

npm의 문제점

• 중복되는 의존성 다운로드
  의존성이 의존하는 의존성, 그 또다음까지 존재한다. 패키지명과 버전이 일치해도 npm v1, v2에서는 중복으로 다운로드를 실행해 설치 시간이 길었다.

• 설치 방식에서 초래하는 request waterfall
  의존성을 순차적으로 해석하고 다운로드하기 때문에 병렬 다운로드가 불가능했다.
  1️⃣ 의존성 1 설치 → package.json 확인 → 의존성 2 설치 → …
  이 과정이 순차적으로 진행돼 설치 시간이 늘어났다.

• 패키지 버전 고정 불가능
  lockfile이 없어 각 개발자가 서로 다른 버전을 사용했다. package.json에 ^(major) 혹은 ~(minor)만 고정하면 모두 다른 버전으로 개발·배포되었고, 문제 재현이 어려웠다.

read package1/package.json
└─ find package2
   └─ download package2
      └─ read package2/package.json
         └─ find package3
            └─ download package3

read package.json → find package → download package가 순차적으로 발생하면서 npm install 시간이 길어진다.

다운로드 병목 해결사 yarn classic

• 의존성 캐싱
  동일한 패키지명·버전이 중복될 경우 캐시를 사용해 다운로드 시간을 단축한다. 중복 패키지는 호이스팅(hoisting)으로 상위 디렉터리로 이동한다.

• dependency graph를 먼저 그려서 병렬 다운로드

fetch package metadata from registry (JSON)
→ read dependencies from metadata
→ resolve versions (lockfile 우선)
→ 전체 dependency graph 완성

Download packages in parallel

• lockfile을 통한 패키지 버전 고정
  lockfile에 patch version까지 명시해 모두가 동일한 의존성 버전에서 개발·CI·배포가 가능해져 에러 재현 난이도가 낮아졌다.

yarn classic의 문제점

암묵적 의존성으로 인한 프로젝트 의존성 붕괴

Node.js는 모듈을 찾을 때 현재 디렉터리부터 상위 디렉터리로 /node_modules/package를 탐색한다. 호이스팅으로 인해 package.json에 명시되지 않은 패키지가 최상위 /node_modules에 들어가 import가 가능해지며, 이를 phantom dependencies라 부른다.

디스크 I/O로 인한 module resolution 속도 저하

무수한 디렉터리 스캔으로 디스크 I/O가 발생해 yarn dev·yarn build 시 개발 서버 시작 및 빌드 시간이 느려진다.

import lodash
→ filesystem walk-up
→ /node_modules/lodash 있네? OK

암묵적 의존성 해결사 yarn berry

매핑 테이블 파일로 위치 밝혀주기

.pnp.cjs 파일에 각 의존성 경로를 명시하고, Node.js의 require() 동작을 덮어써 .pnp.cjs를 참고해 의존성 경로를 찾는다. 암묵적 의존성 발생 가능성이 차단된다.

무수한 디스크 I/O 대신 파일 하나에서 로직 전부 처리

require()가 덮어써졌기 때문에 반복적인 Disk I/O가 사라진다.

import lodash
→ .pnp.cjs 로드
→ 현재 패키지의 dependency graph 확인
→ package.json에 선언됨?
   ❌ No → 즉시 에러