https://youtu.be/Ds7EjE8Rhjs

비녀의 Package Manager

• 비녀의 Package Manager
  • JS의 import
  • Package 란?
  • NPM의 등장
  • Yarn 의 등장 (yet another resource negotiator)
  • NPM 계열의 한계
  • Pnpm
  • Yarn v2
  • Yarn v2 - Plug’n’Play

JS의 import

• 자바 스크립트 초창기에는 import 나 require 라는 개념을 지원하지 않았다. 더 정확히는 모듈이라는 개념을 자바스크립트에서 지원 하지 않았다.
• 초창기에는 코드량 적어서 모듈로 분리할 필요가 없었다.
• 프론트엔드가 발전을하고 자바스크립트의 코드량이 많아지면서 모듈로 분리할 필요성이 생김

Package 란?

• 모듈들을 뭉쳐놓은 덩어리 하나.
• npm 왈 모듈은 require 라는 node.js 의 도구를 사용해서 불러올 수 있는 것을 모듈이라고 하고 package.json 을 가지고 있는 모듈 혹은 모듈의 뭉치를 전부 다 패키지라고 정의

NPM의 등장

• 패키지들도 코드량이 늘어나면 굉장히 많이 필요하게 된다. 그래서 NPM 등장하면서 이것들을 관리할 수 있게 해주었다.
• NPM 발표
  • 여러 버전의 동일한 패키지를 한 프로젝트에서 사용할 수 있게 하자
  • 설치 방식을 통일하자
  • 패키지 관련 정보가 들어있는 메타 데이터를 간소화 하자
  • 누구나 배포할 수 있도록 하자
• 디렉터리 구조
  • node_modules
    • 설치하고자 하는 패키지들이 다 담겨져 있다.
  • package.json
    • 패키지를 다룰 수 있는 CLI 명령어를 제공하고 그것을 커스텀 할 수 있고 또 거기에 대한 메타데이터들을 제공한다.

Yarn 의 등장 (yet another resource negotiator)

• 페이스북과 구글 개발자들이 모여서 2016 년도에 내놓음
• npm 개선점 으로 개발
  • 병렬화를 통한 속도 개선
    • npm 이 병렬화를 하지 않아서 굉장히 느린 다운로드 속도를 가지고 있었다
  • 자동화된 lock 생성
    • npm 이 지금은 package.lock 이라는 파일을 제공하지만 원래는 shrinkwrap 이라는 메서드를 사용해서 CLI 에 직접 쳐줘야지만 그 파일을 생성해줌
    • yarn 이 자동화된 yarn.lock 파일을 생성하는 기술을 처음 도입해서 npm 도 따라감
  • 의존성 트리 알고리즘 변경
    • npm 은 패키지를 다운로드 받는 순서에 따라서 의존성이 조금씩 변경이 될 수 있는 그런 알고리즘 이였다.
    • yarn 에서는 그것을 제거하고 독자적인 알고리즘을 선택 함으로써 의존성 트리가 덜 변형되도록 하는 그런 알고리즘을 사용
  • 캐시 사용
    • yarn 캐시 파일을 가지고 있어서 다운로드 받았던 것을 기억할 수 있다.
    • 다운로드 속도 개선

NPM 계열의 한계

• 비 효율적 의존성 검색
  • 부모 디렉토리 부터 시작해서 루트 디렉토리까지 순차적으로 node_modules 를 뒤지면서 패키지가 없으면 계속 찾아 나가게 된다.
    • 패키지가 없으면 계속 찾아나가야 하는 단점이 있다.
    • 잘못된 의존성이나 버전이 다른 의존성을 가지고 있어도 그것을 검색해서 사용해 버릴 수 있는 치명적인 단점이 있다.
• 유령 의존성(호이스팅)
• 너무 무거운 node_modules
  • 다운로드를 잘 받았는지 검사하지 않는다
• 이것들을 해결하기 위해서 Pnpm 과 Yarn berry 가 나왔다.

Pnpm

• npm 의 구조를 가져가는데 명확하게 한가지만 변경을 했다.
  • 평타화되지 않은 플랫하지 않은 node_modules 를 사용한다.
• 평타화되지 않아 디렉토리가 복잡하다
• 구조만 보면 덜 효율적이지 않냐라고 생각할 수 있지만 자체적으로 굉장한 알고리즘을 사용하고 있다.
  • Symbolic Link 라고 하는 symlink 기술
  • pnpm store
  • 루트 디렉토리에 pnpm store 라는 레지스트리를 자체적으로 생성해서 pnpm store 에 한 번만 저장을 해서 중복과 디스키 낭비를 막을 수 있다.
  • 실제 프로젝트 node_modules 에는 이걸 연결하는 Symbolic Link 만 달아줘서 pnpm store 에 연결해서 가져오고 만약에 프로젝트 내에서 공유해야 되는 내용이 있다면 그것에 대해서도 Symbolic Link 를 달아서 서로 참조하게 된다

  • 다운로드 수를 줄이고 링크를 사용해서 효과적으로 개선 하려고 한것

    npm 과 yarn 으로 프로젝트 100개를 컴퓨터에 다운을 받는다고 치면 node_modules 가 컴퓨터에 100개 다운 받아지게 될 거다

Yarn v2

• node_modules 개념을 아예 없애버리려고한 움직임을 가지고 있다.
• 일반 Yarn 과 다른게 Yarn2는 yarn set version berry 라는 병령어를 통해서 사용을 할 수 있다.
• node_modules 와 node 에 내장된 의존성 관리 없이 의존성을 관리 하고 싶다.
• 디렉토이에 node_modules 가 없다.
• pnp.cjs 이 생김
• //Cache 디렉토리
  • cache 에 저장되는 것은 zip 인데 파일 패키지를 zip 파일로 저장을 한다.
    • 이점
      1. Zero Install (Yarn install 을 불필요)
      2. 오프라인시에 캐싱기능으로 사용가능
      3. ci 배포시에 clone 만 하면 의존성이 다 있기 때문에 배포 속도를 줄일 수 있다.
      4. 폴더나 파일수가 굉장히 많이 줄어들고 용량도 줄어든다.
• 어떻게 관리하냐가 yarn berry 의 가장 주요한 문제점이었을 것이다 그래서 yarn berry 가 제시한 개념이 있다 -> Plug’n’Play

Yarn v2 - Plug’n’Play

• 직역을 하면 코드만 꼽으면 바로 실행할 수 있다는 뜻
• pnp.cjs
  • 쉽게 얘기하면 일종의 지도
  • 어떤 패키지 인지 명시
  • 어떤 버전 인지 명시
  • 어느 위치에 있는지 명시
  • 어떤 의존을 참조하고 있는지 명시
  • zip 파일들을 pnp.cjs 를 따라서 찾아가면서 yarn berry 가 작동 한다.