chore: raise the pnpm pin to ^12.4.1 - #89
Conversation
Keeps the devEngines range and the pnpm-lock.yaml pin at the current pnpm 12.x release. Environments that launch pnpm through Corepack resolve the range to the newest 12.x and cannot switch to the lockfile's version, so an older lockfile pin fails frozen installs.
|
This run was cancelled 🛑 The workflow was cancelled before completion. Please check the link below for details. |
@standard-server/aws-lambda
@standard-server/core
@standard-server/fastify
@standard-server/fetch
@standard-server/node
@standard-server/peer
@standard-server/shared
commit: |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Merging this PR will not alter performance
Comparing Footnotes
|

Raises the pnpm pin in
devEngines.packageManagerfrom^12.0.0to^12.4.1and records 12.4.1 inpnpm-lock.yaml(previously 12.3.4), the same change as middleapi/orpc#2012. With a range pin, any environment that launches pnpm through Corepack resolves the range to the newest 12.x on npm and cannot switch to the version recorded in the lockfile, so an older lockfile pin failspnpm install --frozen-lockfilewithERR_PNPM_FROZEN_LOCKFILE_WITH_OUTDATED_LOCKFILE. Keeping the pin at the current release avoids that.Behavior
packageManagerDependenciesblock and the@pnpm/exe.*platform packages for 12.4.1.pnpm self-update <version>followed bypnpm install).Testing
pnpm install --frozen-lockfilepasses with pnpm 12.4.1: the supply-chain check passes and the resolution step is skipped.eslint package.jsonpasses.