chore: use pnpm setup runtime action#199
Conversation
|
Reviews (1): Last reviewed commit: "chore: use pnpm setup runtime action" | Re-trigger Greptile |
c759254 to
497ae41
Compare
|
| - name: Set up pnpm | ||
| uses: pnpm/action-setup@fc06bc1257f339d1d5d8b3a19a8cae5388b55320 # v5.0.0 | ||
| - name: Set up pnpm and Node.js | ||
| uses: pnpm/setup@f7d0e5f4b1b3089d2799ef9722859e7ba314c4c8 # v1 |
There was a problem hiding this comment.
Unverified action origin —
pnpm/setup vs pnpm/action-setup
The official pnpm action is pnpm/action-setup (documented at pnpm.io and on the GitHub Marketplace). pnpm/setup does not appear in pnpm's official documentation or Marketplace listing. Can you confirm this action lives at github.com/pnpm/setup under the pnpm org and is the intended replacement? This job has contents: write and access to the GitHub App token for pushing to main, so verifying the SHA resolves to a legitimate pnpm-owned repository is important before merging.
💡 Motivation and Context
Simplify CI setup by replacing the separate
pnpm/action-setup+actions/setup-node+ pnpm cache wiring with the new pinnedpnpm/setupaction, which installs pnpm and the Node.js runtime in one step.This also adds/keeps package-manager release-age gates at a total of 7 days:
.npmrc:min-release-age=7because npm uses days.minimumReleaseAge: 10080because pnpm uses minutes.Note:
pnpm/setupdoes not currently read.nvmrc, so Node 24 is duplicated in the action config for now where the repo also has.nvmrc. Once jasongin/nvs#315 lands, we can remove that duplicated runtime version and go back to a single.nvmrcsource of truth.💚 How did you test it?
.npmrcfiles use npm's day-basedmin-release-age=7and pnpm files use minute-basedminimumReleaseAge: 10080.git diff --check.📝 Checklist
If releasing new changes
pnpm changesetto generate a changeset file🤖 Agent context
Autonomy: Human-driven (agent-assisted)
Updated the CI setup at the user's request after checking the new
pnpm/setupaction behavior. Choseinstall: falseso existing explicitpnpm install --frozen-lockfilecommands keep their current lockfile behavior, and pinned the action to the currentv1commit SHA.