yarn berry를 주로 사용하고 있는데 패키지매니저 간 차이와 히스토리를 정리해본 적 없는 것 같아서 정리함.
yarn과의 비교를 위해 초창기 문제점들을 나열하나 실제로 현재는 열거된 문제 중 다수가 보완/개선되어 yarn 1과 큰 차이를 보이지 않는 경우가 많다. 다만 yarn은 당시 npm의 문제점들을 보완하기 위해 탄생한 것이었으므로 비교를 위해 해당 특징들을 씀.
패키지 설치 실행 시 순차적으로 npm 레지스트리에서 가져와 설치하므로 비교적 그 속도가 느리다.
설치하고자 하는 패키지A가 내부적으로 또 다른 패키지B에 의존 관계를 가질 때, npm은 이 패키지를 자동으로 그 즉시 설치한다. 패키지 하위 호환 범위의 버전 변경에서 문제가 있는 코드가 포함되어 있다면 위험에 그대로 노출되는 셈.
npm은 semver 규칙에 의거하여 자동으로 패키지들을 업데이트한다. 하나의 패키지에 대하여 업데이트를 실행할 때 패키지 내부 의존성 트리에서 semver에 의해 의도하지 않은 거대한 양의 업데이트가 동반되는 것도 가능한 시나리오.
npm 5 이후 package-lock.json
파일 자동 생성을 지원했으나 그 이전에는 semver 기반 설치와 중복 패키지 제거(merge) 로직 등, 패키지 설치 순서나 시점에 따라 설치 결과인 node_modules의 파일 구조가 정해지는 비결정론적 방식이었다. 이로 인해 서버에 배포된 프로젝트와 개발자 로컬 환경서의 프로젝트의 패키지 설치 파일이 서로 다르거나, 동일한 package.json
파일을 공유하고 있는 개발자끼리도 로컬에 설치된 패키지가 서로 다른 상황에서 버그를 찾아야하는 혼란을 야기하기도 했다. - "제 컴퓨터에선 되는데용?"
패키지 설치 시 병렬 실행을 지원하므로 설치 속도가 빠르다
오로지 yarn.lock, package.json 파일에 저장된 패키지를 설치하며, 코드 실행 전 checksum 으로 패키지 무결성을 검사하여 보안 이슈를 개선했다. (하지만 npm과 동일하게 I/O 호출을 통해 node_modules 폴더를 관리하던 yarn1에서 패키지 내용을 검증하진 않았다는 데 checksum은 뭘 검사하는겨. 이전에 설치된 것과 같은 패키지가 맞는지만 해시로 체크한다는 건가)
yarn.lock 파일을 생성하여 이곳에 기록된 버전에 의거하여 이후 패키지를 설치하므로 모든 디바이스에서 동일한 버전의 패키지가 설치될 것을 보장한다.
패키지 설치 시 레지스트리에서 받아온 패키지 데이터를 로컬 캐시에 저장한다. 이로 인해 한 번 설치했던 패키지를 재설치할 때에는 레지스트리 대신 로컬 캐시를 참조하므로 속도가 빠르고 오프라인에서도 설치가 가능하지만 반대 급부로 디스크 메모리 사용량이 크다.
node_modules를 만들지 않는다.
.zip
형태로 압축해 ./yarn/cache
폴더에 저장한다.pnp.cjs
파일에 저장한다.hardLink
로 연결될 뿐이므로