feat: support pnpm v11 by downloading from GitHub releases - #12
Conversation
pnpm v11 stable ships native per-platform executables too, they are just published under a different naming scheme than v12+: v11: @pnpm/<os>-<arch> (macos/win names, linuxstatic-<arch> for musl) v12+: @pnpm/exe.<os>-<arch> (with a -musl suffix on Linux) The action previously only queried the v12 names, so it rejected v11 with an inaccurate "pnpm 11 is a Node.js program" message. Lower the floor to v11 and select the executable package by resolved major. The version is now resolved first (against the authoritative `pnpm` packument) so the major is known before the per-platform package is chosen. Tarball layout is identical across both schemes, so download/extract is unchanged. Caveat: pnpm v11 publishes no native binary for Intel macOS (darwin-x64); that combination errors clearly and points users to v12+. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 54 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe action now supports pnpm v11+ self-contained binaries from GitHub releases, authenticated release lookups, SHA-256 verification, platform-specific archive extraction, updated compatibility documentation, and expanded CI coverage. ChangesRelease-based pnpm installation
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant GitHubAction
participant PnpmResolver
participant GitHubReleases
participant LocalRunner
GitHubAction->>PnpmResolver: version and token
PnpmResolver->>GitHubReleases: request release metadata
GitHubReleases-->>PnpmResolver: archive URL and SHA-256 digest
PnpmResolver->>LocalRunner: resolved archive
LocalRunner->>LocalRunner: verify, extract, and link pnpm
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The integration workflow only exercised pnpm 12. Add two jobs for the new v11 path: - smoke-v11: downloads pnpm 11 across ubuntu (x64/arm64), macOS (arm64), and Windows, asserting the v11 `@pnpm/<os>-<arch>` package resolves and pnpm lands on PATH. No Intel-macOS entry — v11 ships no darwin-x64 binary. - runtime-node-pnpm11: installs pnpm 11, a node runtime via `pnpm runtime`, and runs `pnpm install` — validating the load-bearing assumption that `pnpm runtime` works on v11. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Replace the npm-registry download with pnpm's GitHub release archives, which
carry a single self-contained binary per platform (`pnpm-<os>-<arch>.tar.gz`,
`pnpm-win32-<arch>.zip`). This unifies v11 and v12 under one code path and
fixes v11 support: v11's npm `@pnpm/<os>-<arch>` packages are only Node-SEA
launchers that need the JS `dist/` shipped separately in the main `@pnpm/exe`
package, so downloading a single npm package produced a broken install (CI
caught `Cannot find module dist/pnpm.mjs`). The GitHub archive bundles the
launcher and its `dist/` together, so extracting it yields a working layout.
Integrity is preserved: GitHub exposes a per-asset SHA-256 `digest` via the
releases API, which the action now verifies (replacing the npm sha512 check).
A `token` input (default `${{ github.token }}`) authenticates the API lookup
to avoid the anonymous rate limit.
Verified end-to-end on linux-x64 for 11.17.0, 12.0.0-alpha.21, ^11, and
next-12 (download + sha256 + extract + `pnpm --version` + pnpx dispatch);
pre-v11 is rejected by the floor.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ase error Some pnpm prereleases (e.g. 12.0.0-alpha.19) are published to npm but have no GitHub release, so they can't be downloaded as binaries. The test workflow pinned alpha.19 throughout; move it to alpha.21, which has a release. Also make fetchRelease turn the API 404 into an actionable error instead of a generic "empty response". Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
PR Summary by QodoSupport pnpm v11 by downloading self-contained archives from GitHub releases
AI Description
Diagram
High-Level Assessment
Files changed (7)
|
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/install-pnpm/download.ts`:
- Around line 59-62: Make the Intel macOS guidance conditional in the
no-release-asset error within the download flow: append the pnpm v11 darwin-x64
note only when the current platform is darwin-x64, while keeping the generic
pnpm/version/asset error for Windows, Linux, and other platforms.
- Around line 150-168: Update fetchRelease to reject every non-success HTTP
response, not only 404, before returning response.result. Preserve the existing
specialized 404 message, and for statuses such as 401, 403, and 5xx throw a
clear error including the status and available GitHub error details so
resolvePnpm never receives a non-GitHubRelease payload.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 464c9db8-69c4-4317-9595-672b1934210a
⛔ Files ignored due to path filters (1)
dist/index.jsis excluded by!**/dist/**
📒 Files selected for processing (6)
.github/workflows/test.yamlREADME.mdaction.ymlsrc/inputs/index.tssrc/install-pnpm/download.tssrc/install-pnpm/run.ts
📜 Review details
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2026-05-11T16:19:49.450Z
Learnt from: zkochan
Repo: pnpm/setup PR: 1
File: src/cache-restore/run.ts:35-35
Timestamp: 2026-05-11T16:19:49.450Z
Learning: When using `actions/exec` (`getExecOutput` / `exec`), it is valid for the `commandLine` option to include both the command and its arguments in a single string (e.g., `getExecOutput('pnpm store path --silent')`). The library tokenizes `commandLine` internally (via `argStringToArray()`), so this behaves like passing an equivalent command + args array (e.g., `getExecOutput('pnpm', ['store','path','--silent'])`). In code reviews, do not flag this as incorrect—this matches documented behavior and a production-tested pattern.
Applied to files:
src/install-pnpm/run.tssrc/install-pnpm/download.tssrc/inputs/index.ts
🪛 LanguageTool
README.md
[uncategorized] ~25-~25: The official name of this software platform is spelled with a capital “H”.
Context: ...hecksum via the GitHub API. Defaults to ${{ github.token }}, which lifts the low anonymou...
(GITHUB)
🪛 zizmor (1.26.1)
.github/workflows/test.yaml
[warning] 72-72: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[warning] 105-105: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
🔇 Additional comments (11)
README.md (1)
5-25: LGTM!Also applies to: 113-113
.github/workflows/test.yaml (1)
23-29: LGTM!Also applies to: 59-156, 228-228, 269-269, 285-285, 310-310, 367-367, 412-412, 449-449, 459-459, 486-486
action.yml (1)
11-12: LGTM!Also applies to: 62-68
src/inputs/index.ts (1)
21-21: LGTM!Also applies to: 62-62
src/install-pnpm/download.ts (6)
5-46: LGTM!
47-58: LGTM!Also applies to: 63-72
82-115: LGTM!
117-148: LGTM!
170-204: LGTM!
213-246: LGTM!src/install-pnpm/run.ts (1)
17-21: LGTM!
…ase lookups - The "no Intel-macOS binary" hint was appended to every platform's no-asset error; show it only on darwin-x64, else point to the release page. - fetchRelease treated any non-404 with a JSON body as success, so a 403 rate-limit / 401 / 5xx slipped through and later threw an opaque TypeError on `release.assets`. Reject every non-200 with a clear HTTP-status error. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/install-pnpm/download.ts`:
- Around line 60-64: Update the isIntelMac condition in the pnpm download error
handling to also require that version is major version 11, so the Intel macOS
upgrade guidance applies only to pnpm v11. Preserve the release-page fallback
for other versions, including v12+.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: f5a4fe34-80d1-4562-a86c-40d6f8e95f6e
⛔ Files ignored due to path filters (1)
dist/index.jsis excluded by!**/dist/**
📒 Files selected for processing (1)
src/install-pnpm/download.ts
📜 Review details
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2026-05-11T16:19:49.450Z
Learnt from: zkochan
Repo: pnpm/setup PR: 1
File: src/cache-restore/run.ts:35-35
Timestamp: 2026-05-11T16:19:49.450Z
Learning: When using `actions/exec` (`getExecOutput` / `exec`), it is valid for the `commandLine` option to include both the command and its arguments in a single string (e.g., `getExecOutput('pnpm store path --silent')`). The library tokenizes `commandLine` internally (via `argStringToArray()`), so this behaves like passing an equivalent command + args array (e.g., `getExecOutput('pnpm', ['store','path','--silent'])`). In code reviews, do not flag this as incorrect—this matches documented behavior and a production-tested pattern.
Applied to files:
src/install-pnpm/download.ts
🔇 Additional comments (1)
src/install-pnpm/download.ts (1)
167-171: LGTM!
v12+ does ship a darwin-x64 binary, so only v11 should suggest upgrading; any other missing-asset case now points to the release page regardless of platform. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
What
Lowers the supported floor to pnpm v11 and switches the download source from the npm registry to pnpm's GitHub releases.
Why the source changed
The original README claimed v11 couldn't be used because it "isn't a standalone executable." Investigating (and CI) showed the real situation is subtler:
@pnpm/<os>-<arch>) they are only Node-SEA launchers thatrequirethe JSdist/shipped separately in the main@pnpm/exepackage. Downloading a single npm package yields a broken install (Cannot find module dist/pnpm.mjs) — caught by CI.pnpm-<os>-<arch>.tar.gz,pnpm-win32-<arch>.zip) bundle the launcher and itsdist/together as one self-contained download, for both v11 and v12, under one consistent naming scheme.So downloading from GitHub releases unifies v11 and v12 under a single code path and Just Works.
Changes
src/install-pnpm/download.ts: resolve version against npm (exact/range/dist-tag), then download the matching self-contained archive from GitHub releases and extract it whole. Integrity is verified against the SHA-256digestGitHub publishes per asset (replacing the previous npm sha512 check).MIN_SUPPORTED_MAJOR12 → 11. Clear error when a resolved version has no GitHub release (some prereleases are npm-only).tokeninput (default${{ github.token }}) authenticates the release API lookup to avoid the anonymous rate limit.README.md/action.yml: describe the GitHub-releases flow; document thetokeninput; note v11 has no Intel-macOS (darwin-x64) binary..github/workflows/test.yaml: add v11 coverage — a cross-OSsmoke-v11job (ubuntu x64/arm64, macOS arm64, Windows) and aruntime-node-pnpm11job (runtime install +pnpm installon v11). Repin v12 test versions fromalpha.19(no GitHub release) toalpha.21.dist/index.js.Verification
CI is fully green (21 jobs): all v11 jobs pass on ubuntu x64/arm64, macOS arm64, and Windows, including
pnpm runtime set+pnpm installon v11; all v12 jobs pass. Locally verified end-to-end for11.17.0,12.0.0-alpha.21,^11, andnext-12(download + sha256 + extract +pnpm --version+ pnpx dispatch); pre-v11 is rejected by the floor.Caveats
darwin-x64) binary — that combination errors clearly and points to v12+. arm64 macOS, Linux (glibc + musl), and Windows are covered on v11.12.0.0-alpha.19) can't be installed and produce an actionable error.🤖 Generated with Claude Code
Summary by CodeRabbit