패키지 매니저

주차 및 날짜: 2주차 (10/20)
담당자: 황수빈, 가영 이

📦 패키지란?

라이브러리(library)와 유사한 개념

• 라이브러리가 코드의 작성을 위해 사용되는 코드의 묶음이라면, 패키지는 코드의 배포를 위해 사용되는 코드의 묶음이다.
• (따라서 패키지는 경우에 따라 라이브러리를 포함할 수도 있으며, 일반적으로 라이브러리나 실행 파일(executable)을 포함한다.)

👨🏻‍💼 패키지 매니저란?

패키지를 다루는 작업을 편리하고 안전하게 수행하기 위해 사용되는 툴

• 여기서 패키지를 다루는 작업이란 패키지를 설치, 업데이트, 수정, 삭제하는 작업을 의미

📄 package.json이란?

package.json은 프로젝트 정보와 의존성(dependencies)을 관리하는 문서입니다.

우리가 어떤 패키지(오픈소스)를 사용하는지, 어떤 버전을 사용하는지 등을 기록함으로써 어느 곳에서도 동일한 개발 환경을 구축할 수 있게 해줍니다.

👨‍👩‍👧‍👦 의존성이란?

• 많은 패키지들은 다른 패키지가 설치되어 있어야만 제대로 동작한다.
• 이 경우에 기존 패키지를 제대로 동작시키기 위해 필요한 다른 패키지를 'dependency'라고 말한다.

다시 말하자면 ⇒ 패키지를 사용하고자 할 때 dependency에 해당되는 다른 패키지들을 전부 설치해줘야한다

---

👾 npm 이란?

Node Packaged Manager ➡️ Node.js로 만들어진 pakage들을 관리해주는 툴

수정 ⇒

pm은 node package manager의 약자가 아니다. npm의 전신은 사실 pm이라 불리는 bash 유틸리티인데, 이는 pkgmakeinst의 약자다. 그리고 이의 node 버전이 npm인 것이다.

https://github.com/npm/cli#is-npm-an-acronym-for-node-package-manager

npm이 없었을 때는 필요로 하는 기능을 추가하기 위해서 직접 작성하거나 github를 통해 다운로드하여 사용해야 했다. Node.js를 설치하기만 하면(기본적으로 npm은 Node.js 내에 내장) 명령어 한 줄로 기능의 추가가 가능

그렇다면 이렇게 편리한 npm이 있는데 yarn이라는 것은 왜 만들어지게 된 것일까요?

👎🏻 과거 npm의 단점

1. 🔄 의존성 중복

   패키지 설치 시 패키지들을 각각 별도로 설치 → 공유된 의존성이 중복으로 설치될 수 있다. 의존성 트리가 깊어질수록 패키지 설치 속도가 느려지고, 디스크 공간을 많이 차지할 수 있다.

2. ⛔ 일관적이지 않은 패키지 버전

   시맨틱 버저닝 → 모듈간의 버전 불일치로 인해 문제가 발생할 수도 있다.

   • 🔍 자세히 알아보기 노드 모듈들은 기본적으로 시멘틱 버저닝이라는 기법을 사용하여 사용하는 모듈들의 버전을 나타낼 것을 권장. 시멘틱 버저닝이란 간단히 말해 1.2.3 처럼 버전을 세 가지 숫자가 들어갈 수 있는 자리로 구분하고, 각각의 자리에 현재 버전이 이전 버전과 어떤 관계가 있는지 암시하도록 하는 방법입니다. 예를 들어 첫 번째 자리에 들어가는 숫자가 다르면, 두 버전은 이전 버전과 호환되지 않는 완전히 새로운, 메이저 버전이라는 의미입니다. 그러나 이 방식은 장점과 동시에 단점을 함께 가지고 있습니다. 위 사진을 보시면 모듈의 버전에 캐럿 기호(^)가 들어가 있는데, 이는 가장 앞 숫자인 메이저 버전을 제외한 두 자리 (마이너, 패치) 버전까지는 변경을 허용할 수 있다는 의미입니다. 현재 사진 속 바벨 코어의 버전이 ^7.17.9 이므로, 메이저 버전인 7이 변경되지 않는 범위에서는 모듈의 버전이 바뀌는 것을 허용합니다. 7.17.10 버전이나, 7.18.0 버전 등이 모두 사용될 수 있다고 볼 수 있겠네요. 이때 npm install 명령어를 통해 모듈들을 설치하면 해당 메이저 버전 중 최신 버전을 다운받게 됩니다. 빌드에 따라 유연하게 버전을 선택할 수 있다는 장점도 있지만, 이럴 경우 사용하는 모듈간의 버전 불일치로 인해 문제가 발생할 수도 있습니다. 서로 다른 환경에서 하나의 프로젝트를 개발 한다는건 어떤 문제가 발생할지 모르는 잠재적인 위험을 안고 가는 것과 같습니다.
     

3. 🎢 속도 및 성능

   npm은 모듈들을 한 번에 하나씩만 순차적으로 설치 → 설치해야 하는 모듈이 많으면 많을수록, 총 설치 시간이 길어지게 됩니다. 첫 모듈 설치 시간이 길어지면 빌드 및 배포 시간에도 부정적인 영향을 끼치게 됩니다.

4. 🔐 취약한 보안 이슈

   과거의 npm은 잠금 파일이 없었다 → 패키지 설치 시 자동으로 포함된 의존성 패키지가 설치되도록 함

   (하지만 현재는 package-lock.json 을 제공)

5. 🤦🏻 환경에 따라 달라지는 동작

   고정되지 않은 설치 순서 → 개발자의 환경에 따라 모듈들의 설치 순서가 변경될 수 있다. 이미 만들어진 프로젝트에서 모듈을 추가로 설치하게 될 경우, 그 뒤에 명령어를 통해 처음부터 설치하는 사람과 모듈 설치 순서가 달라질 수 있습니다. 내가 어떤 순서로 모듈을 의존성에 추가 했는지에 상관없이, npm은 모듈 이름을 사전 순서대로 정렬하여 순차적으로 설치하기 때문입니다.

---

🧶 yarn

기존의 npm이 가지고 있던 문제점들을 해결하기 위해 등장

🔓 yarn.lock

yarn은 사용할 모듈의 버전을 지정하기 위해 프로젝트에 .lock 파일을 포함

정확한 버전을 지정하고 고정하기 때문에 다른 사용자가 프로젝트를 개발할때 항상 같은 버전의 모듈을 사용할 수 있도록 보장 이 파일 덕분에 기존 npm의 일관적이지 않은 패키지 버전 문제를 해결 가능

🏃🏻속도

yarn은 캐시를 사용하여 한 번 다운로드 한 패키지라면 그 다음부터는 엄청나게 빠른 속도로 설치 가능, 인터넷이 연결되지 않은 환경에서도 설치가 가능(오프라인)

병렬 다운로드를 지원하여 순차적으로 설치해야하는 npm과 달리 모듈들을 한꺼번에 설치 → 속도 ↑

🥊 npm vs yarn

	npm	→	yarn
속도	순차적으로 설치로 인한 긴 소요시간	Ultra Fast(고속), Offline Mode(오프라인모드)	다운로드한 모든 패키지를 캐시화, 병렬화를 통해 리소스 활용률을 극대화
의존성	의존성 중복	Flat Mode(플랫 모드)	중복 항목을 생성하지 않으려면 일치하지 않는 버전의 종속성을 단일 버전으로 해결
신뢰성	일관적이지 않은 패키지 버전	Super Reliable(신뢰성)	잠금 파일 형식을 사용하여 다른 시스템에서도 동일한 방식으로 작동하도록 보장
접근성	별도 설치 X		별도 설치 필요

npm은 기본적인 패키지 매니저이며,

pnpm은 npm의 의존성 문제를 해결한 패키지 매니저다.

yarn은 npm보다 빠른 의존성 설치와 버전 관리를 제공하는 패키지 매니저이며,

yarn berry는 다중 패키지 프로젝트를 위한 기능을 강화한 yarn의 버전이다

---

🫂Pnpm

개념

키워드 : #!flat , #심볼릭 링크 , #디렉토리 레벨

pnpm은 npm의 구조를 가져가는 명확하게 한 가지만 변경을 시켰다.

❤️ 바로 (평탄화 하지 않은) 플랫하지 않은 노드 모듈을 사용하겟다는 것.

위에서 pnpm 디렉토리 확인한 사진들을 보며 의존성들은 어디에 있을까?
node_modules 에는 .pnpm 이라는 하나의 폴더뿐이며 express라는 심볼릭 링크만 있다.

의존성 :
Node.js는 패키지 의존성을 관리하기 위해 package.json 파일에 정의된 의존성 목록을 사용한다. 이 목록은 패키지 이름과 해당 버전을 포함하고 있으며, npm (Node Package Manager) 또는 yarn과 같은 패키지 관리 도구를 사용하여 이 목록에 나열된 의존성을 설치한다.
일반적으로 패키지 관리 도구는 패키지를 node_modules 디렉토리에 설치하여 이 디렉토리에 설치된 패키지는 프로젝트의 코드에서 require 함수를 사용하여 불러올 수 있다.

express 안에 무엇이 있는지?

express 에는 node_modules가 없다? 
express의 모든 의존성들은 어디에?

⭐ 사실 express 가 단지 심볼릭 링크라는 것!

→ 이게 무슨 말이냐… 그니까 Node.js는 actual location을 이용해서 사용된다.
즉, 패키지가 실제 파일 시스템의 복사본이 아닌 원래 위치에서 로드되는 것을 의미한다.

❤️ 심볼릭 링크(Symbolic Link),
일반적으로 "심링크"라고 줄여 부르며 "소프트 링크(Soft Link)" 또는 "심볼릭 링크(Symbolic Link)라 한다. 파일 시스템에서 사용되는 특별한 종류의 파일이며, 다른 파일이나 디렉토리를 가리키는 참조(링크) 역할을 한다.
- 가상 경로 참조:
심볼릭 링크는 다른 파일 또는 디렉토리의 가상 경로를 가리킨다. 즉, 원본 파일이나 디렉토리가 아닌, 그 목적지의 경로를 저장하고 있다.

즉 실제 위치는 아래 사진과 같은 곳에 저장되어 있다!

아 그래서 .pnpm/ 폴더의 목적을 알게 되었다!

우리는 이를 가상 저장소 디렉토리라 부른다.

즉, 내가 이해한 바로는 .pnpm/ 은 가상 저장소 디렉토리?!

→ npm v3,4,5,6 또는 Yarn v1에 의해 생성된 평탄한 node _modules와는 달리 패키지를 격리된 상태로 유지한다.

---

❤️ pnpm에서 node_modules 구조의 두 번째 트릭은 패키지의 의존성들이 의존 패키지의 실제 위치와 동일한 디렉토리 레벨에 있다는 것.

따라서 express의 의존성들은 npm의 의존성 문제를 해결하기 위해 고안된 패키지 매니저로, 고유 설치와 플랫 노드 모듈을 통해 의존성 관리를 최적화한다.

⭐ 무슨 말이냐면, 실제 위치를 프로젝트 루트 디렉토리에서부터 일정한 깊이(기본적으로 .pnpm디렉토리 내)에 저장하며, 이 위치에 대한 심볼릭 링크를 생성한다. 이것은 효율적으로 중복된 의존성을 공유하고 디스크 공간을 절약하는 방식인 것.

예를 들어, express 패키지의 의존성들이 pnpm을 사용하는 경우, 이러한 의존성들은 .pnpm/express@4.17.1/node_modules/ 디렉토리에 저장된다.
그리고 이러한 의존성들은 express 패키지에 대한 심볼릭 링크를 통해 참조된. 이것은 중첩된 의존성이 여러 번 복사되지 않고 효율적으로 관리됨을 의미한다.

결론 : pnpm을 사용하면 디스크 공간을 절약하면서도 패키지 의존성을 효율적으로 관리할 수 있습니다

더 이해하기 쉽게..

만약 여러분이 npm과 yarn으로 프로젝트를 100개를 컴퓨터에 다운을 받는다 치면

노드 모듈이 컴퓨터에 100개가 다운받을 것 → 생각만해도 내 컴퓨터 눈물 줄줄이죠?

근데 pnpm은 이게 불필요하다 생각한거

pnpm을 설치하게 되면 루트 디렉토리에 pnpm store라는 레지스트리를 자체적으로 생성한다.

그래서 거기에 단 한 번만 저장을 하게 된다..? →전역적으로 관리하는 느낌으로 이해했다…

그러면 실제 프로젝트의 node_modules에는 이걸 연결하는 심볼릭 링크만 달아준다. 루트 디렉토리에 있는 pnpm store에 연결해서 가져오면 된다.

---

👤Yarn-berry

개념

키워드 : #Plug’n’Play , #ZipFS , #Zero-Install

배경 :

즉, Node.js를 위한 새로운 패키지 관리 시스템으로, 기존의 npm, yarn v1의 패키지 비효율적인 매니징 방법을 개선하며 빌드 시간을 단축시켜주고 개발 과정에서의 안정성을 높여준다.

❤️ Plug'n'Play (PnP) 방식

유령 의존성 (phantom dependencies) 즉, 어떠한 의존성이 호이스팅을 통해 최상단으로 선언되었다면, 실제로 package.json에 선언되지 않은 패키지임에도 불구하고, 사용할 수 있는 문제점을 유령 의존성이라 한다.
문제점 :
1. package.json에 명시되지 않은 패키지 또한 사용가능해지는 경우가 생긴다.
2. package.json 패키지를 제거했을 경우 의존되는 내용도 함께 사라질 수 있다

yarn은 새로운 전략으로 이 문제를 해결하려 했고, pnp 방식을 선택하였다.

💻 PNP 방식 : 즉시 시작이라는 뜻, 꽂기만 하면 사용할 수 있다 정도로 풀어 쓸 수 있다. 의미는 컴퓨터에 하드웨어를 연결하면 별도의 사용자 조작이나 프로그램 설치 없이 바로 사용할 수 있는 것.

pnp 방식은 어떠한 패키지를 설치하게 되면 더 이상 node_modules에 저장되지 않는다. 대신 .yarn/cache 폴더에 해당 의존성의 정보가 저장되고, .pnp.cjs 파일에 의존성을 찾을 수 있는 정보가 기록된다.

/* prettier 패키지 중에서 */
["prettier", [\
	/* prettier 패키지의 버전이 2.8.8이고 npm 패키지로 등록되어있다. */
        ["npm:2.8.8", {\
        /* 이 위치에 있고 */
          "packageLocation": "./.yarn/cache/prettier-npm-2.8.8-430828a36c-b49e409431.zip/node_modules/prettier/",\
          /* 이 의존성들을 참조한다. */
          "packageDependencies": [\
            ["prettier", "npm:2.8.8"]\
          ],\
          /* 실제 파일 시스템에 복사된다.(해당 패키지가 모듈로 사용되는 모든 위치에서 동일한 내용을 가짐) */
          "linkType": "HARD"\
        }]\
      ]],\

❤️ Zip File System

이제 각 의존성은 Zip 아카이브로 관리된다.
.zip를 활용하여 압도적으로 적은 용량 사용.

.pnp.js에 명시된 정보에 따라서 각 패키지들은 동적으로 참조된다.
해당 방식을 택함으로서 기존의 node_modules 방식 때보다 사용 용량이 획기적으로 줄었다. 또한 기존의 트리형태의 node_modules 폴더를 순회할 필요가 없어졌기 때문에, 검색 속도도 증가!

yarn berry에서 패키지 정보를 zip으로 관리하는 이유는 다음과 같다.

1. 용량 대폭 감소
2. 변경 여부 확인 용이 (zip 파일의 checksum을 확인)
3. 복잡한 구조가 필요 없음.

❤️ Zero-Install

zero install은 말 그대로 설치를 하지 않고 이용하는 방식말한다.

기존에 node_modules에서 모든 디펜던시를 새로 인스톨하려고 하면, 모든 디펜던시 모듈이 인스톨에만 굉장히 많은 시간이 소모하게 되는데
zero install을 이용하면 디펜던시 install에 걸리는 시간을 없앨 수 있기 때문에 CI단이나 배포 파이프 라인에서 반복되는 install 시간을 단축시킬 수 있게 되고 CI 실행시간 및 배포 시간을 대폭 감소 시킬 수 있다.

.pnp.cis : 의존성을 확인할 수 있는 파일

💻 결론 : zero-install을 통해 패키지의 의도하지 않은 호이스팅을 허용하지 않고 + install 시간 감소

---

🧙어떨 때 써야 되는데? (yarn-berry, pnpm)

문득, 초기세팅을 조사하던 중, 그래서 얘네들 개념은 잘 알겠다. 근데 어떨 때 써야 야무지게 쓸 수 있는지...궁금해졌기에 사례들로 같이 알아보자!

많은 글들을 알아본 결과

✨Yarn Berry를 도입하는 이유는 PnP가 99%

기존 방식을 버리고 새롭게 제시한 패러다임은 안정성을 보장할 뿐만 아니라 개발 워크플로우도 개선할 수 있기 때문입니다.
우선 zip 파일을 git으로 관리하기 시작하는 순간, 모두가 같은 버전의 패키지를 사용하는 게 보장됩니다. 각자 네트워크에서 패키지를 다운로드 받는 게 아니라 동일한 파일을 source로 사용하게 때문이죠.

Zip FS 특징은 CI/CD를 구축할 때도 장점으로 작용한다.

배포할 때 구조에 따라 과금 문제로 인해 서버 확장에 제약이 있다.
네트워크에서 패키지를 다운로드 받는 시간이 사라지므로 보통 분 단위로 과금하는 CI/CD 솔루션을 사용할 때 비용 절감 효과를 기대할 수 있습니다.
이런 것보다 나는

🤖 바로 브랜치를 넘나들 때마다 install을 굳이 할 필요가 없어진다는 점입니다.

이 말에서 pnp가 확 와닿았던 것 같다.

그래서 나도 협업 할 때 항상 배포하기 전엔 `npm install i`를 적극활용 했던 기억이..

하지만 PnP 방식에서는 패키지 zip 파일 자체를 버전관리할 수 있게 되어 각 커밋에 맞는 의존성이 생긴다고 이해했다.
어떤 브랜치, 어떤 커밋으로 돌아가도 ‘.yarn/cache’ 폴더에 즉시 사용 가능한 패키지들이 있다!

하지만 이것의 모든 전제는 모든 패키지가 PnP를 지원해야 한다는 점

🤖프로젝트에 PnP를 지원하지 않는 패키지가 하나라도 존재한다면 PnP 방식일지라도 node_modules가 따라온다. 흠...

✨ pnp 적용 문제점

막상 yarn berry 버전에서 pnp을 이용해 보면, 예상과는 다르게 정상적으로 동작하지 않고 디펜던시 관련 에러가 발생 할 것이다.

각 모듈이 pnp로 사용할 수 있으려면, pnp방식에 맞게 의존성 관리가 strict하게 세팅이 되어있어야 한다. 그러나 모든 모듈이 pnp형태에 맞게 호환이 모두 되어있는 상태가 아니기 때문에 pnp를 제대로 사용하기에는 많은 문제들이 발생할 수 밖에 없다.

🤖 이로 인해 Yarn에서도 완전히 strict한 방식 대신, pnp loose 모드를 통해 명시적으로 요구하는 디펜던시를 요구하지 않도록 할 수 있다.
그러나 이는 pnp가 정상적으로 동작하는 것을 보장하지 않는다. 따라서 왠만하면 pnp 모드를 이용하려면 strict 모드로 이용하는 것이 좋다.

각 의존성 모듈이 zip아카이브 파일로 독립적으로 관리가 됨으로써 의존성 트리가 더욱 strict하게 관리가 필요하다.

따라서 pnp형식으로 관리가 될 때는 이러한 의존성 모듈 관리에 대해 문제되는 부분을 모두 해결해 주어야만 정상적으로 pnp방식으로 모듈을 이용할 수 있게 된다.

⭐나의 생각

매번 npm 또는 yarn으로 패키지 환경을 셋팅하면 git clone을 하면 npm install 및 yarn install를 통해 의존성을 관리해야 했지만, 이런 점들이 zero-install로 하지 않아도 된다는 점. 유령 의존성 문제 극복점들은 매우 이상적인 것 같다.

하지만 막상 실제 도입 사례들을 찾아본 결과 느껴지는 단점은 모든 패키지가 PnP를 지원해야 한다는 점인 것 같다.

그래서 실제 적용 사례들을 보며 생각을 해봤다.
Airbridge가 pnpm으로 돌린 이유!

글을 읽어보면 Yarn-berry(PnP)의 문제점을 파악했다.

1. Yarn PnP가 Git에 지속적으로 주는 부하
   Yarn-berry는 node_modules 대신 .yarn/cache에 ZipFS 방식으로 패키지를 압축하여 저장한다. 이는 패키지 설치 시간의 감소와 용량의 감소라는 강력한 장점이 있다.
   하지만 글쓴이는 PnP가 Git에 지속적으로 영향을 줄 수 있겠다는 생각을 했다.

고민은 Airbridge의 커밋 수는 10,000건이 넘는다는 점이었습니다. Airbridge에서 사용하는 패키지 중에서는 바이너리가 포함된 무거운 패키지들이 있습니다. 커밋의 수가 많을 수록, 한 커밋에 포함되는 파일의 용량과 수가 많을 수록, 이후의 작업에서 Git의 체크아웃, 브랜칭 속도에 영향을 줄 수 있겠다는 생각이 들었습니다.
이를 풀기 위해 Git 대용량 파일 저장소(LFS) 내지는 Git 최대 커밋 크기 조정, 주기적으로 Git의 history를 살리면서 파일만 지우는 작업을 하는 것은 정말 오버 엔지니어링이라고 생각했습니다.

혹은 Yarn Workspace의 자잘한 버그들
그리고, 모노레포 내의 패키지들에 얽힌 dependency를 별도로 설치, 관리해야했습니다.
이로 인해 저장 공간을 중복으로 사용하거나 설치 시간이 오래 걸리는 문제가 있었습니다.

그렇다면 pnpm은?

사용후기들도 마찬가지로 찾아보았다.
Javascript 패키지 매니저 pnpm, pnpm이란?, pnpm사용이유, pnpm 설치방법, pnpm 사용방법

실제로 써보니 확실히 더 빠르게 프로젝트를 셋업할 수 있었습니다.
그리고 항상 node_modules 폴더 크기가 너무커서 불필요 프로젝트를 삭제할때마다 시간이 오래걸렸는데,
이 부분도 크게 향상되어서 만족스러웠습니다.

많은 개발자들이 npm, yarn, pnpm 모두 사용해도 좋을 만큼 안정적인 상태에 있다고 평가한다.
확실히
프로젝트 마다 다양한 패키지 매니저를 사용해보고, 성능, 설치 방식 등을 직접 비교해 결정하는 건 어떨까!?
다음 글은 pnpm 실습 글을 가져와보겠습니다~!

레퍼런스

• 평탄한 node_modules가 유일한 방법은 아닙니다. | pnpm
• Plug'n'Play | Yarn