기타 패키지 관리자

추가된 버전: v12.0.0-rc.6 (pnpm v12 전용)

pnpm은 자기 자신뿐만 아니라 다른 패키지 관리자도 설치합니다: npm, Yarn Classic, Yarn Berry, Yarn 6(yarnpkg/zpm), Bun. 레지스트리에 게시된 npm 기반 패키지 관리자는 신뢰할 수 있는 패키지 관리자 레지스트리를 통해 해석되고 가져와지며, 해당 버전이 실행되기 전에 정확한 버전에 대한 npm의 서명으로 검증됩니다 — 이는 pnpm이 묻지 않고 자체 버전을 전환할 수 있게 하는 것과 같은 기준입니다. 반면 Yarn 6과 Bun은 각 프로젝트에서 제공하는 플랫폼 아카이브로 배포되며, 게시자 체크섬으로 고정됩니다.

Node.js가 없는 머신의 JavaScript 패키지 관리자는 실행을 위해 관리되는 LTS 런타임을 제공받으므로, 이 중 어느 것도 직접 Node.js를 설치할 필요가 없습니다.

이 기능을 사용하는 곳은 세 가지입니다:

• git 호스팅 종속성은 해당 종속성이 요구하는 패키지 관리자로 준비됩니다 — Preparing a git-hosted dependency를 참고하세요;
• pnpm dlx(pnx)는 단일 명령에 대해 패키지 관리자를 실행합니다;
• pnpm shim add는 현재 프로젝트가 고정한 버전을 실행하는 명령을 링크합니다.

각 패키지 관리자의 출처#

레지스트리에 게시된 패키지 관리자는 pnpm 자체 엔진과 동일한 해석, 검증, 설치 파이프라인을 거칩니다. 플랫폼 아카이브로 배포되는 패키지 관리자는 관리형 런타임과 마찬가지로 게시자 체크섬으로 고정됩니다.

각 패키지 관리자는 pnpm 홈 아래의 자체 환경 lockfile로 해석되므로, 한 패키지 관리자의 고정이 다른 패키지 관리자의 고정을 덮어쓰지 않습니다.

프로젝트의 패키지 관리자 선언하기#

pnpm add에서 패키지 관리자를 지정하면 같은 이름의 npm 패키지를 설치하는 대신 프로젝트가 사용하는 패키지 관리자를 기록합니다:

pnpm add yarn@4

선언은 패키지 관리자가 읽는 위치에 기록됩니다:

• Yarn은 정확한 버전만 허용하는 packageManager 필드를 통한 프로젝트 고정으로 시작됩니다. 따라서 요청된 계열은 기록되기 전에 해석됩니다: pnpm add yarn@4는 "packageManager": "yarn@4.18.0"을 기록합니다. 고정된 아티팩트가 npm tarball인 Yarn Classic 계열(<2)에서는 값에 해당 tarball의 +sha512.… integrity도 포함됩니다 — "packageManager": "yarn@1.22.22+sha512.…".
• 그 외 모든 패키지 관리자는 범위를 담는 devEngines.packageManager에 기록됩니다.

두 필드 중 하나만 남습니다: 두 필드는 같은 것을 선언하며, 두 선언이 일치하지 않는 프로젝트는 버전 전환 도구가 실행을 거부하기 때문입니다.

{
  "devEngines": {
    "packageManager": {
      "name": "npm",
      "version": "^11.0.0"
    }
  }
}

다음 두 가지는 의도적으로 이 기능의 대상이 아닙니다:

• pnpm 자체. pnpm의 자체 고정을 변경하면 다음 명령에서 실행 중인 CLI가 전환되므로, 이는 add의 부수 효과가 아니라 pnpm self-update가 의도적으로 수행해야 하는 작업입니다.
• 필터링된 선택. 프로젝트가 사용하는 패키지 관리자는 해당 프로젝트 자체의 선언이므로, pnpm add yarn --filter …는 ERR_PNPM_PACKAGE_MANAGER_IN_SELECTION으로 실패합니다. 프로젝트 자체에서 명령을 실행하세요.

릴리스된 버전을 요청하는 대신 패키지의 위치를 지정하는 지정자는 여전히 지정한 대상을 일반 종속성으로 설치합니다:

pnpm add yarn@npm:yarn@1.22.22
pnpm add yarn@yarnpkg/berry

해석된 버전이 pnpm-lock.yaml에 기록되지 않는 것은 pnpm 이외의 패키지 관리자의 경우입니다: 해당 버전은 pnpm 홈 아래의 자체 환경 lockfile에 고정됩니다. 프로젝트의 lockfile에는 pnpm 자체의 고정만 packageManagerDependencies 아래에 기록됩니다.

런타임#

pnpm add는 런타임에도 같은 규칙을 따릅니다: node 또는 deno를 지정하면 명시적인 node@runtime:22 표기가 이미 그랬던 것처럼 engines.runtime 아래에 기록됩니다.

bun은 런타임이자 패키지 관리자이며, 패키지 관리자가 먼저 응답합니다: pnpm add bun은 이를 프로젝트의 패키지 관리자로 선언합니다. 런타임으로 추가하려면 런타임을 요청하세요 — pnpm add bun@runtime:1.3.0.

전역으로 설치하기#

pnpm add -g yarn

는 npm의 Classic 전용 yarn 패키지가 아니라 현재 Yarn 계열을 설치하며, pnpm add -g node@22 / pnpm add -g deno@2는 런타임을 다운로드하는 래퍼 패키지가 아니라 해당 Node.js 또는 Deno 릴리스를 설치합니다.

전역으로 설치된 패키지 관리자도 전역으로 설치된 Node.js가 이미 devEngines.runtime을 따르는 것처럼 프로젝트의 고정을 따릅니다: 프로젝트가 버전을 고정한 곳에서는 고정된 버전이 실행되고, 그 외의 모든 곳에서는 전역으로 설치된 사본이 대체로 사용됩니다. 이미 결정한 경우가 아니라면 pnpm은 패키지 관리자에 대한 globalShims 항목을 추가하여 이를 기록합니다 — false를 포함한 명시적 항목은 설정한 그대로 유지됩니다.

버전이 선택되는 방식과 pnpm이 확인을 요청하는 경우에 대해서는 Project-aware global bins를 참고하세요.

단일 명령에 대해 실행하기#

pnx yarn@4 install
pnx npm@11 ci
pnx bun@1.3.0 install

Running a package manager or a runtime을 참고하세요.

Git 호스팅 종속성 준비하기#

설치하기 전에 빌드해야 하는 git 호스팅 종속성은 호스트에 우연히 있는 패키지 관리자가 아니라 해당 종속성이 요구하는 패키지 관리자로 준비됩니다:

• 해당 종속성의 packageManager / devEngines.packageManager 고정이 적용됩니다;
• 고정이 없으면 종속성이 포함한 lockfile이 패키지 관리자를 지정합니다 — 그리고 Yarn Classic이 작성한 yarn.lock은 더 이상 Yarn Berry로 설치되지 않습니다. Berry는 작성하는 모든 lockfile에 __metadata:를 기록하며 두 계열은 서로의 lockfile을 읽을 수 없으므로, 어느 쪽이 작성했는지는 선호가 아니라 제약 조건입니다.

종속성이 버전을 고정했거나 호스트가 종속성의 요구 사항을 충족할 수 없는 경우 pnpm이 해당 패키지 관리자를 제공합니다 — 따라서 Yarn으로 빌드된 저장소도 이제 pnpm만 있는 머신에서 설치되며, 적합한 패키지 관리자를 이미 갖춘 호스트는 자체 패키지 관리자를 계속 사용합니다.

버전 v11에서 넘어오는 프로젝트의 변경 사항#