JavaScript 패키지 관리자 비교: Npm vs Yarn vs Pnpm

패키지 관리자 공간에는 세 가지 주요 플레이어가 있습니다.

• npm

• Yarn

• 고성능 npm(pnpm)

실제로 모든 패키지 관리자에 기본적으로 유사한 기능이 구현되어 있으므로 비기능적 요구 사항에 따라 어떤 패키지를 사용할지 결정할 가능성이 높습니다. , 설치 속도, 저장 공간 소비 또는 실용성 등이 있습니다.

물론 각 패키지 관리자를 사용하기 위해 선택하는 방식은 다르지만 모두 기본적으로 일관된 개념을 가지고 있습니다. 위의 모든 패키지 관리자는 다음 명령을 수행할 수 있습니다.

• 데이터 읽기 및 쓰기
• 모든 종속성 일괄 설치 또는 업데이트
• 종속성 추가, 업데이트 및 삭제
• 스크립트 실행
• 패키지
게시

그러나 그럼에도 불구하고 패키지 관리자는 내부적으로 다릅니다. 전통적으로 npm 과 Yarn 플랫 node_modules 폴더에 종속성을 설치했습니다. (여기서 순서에 주의하세요. yarn 먼저 타일링되고 이전에는 npm 재귀적이었습니다.) 그러나 타일링은 일련의 안전 문제를 일으킬 수도 있습니다.

• 의존구조의 불확실성 .

• 평탄화 알고리즘 자체는 매우 복잡 하고 시간이 많이 걸립니다.

• 선언된 종속성이 있는 패키지는

• 여전히 프로젝트에서 불법적으로 액세스 될 수 있습니다.

따라서 pnpm 종속성을 보다 효율적으로 저장하기 위해 node_modules 폴더에 몇 가지 새로운 개념을 도입했습니다. Yarn Berry 더 나아가 node_modules 의 (PnP) 모드를 완전히 포기합니다(자세한 내용은 다른 기사에서 확인하세요).

JavaScript 패키지의 간략한 역사

가장 먼저 출시된 패키지 관리자는 2010년 1월에 npm 이었습니다. 이는 오늘날 패키지 관리자가 작동하는 방식에 대한 핵심 원칙을 확립했습니다. 하지만 npm 10년 넘게 존재했는데 왜 다른 옵션이 있을까요? 이러한 경우가 발생할 수 있는 몇 가지 주요 이유는 다음과 같습니다.

• node_modules 폴더 구조에는 다양한 종속성 해결 알고리즘(중첩 및 타일, node_modules 대 PnP 모드)과
• 다양한 종속성 끌어올리기 방법( hoisting )이 있습니다.
• 다양한 locking 형식(예: yarn 자체로 작성된 것과 같은 다양한 성능)
• 디스크 저장소 패키지 다른 파일 형식(다양한 공간 효율성)
• monorepos 의 유지 관리성과 속도에 영향을 미치는 다중 패키지 프로젝트(일명 workspaces )에 대한 다양한 지원
• 새로운 도구와 명령에 대한 다양한 요구 사항(플러그인 및 커뮤니티 도구를 통한 확장성에 대한 다양한 요구 사항)
• 구성 가능성과 유연성을 다르게

살펴보겠습니다. npm 등장 이후 이러한 측면이 어떻게 결정되었는지, Yarn Classic 이러한 문제 중 일부를 어떻게 해결했는지, pnpm 이러한 개념을 어떻게 확장했는지, Yarn Classic 의 후속 제품인 Yarn Berry 이러한 기존 개념과 프로세스를 어떻게 깨뜨렸는지에 대한 역사입니다.

Pioneer npm

npm 패키지 관리자의 창시자입니다. 많은 사람들이 npm 이 "노드 패키지 관리자"의 약어라고 잘못 믿고 있지만 사실은 그렇지 않습니다.

이전에는 프로젝트 종속성을 수동으로 다운로드하고 관리했기 때문에 이 릴리스는 혁명을 일으켰습니다. npm 파일 및 해당 메타데이터 필드, node_modules 에 종속성 저장, 사용자 정의 스크립트, 공개 및 비공개 패키지 등과 같은 기능을 도입했습니다.

2020년에 GitHub는 npm을 인수했으므로 원칙적으로 npm 이제 Microsoft에서 관리됩니다. 글을 쓰는 시점에서 최신 메이저 버전은 2021년 10월에 출시된 v8이다.

Innovator Yarn Classic

2016년 10월, Facebook은 기존의 npm 일관성 문제를 해결하기 위해 새로운 패키지 관리자(engineering.fb.com/2016/10/11/…)를 개발하기 위해 Google 및 기타 여러 회사와의 파트너십을 발표했습니다. 보안 및 성능 문제. 그들은 대체품의 이름을 Yarn으로 명명했습니다.

Yarn 여전히 npm 의 많은 개념과 프로세스를 기반으로 설계되고 설계되었지만 Yarn 패키지 관리자 분야에 상당한 영향을 미쳤습니다. npm 과 비교하여 Yarn 작업을 병렬화하여 설치 프로세스 속도를 높입니다. 이는 이전 버전 npm 의 주요 문제점이었습니다.

Yarn 읽기 및 쓰기, 보안 및 성능에 대해 더 높은 표준을 설정하고 다음을 포함하여 많은 개념을 발명했습니다(나중에 npm 도 이를 위해 많은 개선을 수행했습니다).

• monorepo 캐싱 지원
,
• 오프라인 다운로드
파일 잠금
• 설치
• ( Locking )

Yarn v1 in 유지 관리 모드 진입 2020. 그 이후로 v1.x 시리즈는 레거시로 간주되어 Yarn Classic 으로 이름이 변경되었습니다. 그 후속 제품인 Yarn v2(Berry)는 이제 더욱 활발한 개발 브랜치입니다.

보다 효율적인 pnpm

버전 1의 pnpm 2017년에 Zoltan Kochan에 의해 출시되었습니다. npm 을 대체하므로 npm 프로젝트가 있으면 바로 pnpm 사용할 수 있습니다!

pnpm 이 만들어진 주된 이유는 npm 과 Yarn 프로젝트 전체에서 사용되는 종속성 저장소 구조 측면에서 매우 중복되기 때문입니다. Yarn Classic npm 에 비해 속도 이점이 있지만 pnpm 과 동일한 종속성 해결 방법을 사용합니다. npm 과 Yarn Classic hoisting 사용하여 node_modules 평면화합니다.

pnpm 이전 구조를 최적화하는 대신 또 다른 종속성 해결 전략을 제안합니다. 컨텐츠 주소 지정 스토리지 구조. 이 방법으로 생성된 node_modules 폴더는 실제로 기본 폴더에 전역적으로 저장되는 ~/.pnpm-store/ 디렉터리에 의존합니다. 각 종속성 버전은 이 디렉터리 폴더에 물리적으로 한 번 저장되어 단일 소스 주소를 형성하여 상당한 디스크 공간을 절약합니다.

node_modules 구조는 symlinks 사용하여 생성된 중첩된 종속 구조입니다(폴더 내의 각 파일/패키지는 하드 링크를 통해 저장됩니다). 공식 문서의 다음 그림은 이를 보여줍니다. (채워질 그림: 소프트 링크와 하드 링크)

pnpm 의 영향력은 2021년 보고서에서 볼 수 있습니다. 콘텐츠 주소 지정이 가능한 스토리지의 혁신으로 인해 경쟁업체는 심볼릭 링크 구조, 패키지의 효율적인 디스크 관리 등 pnpm 개념을 채택하려고 합니다.

Plug'n'Play로 휠을 재창조한 Yarn(v2, Berry)

Yarn 2는 2020년 1월에 출시되었으며 원래 Yarn 에 대한 주요 업그레이드로 청구되었습니다. Yarn 팀은 이를 Yarn Berry 부르며 이것이 본질적으로 새로운 코드 기반과 새로운 원칙을 갖춘 새로운 패키지 관리자라는 점을 더 분명하게 보여줍니다.

Yarn Berry 의 주요 혁신은 node_modules를 복구하기 위한 전략인 플러그 앤 플레이(PnP) 접근 방식입니다. node_modules 생성하는 전략 대신 종속성 조회 테이블이 있는 .pnp.cjs 파일을 생성하세요. 그러면 중첩된 폴더 구조가 아닌 단일 파일이기 때문에 종속성을 보다 효율적으로 처리할 수 있습니다. 또한 각 패키지는 .yarn/cache/ 대신 zip 파일 형태로 폴더에 저장되며 node_modules 보다 디스크 공간을 적게 차지합니다.

이 모든 변화는 너무 빨리 일어나서 출시 후 많은 논란을 불러일으켰습니다. PnP에 대한 이러한 주요 변경 사항은 관리자가 기존 패키지와 호환되도록 업데이트해야 합니다. 기본적으로 새로운 PnP 접근 방식을 사용하고 node_modules 로 되돌리는 것은 처음에는 간단하지 않았기 때문에 많은 유명 개발자가 이를 고려하지 않고 공개적으로 Yarn 2를 비판했습니다.

그 이후 Yarn Berry 팀은 후속 릴리스에서 많은 문제를 해결했습니다. PnP 비호환 문제를 해결하기 위해 팀에서는 기본 작동 모드를 쉽게 변경할 수 있는 방법을 제공했습니다. node_modules 플러그인의 도움으로 기존 node_modules 접근 방식으로 다시 전환하려면 한 줄의 구성만 필요합니다.

또한 JavaScript 생태계는 시간이 지남에 따라 PnP에 대한 지원을 늘려 왔으며 이 호환성 표에서 볼 수 있듯이 일부 대규모 프로젝트에서는 Yarn Berry 채택하기 시작했습니다.

Yarn Berry 아직 초기 단계이지만 이미 패키지 관리자 공간에 영향을 미치고 있습니다. pnpm 2020년 말에 PnP 접근 방식을 채택했습니다.

설치 작업 흐름

패키지 관리자는 먼저 각 개발자의 로컬 및 CI/CD 시스템에 설치되어야 합니다.

npm

npm Node.js 와 함께 제공되므로 추가 단계가 필요하지 않습니다. 운영 체제에 맞는 Node.js 설치 프로그램을 다운로드하는 것 외에도 CLI 도구를 사용하여 소프트웨어 버전을 관리하는 것이 일반적인 관행이 되었습니다. Node의 맥락에서 Node Version Manager(nvm) 또는 Volta는 매우 편리한 유틸리티가 되었습니다.

Yarn Classic 및 Yarn Berry

Yarn 1을 npm 패키지와 같은 다양한 방법으로 설치할 수 있습니다. .$ npm i -g yarn

Yarn Classic에서 Yarn Berry로 마이그레이션하려면 권장 방법은 다음과 같습니다.

• Yarn Classic To로 설치하거나 업데이트합니다.

최신 최신

• 버전

으로 업그레이드하려면

• Yarn set version berry

  명령을 사용하세요

  .

그러나 여기에서 Yarn Berry를 설치하는 데 권장되는 방법은 Corepack을 이용하는 것입니다.

Corepack은 Yarn Berry 개발자가 만들었습니다. 이 이니셔티브는 원래 패키지 관리자 관리자(pmm)로 명명되었으며 LTS v16의 Node와 병합되었습니다.

Corepack의 도움으로 Node는 Yarn Classic , Yarn Berry 및 pnpm 바이너리를 포함하므로 "별도로" 설치할 필요가 없는 npm 의 대체 패키지 관리자입니다. 이러한 shim을 사용하면 사용자는 Yarn 및 pnpm 명령을 먼저 명시적으로 설치하지 않고 노드 배포를 망칠 필요 없이 실행할 수 있습니다.

Corepack에는 Node.js ≥ v16.9.0이 사전 설치되어 있습니다. 그러나 이전 Node 버전의 경우 Corepack을 사용하기 전에 ⬇️

npm install -g corepack을

활성화할 수 있습니다. 이 예에서는 Yarn Berry v3.1.1에서 활성화하는 방법을 보여줍니다.

# 먼저 동의해야 합니다
$ 코어팩 활성화
# 심이 설치되었지만 구체적인 버전을 활성화해야 합니다.
$ corepack prepare [email protected] --activate

pnpm

pnpm npm 패키지로 설치할 수 있습니다: $ npm i -g pnpm . Corepack을 사용하여 pnpm을 설치할 수도 있습니다.

$ corepack prepare [email protected] --activate

프로젝트 구조

이 섹션에서는 다양한 패키지 관리자의 주요 기능을 한 눈에 볼 수 있습니다. 특정 패키지 관리자 구성과 관련된 파일과 설치 단계에서 생성되는 파일을 쉽게 찾을 수 있습니다.

모든 패키지 관리자는 프로젝트 매니페스트 package.json 파일에 모든 중요한 메타 정보를 저장합니다. 또한 루트 수준 구성 파일을 사용하여 다양한 개인 패키지 또는 다양한 종속성 해결 구성을 설정할 수 있습니다.

설치 단계에서 dependencies node_modules 와 같은 파일 구조에 저장되고 locking 파일이 생성됩니다. 이 섹션에서는 작업공간 설정을 고려하지 않으므로 모든 예제에서는 종속성이 저장된 단일 위치만 표시합니다.

npm

$ npm install 또는 더 짧은 $ npm i package-lock.json 파일과 node_modules 폴더를 생성합니다. 루트 수준 디렉터리에 배치할 수 있는 .npmrc 와 같은 구성 가능한 파일도 있습니다. 파일 locking 에 대한 자세한 내용은 다음 섹션을 참조하세요.

.
├── node_modules/
├── .npmrc
├── 패키지-lock.json
└── package.json

yarn을

$ yarn 하면 yarn.lock 파일과 node_modules 폴더가 생성됩니다. .yarnrc 파일은 구성 옵션일 수도 있으며 Yarn Classic 은 .npmrc 파일도 지원합니다. 또는 캐시 폴더 .yarn/cache/ 와 .yarn/releases/ 에 로컬로 저장된 최신 Yarn Classic 버전을 사용할 수 있습니다.

.
├── .yarn/
│ ├── 캐시/
│ └── 발매/
│ └── Yarn-1.22.17.cjs
├── node_modules/
├── .yarnrc
├── 패키지.json
└── Yarn.lock

Yarn berry: node_modules

이 특별한 설치 모드로 인해 Yarn Berry 프로젝트에서는 다른 패키지 관리자보다 더 많은 파일과 폴더를 처리해야 합니다. 일부는 선택사항이고 일부는 필수입니다.

Yarn Berry 더 이상 .npmrc 또는 .yarnrc 지원하지 않으며 .yarnrc.yml이 필요합니다. node_modules 폴더를 생성하는 기존 워크플로의 경우 node_modules 또는 pnpm 구성을 사용하려면 nodeLinker 구성을 제공해야 합니다(이 부분이 이해가 안 됩니다).

# .yarnrc.yml
nodeLinker: node-modules # 또는

$ yarn 실행하는 pnpm은 node_modules 폴더에 모든 종속성을 설치합니다. 그리고 최신 버전이지만 Yarn Classic 과 호환되지 않는 yarn.lock 파일이 생성됩니다. 또한 오프라인 설치를 위해 .yarn/cache/ 폴더가 생성됩니다. 이 폴더는 선택 사항이며 프로젝트에서 사용하는 Yarn Berry 버전을 저장하는 데 사용됩니다.

.
├── .yarn/
│ ├── 캐시/
│ └── 발매/
│ └── 원사-3.1.1.cjs
├── node_modules/
├── .yarnrc.yml
├── 패키지.json
└── Yarn.lock

Yarn berry: pnp

PnP의 Strict 모드이든 Loose 모드이든 .pnp.cjs 및 yarn.lock 사용하여 $ yarn 실행하면 .yarn/cache/ 및 .yarn/unplugged 생성됩니다. PnP strict는 기본 모드입니다. 느슨한 모드를 구성하려면 다음 형식으로 활성화해야 합니다⬇️:

# .yarnrc.yml
노드링커: pnp
pnpMode: Loose

PnP 프로젝트에서는 releases 폴더 외에도 .yarn 폴더에 IDE 지원을 제공하는 sdk/ 폴더도 포함될 가능성이 높습니다. 사용 사례에 따라 .yarn 더 많은 폴더가 포함될 수도 있습니다.

.
├── .yarn/
│ ├── 캐시/
│ ├── 출시/
│ │ └── 원사-3.1.1.cjs
│ ├── SDK/
│ └── 분리됨/
├── .pnp.cjs
├── .pnp.loader.mjs
├── .yarnrc.yml
├── 패키지.json
└── Yarn.lock`

pnpm

는 npm 과 동일하거나 Yarn Classic 프로젝트에도 pnpm 에는 package.json 파일이 필요합니다. $ pnpm i 사용하여 종속성을 설치하면 node_modules 폴더가 생성되지만 해당 내용이 주소 지정 가능한 저장소이므로 구조가 완전히 다릅니다.

pnpm 자체 잠금 파일 pnp-lock.yml 도 생성합니다. 선택적 .npmrc 파일을 사용하여 추가 구성을 제공할 수 있습니다.

.
├── node_modules/
│ └── .pnpm/
├── .npmrc
├── 패키지.json
└── pnpm-lock.yml

잠금 파일 및 종속 저장소

이전 섹션에서 언급했듯이 모든 패키지 관리자는 잠금 파일을 생성합니다.

lock 파일은 프로젝트에서 설치된 모든 종속성의 정확한 버전을 저장하므로 보다 예측 가능하고 결정적인 설치가 가능합니다. 종속 버전은 버전 범위(예: v1.2.5 이상)로 선언될 가능성이 높으며 버전을 "잠그지" 않으면 설치된 실제 버전이 다를 수 있으므로 이 lock 파일은 중요합니다.

잠금 파일은 때때로 체크섬(제가 기억하는 한 해시)을 저장하기도 합니다. 이에 대해서는 보안 섹션에서 더 자세히 다루겠습니다.

npm v5+부터 파일 잠금은 항상 npm ( package-lock.json )의 주요 기능이었습니다. pnpm 에서는 Yarn Berry 의 pnpm-lock.yaml yarn.lock 새로운 YAML 형식으로 나타납니다.

이전 섹션에서는 node_modules 폴더 구조에 종속성을 설치하는 전통적인 접근 방식을 살펴보았습니다. 이는 npm , Yarn Classic 및 pnpm에서 사용되는 솔루션입니다( pnpm 다른 솔루션보다 효율적입니다).

Yarn Berry PnP 모드에서 다른 작업을 수행합니다. node_modules 폴더 대신 종속성은 .yarn/cache/ 및 .pnp.cjs 파일의 조합으로 zip 파일에 저장됩니다.

모든 팀 구성원이 동일한 버전을 설치하여 "당신의 컴퓨터와 내 컴퓨터에서 작동하는" 문제를 해결하므로 이러한 잠금 파일을 버전 제어에 두는 것이 더 좋습니다.

CLI

다음 표에서는 npm , Yarn Classic , Yarn Berry 및 pnpm 에서 사용할 수 있는 다양한 CLI 명령을 비교합니다. 이는 완전한 목록이 아니라 치트 시트입니다. 이 섹션에서는 워크플로 관련 명령을 다루지 않습니다.

npm 과 pnpm 임시 명령과 옵션 별칭이 많이 있습니다. 즉, 명령은 다른 이름을 가질 수 있습니다(예: $ npm install 대 $ npm add ). 또한 많은 명령 옵션에는 --save-dev 대신 -D 와 같은 축약된 버전이 있습니다. 표에서는 모든 축약 버전을 별칭이라고 부릅니다. 이러한 각 패키지 관리자를 사용하여 여러 종속성을 추가, 업데이트 또는 제거할 수 있습니다.

종속성 구성 관리

이 표에는 package.json 에 지정된 모든 종속성을 설치하거나 업데이트하는 데 사용되는 종속성 관리 명령이 포함되어 있습니다.

설치 구성 관리

다음 예에서는 개발 중에 패키지를 관리하는 방법을 보여줍니다. 표에 사용된 용어:

• 패키지: 종속성 또는 바이너리
• 바이너리: node_modules/.bin/ 또는 .yarn/cache/ (PnP)의 실행 도구

Yarn Berry package.json 또는 Expose에서만 실행할 수 있다는 점을 이해하는 것이 중요합니다. bin/ 파일에 지정된 바이너리 파일이 있습니다.

일반 명령 이

표에서는 몇 가지 유용한 내장 명령을 다룹니다. 공식 명령이 없는 경우 일반적으로 npm 패키지 또는 Yarn Berry 플러그인을 통해 타사 명령을 사용할 수 있습니다.

구성 파일

패키지 관리자 구성은 package.json 및 전용 구성 파일에서 수행됩니다.

• 사용할 정확한 버전 정의
• 특정 종속성 해결 전략으로
• 프라이빗 레지스트리 구성
• 패키지 관리자에게 모노레포에서 monorepo

npm을

. 대부분의 구성은 프라이빗 구성 파일 .npmrc 에서 발생합니다.

npm 의 workspaces 기능을 사용하려면 package.json 에 작업 공간 메타데이터 필드를 추가하여 npm에게 하위 프로젝트 또는 작업 공간 폴더를 찾을 수 있는 위치를 알려야 합니다.

// ...
  "작업공간": [
    "후크",
    "유틸리티"
  ]
}

모든 패키지 관리자는 공개 npm 레지스트리를 사용할 수 있습니다. 공개 레지스트리에 게시하지 않고 재사용하고 싶을 수도 있습니다. .npmrc 파일의 레지스트리를 비공개로 구성할 수 있습니다. (기본적으로 이제 모두 비공개 소스를 갖고 있습니다.)

# .npmrc
@doppelmutzi:registry=https://gitlab.doppelmutzi.com/api/v4/projects/41/packages/npm/

npm 에 대한 많은 구성 옵션이 있으므로 문서에서 확인하는 것이 가장 좋습니다.

Yarn

package.json 에서 yarn 의 workspaces 설정할 수 있습니다(비공개 패키지여야 함).

{
  // ...
  "비공개": 사실,
  "작업 공간": ["작업 공간-a", "작업 공간-b"]
}

모든 선택적 구성은 .yarnrc 파일에 들어갑니다. 일반적인 구성 옵션은 yarn-path: 이는 각 팀 구성원이 지정된 바이너리 버전을 사용하도록 강제합니다. yarn-path 특정 Yarn 버전(예: .yarn/releases/ )이 포함된 폴더를 가리킵니다. (classic.yarnpkg.com/en/docs/cli…) 명령을 사용하여 통합 Yarn Classic 버전을 설치할 수 있습니다.

Yarn berry

Yarn Berry 의 workspaces 구성은 Yarn Classic ( package.json )의 구성과 유사합니다. 대부분의 Yarn Berry 구성은 .yarnrc.yml 에서 이루어지며 사용 가능한 구성 옵션이 많이 있습니다.

# .yarnrc.yml
YarnPath: .yarn/releases/yarn-3.1.1.cjs

yarn berry 가져오기 방법 $> yarn plugin import <name> 사용하여 플러그인(yarnpkg.com/cli/plugin/…)을 확장할 수 있습니다. 이 명령은 .yarnrc.yml 도 업데이트됩니다.

# .yarnrc.yml
플러그인:
  - 경로: .yarn/plugins/@yarnpkg/plugin-semver-up.cjs
    spec: "https://raw.githubusercontent.com/tophat/yarn-plugin-semver-up/master/bundles/%40yarnpkg/plugin-semver-up.js"

기록 섹션에서 언급했듯이 호환성 이유로 인해 PnP 엄격 모드에는 종속성과 관련된 몇 가지 문제가 있을 수 있습니다. 이러한 유형의 PnP 문제에 대한 일반적인 솔루션은 패킷 확장 구성 정책입니다.

# .yarnrc.yml
패키지 확장:
  "스타일 구성요소@*":
    종속성:
      React-is: "*"

pnpm

pnpm npm 과 동일한 구성 메커니즘을 사용하므로 .npmrc 파일을 사용할 수 있습니다. 개인 레지스트리 구성도 npm 사용하는 것과 동일하게 작동합니다. pnpm의 작업 공간 기능으로 다중 패키지 프로젝트를 지원할 수 있습니다. monorepo 초기화하려면 pnpm-workspace.yaml 파일에서 패키지 위치를 지정해야 합니다.

# pnpm-workspace.yaml
패키지:
  - '패키지/**'

모노레포

모노레포란?

(실제로 여기에는 단일 웨어하우스와 다중 프로젝트, 단일 웨어하우스와 단일 프로젝트, 다중 웨어하우스와 다중 프로젝트라는 세 가지 개념이 있습니다.)

monorepo 는 여러 프로젝트를 포함하는 저장소입니다. 이러한 프로젝트를 workspace 또는 패키지라고 합니다. 여러 저장소를 사용하는 대신 모든 것을 한 곳에 보관하는 것이 프로젝트 구성 전략입니다.

물론 이로 인해 추가적인 복잡성이 발생합니다. Yarn Classic 이 기능을 처음으로 활성화했지만 이제는 모든 주요 패키지 관리자가 작업 공간 기능을 제공합니다. 이 섹션에서는 다양한 패키지 관리자를 사용하여 작업공간을 구성하는 방법을 보여줍니다.

npm

npm 팀은 v7에서 오랫동안 기다려온 npm 작업 공간 기능을 출시했습니다. 여기에는 루트 패키지에서 다중 패키지 프로젝트를 관리하는 데 도움이 되는 많은 CLI 명령이 포함되어 있습니다. 대부분의 명령은 workspace 관련 옵션과 함께 사용되어 특정 작업 공간, 여러 작업 공간 또는 모든 작업 공간에 대해 실행해야 하는지 npm 알릴 수 있습니다.

# 모든 작업공간에 대한 모든 종속성 설치
$ npm i --작업 공간.
# 하나의 패키지에 대해 실행
$ npm 실행 테스트 --workspace=hooks
# 여러 패키지에 대해 실행
$ npm 실행 테스트 --workspace=hooks --workspace=utils
# 모두에 대해 실행
$ npm 실행 테스트 --workspaces
#테스트가 누락된 모든 패키지 무시
$ npm run test --workspaces --if-present

팁: 다른 패키지 관리자와 비교할 때 npm v8은 현재 고급 필터링이나 여러 작업 공간 관련 명령의 병렬 실행을 지원하지 않습니다.

Yarn

2017년 8월 Yarn 팀은 작업 공간 기능에 대한 monorepo 지원을 발표했습니다. 이전에는 패키지 관리자를 Lerna와 같은 타사 소프트웨어가 포함된 다중 패키지 프로젝트에서만 사용할 수 있었습니다. Yarn 에 대한 이 새로운 추가 기능은 다른 패키지 관리자가 이러한 기능을 구현할 수 있는 길을 열어줍니다.

관심이 있으시면 Lerna 유무에 관계없이 Yarn Classic의 작업 공간 기능을 사용하는 방법을 참조하실 수 있습니다. 하지만 이 문서에서는 Yarn Classic 작업 영역 설정에서 종속성을 관리하는 데 도움이 되는 몇 가지 필수 명령만 소개합니다.

# 모든 작업공간에 대한 모든 종속성 $yarn을 설치합니다. 
# 종속성 트리 표시 $ Yarn 작업 공간 정보 
# 시작하려면 다른 패키지를 실행하세요. $ Yarn Workspace awesome - 패키지 시작
  # 패키지에 Webpack 추가 $ Yarn 작업 공간 awesome - 패키지 추가 - D webpack
  # 모든 패키지에 React 추가 $ Yarn add React -W

Yarn berry

Yarn Berry Yarn Classic 의 개념을 기반으로 구현되었기 때문에 처음부터 작업공간을 특징으로 했습니다. Reddit 댓글에서 Yarn Berry의 수석 개발자는 다음을 포함하여 작업 공간 중심 기능에 대한 간략한 개요를 제공했습니다.

• $ Yarn add --interactive: 패키지를 설치할 때 다른 작업 공간의 버전을 재사용할 수 있습니다.
• $ Yarn up: 모든 작업 공간을 업데이트합니다. 패키지
• $yarn 작업 공간 초점: 단일 작업 영역에만 종속 항목 설치
• $yarn 작업 영역 foreach: 모든 작업 영역에서 명령 실행

Yarn Berry package.json 파일의 dependencies 또는 devDependencies 필드에서 사용할 수 있는 여러 프로토콜을 사용합니다. 그중에는 workspace 프로토콜이 있습니다.

Yarn Classic 의 작업공간과 달리 Yarn Berry 종속성이 이 monorepo 의 패키지 중 하나여야 함을 명확하게 정의합니다. 그렇지 않고 버전이 일치하지 않으면 Yarn Berry 원격 레지스트리에서 해당 버전을 가져오려고 시도할 수 있습니다.

{
  // ...
  "종속성": {
    "@doppelmutzi/hooks": "작업 공간:*",
    "http-서버": "14.0.0",
    // ...
  }  
}

pnpm

workspace 프로토콜을 통해 pnpm Yarn Berry 와 유사한 monorepo 프로젝트에 기여했습니다. 많은 pnpm 명령은 monorepo 컨텍스트에서 특히 유용한 --recursive (-r) 또는 --filter 옵션을 허용합니다. 기본 필터링 명령도 Lerna 를 훌륭하게 보완합니다.

# 모든 작업 공간을 정리합니다  
pnpm -r exec -- rm -rf node_modules && rm pnpm-lock.yaml  
# 범위가 @doppelmutzi인 모든 작업 공간에 대해 모든 테스트를 실행합니다.
pnpm 재귀 실행 테스트 --filter @doppelmutzi/`

성능 및 디스크 효율성

성능은 선택 결정의 핵심 부분입니다. 이 섹션에서는 중소규모 프로젝트를 기반으로 한 벤치마크를 제시합니다. 다음은 샘플 프로젝트에 대한 몇 가지 참고 사항입니다.

• 두 벤치마크 세트 모두 작업 공간 기능을 사용하지 않습니다.
• 소규모 프로젝트는 33개의 종속성을 지정합니다.
• 중형 프로젝트는

3가지 사용 사례(UC)를 사용하여 각 패키지 관리자 변형을 한 번 측정했습니다. 자세한 평가 및 설명은 프로젝트 1(P1)과 프로젝트 2(P2)의 결과를 확인하시기 바랍니다.

• UC 1: 캐시/저장소 없음, 잠금 파일 없음, node_modules 또는 .pnp.cjs 없음
• UC 2: 캐시/저장소 있음, 잠금 파일 없음, node_modules 또는 .pnp.cjs 없음
• UC 3: 캐시/저장소 있음, 잠금 파일 있음, node_modules 또는 .pnp.cjs 없이

gnomon 도구를 사용하여 설치에 소요되는 시간을 측정했습니다( yarn | gnomon ). 또한 생성된 파일 $ du -sh node_modules 의 크기를 측정했습니다.

안전

npm

npm 잘못된 패키지를 처리할 때 너무 관대하며 많은 프로젝트에 직접적인 영향을 미치는 몇 가지 보안 취약점에 직면했습니다. 예를 들어 버전 5.7.0에서는 Linux 운영 체제에서 sudo npm 명령을 실행하면 시스템 파일의 소유권을 변경하여 운영 체제를 사용할 수 없게 만들 수 있습니다.

2018년에는 비트코인 ​​도난과 관련된 또 다른 사건이 발생했습니다. Node.js 패키지 EventStream은 3.3.6 버전에 악성 종속성을 추가했습니다. 이 악성 패키지에는 개발자의 컴퓨터에서 비트코인을 훔치려는 암호화 방법이 포함되어 있습니다.

이러한 문제를 해결하기 위해 새로운 npm 버전은 암호화 알고리즘을 사용하여 설치된 패키지의 무결성을 확인합니다. SHA-512.

Yarn

Yarn Classic 및 Yarn Berry 체크섬을 사용하여 처음부터 모든 패키지의 무결성을 확인합니다. Yarn 또한 package.json 에 선언되지 않은 악성 패키지를 검색하지 못하도록 시도합니다. 불일치가 발견되면 설치가 중단됩니다.

PnP 모드의 Yarn Berry 기존 node_modules 방법의 보안 문제가 없습니다. Yarn Classic 과 비교하여 Yarn Berry 명령 실행 보안을 향상시킵니다. package.json 에 선언된 패키지만 실행할 수 있습니다. 이 보안 기능은 아래에서 설명하는 pnpm 과 유사합니다.

pnpm

pnpm 코드를 실행하기 전에 설치된 각 패키지의 무결성을 확인하기 위해 여전히 체크섬을 사용합니다.

위에서 언급했듯이 npm 과 Yarn Classic 모두 프로모션으로 인해 보안 문제가 있습니다. pnpm 관리 모델이 권한 상승을 사용하지 않고 중첩된 node_modules 폴더를 생성하여 불법 종속성 액세스의 위험을 제거하므로 이러한 상황을 방지합니다. 이는 종속성이 .package.json 에 선언되었음을 의미합니다.

우리가 논의한 것처럼 이는 monorepo 설정에서 특히 중요합니다. 알고리즘을 부스팅하면 때때로 종속성 비결정론이 발생할 수 있기 때문입니다.

인기 있는 프로젝트 사용법

결론적으로

다양한 패키지 관리자의 원칙에는 실제로 큰 차이가 있습니다.

pnpm pnpm CLI 사용이 비슷하지만 종속성을 관리하는 것은 매우 다르다는 점에서 npm 처럼 보입니다. Yarn Classic 여전히 ​​인기가 있지만 레거시 소프트웨어로 간주되며 가까운 시일 내에 지원이 중단 될 수 있습니다. Yarn Berry PnP 는 새롭지 만 패키지 관리자 세계에 혁명을 일으킬 가능성은 아직 실현되지 않았습니다.

수년에 걸쳐 많은 사용자들이 누가 어떤 패키지 관리자를 사용하는지 물었고, 전체 사람들은 Yarn Berry PnP 의 성숙도와 채택에 특히 관심이있는 것 같습니다.

이 기사의 목적은 직접 사용할 패키지 관리자를 결정하는 여러 관점을 제공하는 것입니다. 특정 패키지 관리자를 추천하지 않는다는 점을 지적하고 싶습니다. 다른 요구 사항을 평가하는 방법에 따라 다르므로 여전히 원하는 것을 선택할 수 있습니다!

영어 원본 주소 : https://blog.logrocket.com/javaScript-package-managers-compared/