Repository navigation
chore: pin packageManager to pnpm@10.34.4 - #262
Conversation
|
@NnamdiCyber Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
truthixify
left a comment
truthixify
left a comment
There was a problem hiding this comment.
The package-manager pin is incomplete and currently breaks required CI. The examples workflow still configures pnpm/action-setup with version 10 while package.json specifies pnpm@10.34.4, so all eight example jobs fail before install. The main test jobs also fail formatting on scripts/check-pnpm-version.mjs. Update every workflow to use one source of truth (prefer omitting the action version when packageManager is present), format the script, and rerun the required matrix.
OKay, am working on it |
Done |
truthixify
left a comment
truthixify
left a comment
There was a problem hiding this comment.
The current head correctly makes packageManager the single pnpm version source, removes direct version inputs from all checked-in pnpm/action-setup steps, and the local version guard passes with pnpm 10.34.4. Approval is for this exact head. I am not merging it while the required Security audit check is red; that run used an older synthetic merge base which still supplied version: 10, so update/rebase the branch to retrigger CI against current develop.
1c58036 to
6e8b54c
Compare
It's done. Please review |
truthixify
left a comment
truthixify
left a comment
There was a problem hiding this comment.
Reviewed exact head 2a189c6. The repository now has one packageManager pin, every pnpm/action-setup invocation consumes it, the checker uses execFileSync with a fixed executable and argument array, and both the local version check and full formatting check pass. All required CI, compatibility, package, example, and security checks are green.
|
Exact head 2a189c6 passed review and the security preflight, and I approved it. PR #253 merged immediately before this merge attempt, so GitHub now reports this branch as conflicting with develop. Please rebase onto the current develop branch without changing the intended pnpm-pin behavior; I will recheck the new head. |
Add packageManager field to package.json pinning pnpm@10.34.4, the version that created pnpm-lock.yaml, so local and CI installs use the same version. CI pnpm/action-setup pins 10.34.4 instead of floating 10. Add a check:pnpm-version script (run in CI and pre-commit) that rejects lockfile updates from an incompatible pnpm major.
Remove the hardcoded version: key from every pnpm/action-setup@v4 step across all four workflows (ci.yml, examples.yml, publish.yml, docs.yml). pnpm/action-setup reads the packageManager field from package.json automatically, so omitting the key makes package.json the single source of truth and eliminates the version skew that was failing the eight examples matrix jobs. Also format scripts/check-pnpm-version.mjs to pass pnpm run format:check.
The security-audit job was added to upstream/develop after the initial fix and still had version: 10 hardcoded, causing the pnpm/action-setup multiple-versions conflict. Remove the with: block so packageManager in package.json remains the single source of truth.
2a189c6 to
2674856
Compare
@truthixify It's done, please review. |
truthixify
left a comment
truthixify
left a comment
There was a problem hiding this comment.
Changes requested on exact head 2674856. The pnpm single-source-of-truth change is correct and all functional/package matrices are green, but the required Security audit gate is red on untracked critical GHSA-2464-fhr4-w9xw (Next.js unauthenticated RCE through SVG Image Optimization): next 14.2.35 is installed and the gate reports >=15.5.28 as patched. Remediate the dependency and lockfile, then rerun the required gate.
truthixify
left a comment
truthixify
left a comment
There was a problem hiding this comment.
Remote malware screening passed again on exact head 15b3418. All required checks are green. Local verification passed the pnpm-version check, production build, and entry-point smoke suite. The packageManager field now provides one exact pnpm source for local and CI setup.
chore: pin packageManager to pnpm@10.34.4
Problem
package.jsonhad nopackageManagerfield, so CI installed a floating pnpm 10 release while the lockfile was created by pnpm 10.34.4. Different pnpm majors can produce different lockfile resolutions, causing drift between local and CI installs.Changes
package.json: added"packageManager": "pnpm@10.34.4"(Corepack resolves this locally).scripts/check-pnpm-version.mjs(new): readspackageManager, compares its major against runningpnpm --version, exits non-zero on mismatch. Rejects lockfile edits made with an incompatible pnpm major..github/workflows/ci.yml: pinned all 10pnpm/action-setup@v4version: 10→10.34.4; addedpnpm run check:pnpm-versionafterinstall --frozen-lockfilein the test job..husky/pre-commit: runspnpm check:pnpm-versionbefore format/build/test.Verification
package.jsonparses; check script passes locally (ok: pnpm@10.34.4 matches pnpm@10.34.4).Closes #240