릴리스 관리

추가된 버전: v11.13.0

pnpm은 별도의 릴리스 도구 없이 자체적으로 워크스페이스의 버전을 지정하고 릴리스할 수 있습니다. 워크플로는 두 부분으로 구성됩니다:

  1. 작업하면서 pnpm change로 변경 의도를 기록합니다. 변경 의도는 .changeset/에 저장되는 작은 마크다운 파일로, 변경이 영향을 주는 패키지, 각 패키지의 버전을 올리는 방식, 그리고 changelog 항목이 될 요약을 담고 있습니다. 이 파일들은 변경 사항과 함께 커밋됩니다.
  2. 릴리스 시에는 인수 없는 pnpm version -r이 대기 중인 의도를 소비합니다. 즉, 워크스페이스 전체의 버전을 올리고, 이를 의존하는 패키지에 전파하며, changelog를 작성하고, 소비한 내용을 커밋되는 원장에 기록합니다.

의도 파일은 changesets 형식을 사용하므로 기존 .changeset/ 디렉터리를 그대로 사용할 수 있습니다. Changesets CLI를 계속 사용하려면 pnpm과 함께 Changesets 사용하기를 참고하세요.

변경 사항 기록하기#

pnpm change

이 명령은 영향을 받는 패키지, 버전 올림 유형, 요약을 입력하도록 요청한 다음 .changeset/calm-cats-resolve.md와 같은 파일을 작성합니다:

---
"@example/core": minor
---

Added a `--watch` flag to the build command.

대기 중인 의도가 어떤 결과를 만들어낼지 확인하려면:

pnpm change status

릴리스하기#

pnpm version -r

이 명령은 릴리스 계획을 적용합니다. 의도에 지정된 모든 패키지의 버전이 올라가며, workspace: 범위를 통해 해당 패키지에 의존하는 모든 패키지의 버전도 함께 올라갑니다. 먼저 --dry-run으로 미리 확인하고, --filter로 범위를 좁히세요.

재귀 실행은 여러 패키지를 서로 다른 버전으로 올릴 수 있으므로 git 커밋이나 태그는 생성되지 않습니다. 태그로 지정할 단일 버전이 없기 때문입니다. 결과를 직접 커밋한 다음 pnpm publish -r로 게시하세요.

첫 릴리스#

v11.16.0부터는 패키지의 첫 릴리스 시 매니페스트에 적힌 버전에서 올리지 않고 그 버전을 그대로 게시합니다. pnpm version -r과 pnpm change status는 각 릴리스의 현재 버전을 레지스트리에서 확인합니다. 해당 버전이 아직 게시되지 않았다면 패키지는 그 버전으로 처음 게시되며, 대기 중인 변경 의도는 다음 릴리스부터 적용됩니다. 따라서 1100.0.0으로 시작하고 minor 의도가 있는 새로 추가된 패키지는 곧바로 1100.1.0으로 건너뛰지 않고 1100.0.0으로 게시됩니다.

환경설정#

릴리스 동작은 pnpm-workspace.yaml의 versioning 키에서 설정합니다:

pnpm-workspace.yaml
versioning:
  fixed:
    - ['@example/cli', '@example/napi']
  ignore:
    - '@example/internal'
  maxBump: minor
  lanes:
    '@example/cli': alpha
  changelog:
    storage: repository

모든 키에 대한 설명은 버전 관리 설정에 있습니다.

두 워크스페이스 프로젝트가 같은 이름으로 게시되는 경우, 이름 대신 ./ 접두사를 붙인 워크스페이스 기준 상대 디렉터리로 프로젝트를 참조할 수 있습니다(예: "./packages/cli"). 이 방식은 의도 파일과 versioning.lanes, versioning.fixed, versioning.ignore에서 사용할 수 있습니다.

고정 그룹#

versioning.fixed에 함께 나열된 패키지는 항상 하나의 공유 버전으로 릴리스됩니다. 이 버전은 그룹 내 가장 높은 현재 버전에 구성원 중 가장 큰 버전 올림을 적용한 것입니다. 고정 그룹은 레인 간에 함께 이동해야 하며, 에픽 안에 전부 포함되거나 전부 제외되어야 합니다.

레인#

레인은 병렬 릴리스 트랙입니다. 패키지가 레인에 있는 동안에는 메인 레인의 모든 패키지의 안정 버전을 릴리스하는 것과 같은 실행에서 X.Y.Z-<lane>.N 프리릴리스를 릴리스합니다. 이를 통해 워크스페이스의 나머지 부분은 계속 배포하면서 재작성이나 메이저 버전 라인을 공개적으로 다듬을 수 있습니다.

pnpm lane alpha --filter @example/cli   # move onto the alpha lane
pnpm lane main --filter @example/cli    # graduate back to stable
pnpm lane                               # show membership

프리릴리스 버전이 계산되는 방식은 pnpm lane을 참고하세요.

에픽#

에픽은 구성원 패키지 그룹을 리드 패키지에 묶어, 모든 구성원의 메이저 버전을 리드의 메이저 버전에서 파생된 범위로 제한합니다. 리드가 메이저 M에 있는 동안 구성원은 M*100 … M*100+99.

pnpm-workspace.yaml
versioning:
  epics:
    - lead: '@example/app'
      packages:
        - './packages/**'
        - '!./packages/private-*'

리드가 11.x이면 구성원은 메이저 1100–1199를 사용합니다. 구성원은 범위 안에서 독립적으로 이동합니다. 패치, 마이너는 물론 범위를 벗어나지 않는 major 의도도 가능합니다. 구성원을 범위 상한 너머로 올리는 버전 올림은 리드가 자신의 메이저 버전을 올릴 때까지 거부됩니다. 릴리스 계획이 리드를 새로운 안정 메이저 버전으로 올리면, 모든 구성원은 같은 계획에서 범위의 하한으로 재설정됩니다.

구성원 여부는 pnpm의 패키지 선택자로 판단합니다. 이름 glob, ./ 접두사가 붙은 디렉터리 glob, ! 접두사가 붙은 부정 패턴을 사용할 수 있습니다. 선택자는 순서대로 평가되며 마지막으로 일치하는 선택자가 결정하므로, 앞선 부정 패턴이 제외한 패키지를 뒤의 포함 패턴이 다시 포함할 수 있습니다. 리드는 자신의 범위에 속한 구성원이 되지 않습니다.

Changelog#

기본적으로(versioning.changelog.storage: registry) CHANGELOG.md는 커밋되지 않습니다. 각 릴리스의 섹션은 게시 시점에 작성되어, 이전에 게시된 버전의 changelog 위에 추가된 상태로 게시되는 tarball에 포함됩니다. 소비된 변경 의도는 해당 버전이 섹션과 함께 게시되었음을 레지스트리에서 확인한 경우에만 이후의 pnpm version -r에 의해 정리됩니다.

대신 모든 패키지에 커밋된 CHANGELOG.md 파일을 유지하려면 versioning.changelog.storage: repository를 설정하세요.

원장#

pnpm version -r은 소비한 모든 의도를 커밋되는 추가 전용 파일인 .changeset/ledger.yaml에 기록합니다:

"@example/core@1.3.0":
  dir: packages/core
  intents:
    - calm-cats-resolve

소비는 프로젝트별로 추적됩니다. 의도 파일은 거기에 지정된 모든 프로젝트가 릴리스된 후에만 삭제됩니다. 이 덕분에 릴리스 브랜치 간의 cherry-pick과 역병합이 안전해집니다. 이미 의도를 소비한 릴리스 브랜치는 커밋이 앞쪽 브랜치로 병합될 때 그 의도를 다시 소비하지 않으며, 레인에 있는 패키지는 아직 안정 릴리스용으로 작성할 내용이 남아 있는 의도를 부분적으로 소비할 수 있습니다.