`package.json` currently pins pnpm through the top-level `packageManager` field (`"packageManager": "pnpm@11.25.0"`), which is the same style Corepack reads. pnpm's own docs (https://pnpm.io/package_json) now describe that field as the legacy way to pin pnpm's version, and point to `devEngines.packageManager` as the field pnpm resolves its own version pin through going forward — it's already how this project pins its Node.js version (`devEngines.runtime`), and unlike the legacy field it supports version ranges and a per-field `onFail`.
Keeping the pnpm pin on the legacy field means this project isn't following the convention pnpm itself now recommends for declaring its own version, even though it already uses that same `devEngines` mechanism for Node. `packageManager` should be replaced with a `devEngines.packageManager` entry mirroring the existing `runtime` block, e.g. `{ "name": "pnpm", "version": "^11.25.0", "onFail": "download" }`.
`package.json` currently pins pnpm through the top-level `packageManager` field (`"packageManager": "pnpm@11.25.0"`), which is the same style Corepack reads. pnpm's own docs (https://pnpm.io/package_json) now describe that field as the legacy way to pin pnpm's version, and point to `devEngines.packageManager` as the field pnpm resolves its own version pin through going forward — it's already how this project pins its Node.js version (`devEngines.runtime`), and unlike the legacy field it supports version ranges and a per-field `onFail`.
Keeping the pnpm pin on the legacy field means this project isn't following the convention pnpm itself now recommends for declaring its own version, even though it already uses that same `devEngines` mechanism for Node. `packageManager` should be replaced with a `devEngines.packageManager` entry mirroring the existing `runtime` block, e.g. `{ "name": "pnpm", "version": "^11.25.0", "onFail": "download" }`.