[자바스크립트] 패키지 매니저 정리(npm, yarn, yarn berry, pnpm)

패키지 매니저란?

• 프로젝트가 의존하고 있는 라이브러리와 같은 패키지들을 설치하고 관리할 수 있도록 도와주는 프로그램이다.
• 아무리 간단한 프로그램이어도 수십개 이상의 다른 패키지들에 의존하게 되고 이 패키지들은 빈번하게 업데이트 되기 때문에 패키지 매니저를 통해 일괄 관리할 필요가 있다.

패키지 매니저 비교

npm(Node Package Manager)

• Node.js의 표준 패키지 매니저로 Node.js를 설치하면 자동으로 설치된다.

npx(Node Package Runner)

• npm에서 제공해주는 도구
• 프로젝트에 영구적으로 필요한 의존성 패키지나 개발 의존성 패키지들이 아니라, 특정 환경을 구성하거나 특정 작업을 수행하는 시점에만 필요한 패키지들을 설치하고 실행한 후 삭제 과정을 자동으로 진행해주는 도구

Yarn(Yet Another Resource Negotiator)

Yarn classic(Yarn 1)

• npm의 단점을 개선한 패키지 매니저
• yarn은 다운 받은 패키지 데이터를 캐시(cache)에 저장하여 중복된 데이터는 다운로드 하지 않으며 패키지를 병렬적으로 설치하기 때문에 속도가 빠르다.

	npm	yarn
설치방식	순차적 설치	병렬적 설치
접근성	node.js와 함께 자동 설치	별도 설치
보안	package-lock.json 파일 자동 생성 및 업데이트	yarn.lock 파일 자동 생성 및 업데이트
로그	출력 로그가 방대하다.	비교적 깔끔하다.

• npm 출력 로그

• yarn 출력 로그

• 이전에는 npm의 경우 패키지 설치시 자동으로 포함된 의존성 패키지까지 설치하여 보안 문제에 있어서 취약점이 있었으나 현재는 npm도 package-lock.json이라는 잠금 파일을 제공하고 속도면에서도 개선이 많이 되어 눈에 띄는 차이는 없다고 한다.

현재는 yarn classic의 유지보수가 중단되었고 새로운 기능이나 버그 픽스는 yarn berry(yarn 2)에서 이루어진다.

yarn classic의 한계

node_modules 관리의 비효율

• npm과 yarn은 모두 node_modules 폴더에서 모든 의존성을 관리하기 때문에 매우 큰 메모리 공간을 사용하게 되고 이 구조를 만들기 위해 많은 메모리 I/O가 필요하다.

유령 의존성

• 위와 같은 비효율을 줄이기 위해 호이스팅 기법을 사용하는데 이 때문에 직접 의존하고 있지 않은 모듈을 require() 할 수 있는 현상이 나타난다.

Yarn berry(Yarn 2)

• Facebook에서 발표한 yarn의 두 번째 버전이다.
• 유령 의존성에 관한 문제를 해결하기 위해 Plug'n'Play(PnP) 라는 새로운 패키지 관리 방식을 사용한다.

Plug'n'Play(PnP)

• 패키지들에 대한 의존성 정보는 .zip 파일로 압축하여 .yarn/cache 폴더에 저장하고 이를 찾기 위한 정보를 .pnp.cjs 파일에 기록한다.
• pnp.cjs 를 이용함으로써 별도의 디스크 I/O 작업 없이 패키지의 정보와 위치를 파악할 수 있다.

# .pnp.cjs
# react 패키지 중 npm:17.0.1 버전의 위치와 의존성 정보
["react", [
  ["npm:17.0.1", {
    "packageLocation": "./.yarn/cache/react-npm-17.0.1-98658812fc-a76d86ec97.zip/node_modules/react/",
    "packageDependencies": [
      ["loose-envify", "npm:1.4.0"],
      ["object-assign", "npm:4.1.1"]
    ],
  }]
]],

zero-install

• PnP의 장점으로 무거운 node_modules를 제거함으로써 의존성까지 github에 올릴 수 있게 되었다.
• 이전에는 .gitignore에 node_modules를 포함시키고 package.json에 기록된 것을 각자 로컬에서 다운받는 방식이었다면 zero-install 방식으로 별도의 설치 없이(yarn install 없이) 바로 사용할 수 있다.
• 위와 같은 이유로 브랜치 변경시에도 yarn install 없이 프로젝트를 실행할 수 있고 CI에서도 의존성을 설치할 필요가 없으므로 CI 시간을 크게 절약할 수 있다.

CI(Continuous Integration) : 개발자를 위한 자동화 프로세스로 빌드 및 테스트의 자동화를 의미

pnpm(Performant npm)

• pnpm은 npm을 개선하여 다양한 기능 향상이 이루어진 대체품으로 npm만 있다면 바로 사용할 수 있다.
• 따라서 npm과 사용법이 비슷하지만 불필요한 I/O과정을 없애 빠르고 효율적이며 패키지 중복 설치를 하지 않아서 사용 용량이 적다.

npm과 yarn의 비효율을 개선한 노드 패키지 매니저

• npm과 yarn은 여러 프로젝트에서 같은 의존성을 사용하는 경우 프로젝트 각각의 node_modules 디렉토리에 라이브러리를 모두 설치한다.
• lodash를 사용하는 패키지가 100개 있다고 가정하였을 때 각 폴더별로 lodash 패키지가 100개 복사되는 것이다.

content-addressable strorage

• 반면에 pnpm은 홈 디렉토리의 글로벌 저장소인 ~/.pnpm-store 에 모든 패키지를 저장하는 전역 저장소(Virtual Store)를 두어서 패키지를 공유하는 구조이다.
• 패키지를 설치할 때 package.json에 명시된 패키지를 읽은 후 node_modules에 심링크(Symbolic link)를 생성하여 전역 저장소에 있는 패키지를 참조하는 형식이다.
• 이 방식을 통해 같은 패키지는 단 한 번만 설치하여 효율적으로 패키지를 관리한다.
• 같은 패키지이지만 다른 버전의 라이브러리를 사용하는 경우에는 기존 패키지를 건드리지 않고 다른 버전의 라이브러리만 새롭게 추가하여 버전 호환 문제에서도 자유롭다.

마무리

• npm보다 속도와 보안을 개선해서 yarn이 등장하였지만 요즘에는 npm도 package-lock.json에서 패키지의 무결성을 확인하며 속도면에서도 개선이 이루어졌다.
• yarn-berry를 사용할 경우, 협업에 있어서 각자 네트워크에서 패키지를 다운로드 받는 게 아니라 동일한 파일을 source로 사용하기 때문에 같은 개발 환경을 공유하는 것이 보장이 된다. 그러나 아직 PnP를 지원하지 않는 패키지가 존재하기 때문에 이러한 패키지에 의존하는 순간 node_modules가 따라오게 되어 장점을 누릴 수 없게 된다.
• pnpm은 npm과 사용법이 비슷하고 yarn1/2와 npm의 핵심기능을 모두 지원하며 종속성 관리 측면에서 좀 더 개선되었다는 장점이 있으나 국내 사용량이 적어서 레퍼런스가 적다는 단점도 있다.
• 서비스의 규모가 커져서 모노레포 환경을 구축하는 경우에는 pnpm을 사용하면 디스크 공간을 절약할 수 있으며 peer-dependency를 명시해야 한다는 제약사항 덕분에 더 안정적이라고 한다!

모노레포 : 같은 레포지토리에서 서로 다른 프로젝트들을 관리하는 소프트웨어 개발 전략. 다양한 프로젝트 FE 코드를 한 곳에서 관리함으로써 코드 재사용, 외부 의존성 관리, 리팩토링 측면에서 장점이 있다!

---

참고 자료

• npm? yarn? 그 차이가 뭐길래...
• [프론트엔드][번역] npm vs yarn
• yarn berry 적용 및 ECS 배포 방식 변경을 통해 빌드/배포 속도 개선하기
• Yarn Berry
• Yarn Berry, 굳이 도입해야 할까?
• Mono Repo & yarn Berry
• [패키지 매니저] npm, yarn, pnpm, yarn-berry - 댓글도 아주 유용
• [우아콘 2022] 우리는 하나다! 모노레포 with pnpm
• npm, yarn, pnpm 비교해보기