Pin pnpm version in CI - #12
Conversation
The workflows asked for `version: latest`, so CI silently moved to pnpm 11 while local development stays on 10.18.3. pnpm 11 removed the `onlyBuiltDependencies` setting in favor of `allowBuilds`, so the approval list in docs/pnpm-workspace.yaml no longer registered and every install failed with ERR_PNPM_IGNORED_BUILDS for @tailwindcss/oxide, sharp, and unrs-resolver. Pinning to the version used locally keeps CI reproducible and lets it verify what developers actually run. pnpm 11 also requires Node >= 22.13, so adopting it would mean upgrading local toolchains first.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
WalkthroughThe documentation deployment, lint, and documentation test workflows now pin pnpm to version Changespnpm CI version pinning
Estimated code review effort: 1 (Trivial) | ~2 minutes Mergeability Score: ⚪ Minimal · up to Pinning pnpm to the locally used version in both CI workflows removes version drift without introducing an actionable merge-blocking risk; the PR is merge-ready after normal checks and review. Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Follow-up to #11. The
LintandNext.js Site Testsjobs have been failing independently of the Rails work.Cause
Both workflows asked pnpm's setup action for
version: latest, so CI silently jumped to pnpm 11 while local development stays on 10.18.3. pnpm 11 removedonlyBuiltDependenciesin favor of a newallowBuildsmap, which means the approval list already committed indocs/pnpm-workspace.yaml:was no longer a recognized setting. pnpm 11 then treated those same three packages as unapproved and hard-failed every install with
ERR_PNPM_IGNORED_BUILDS.So this was never a missing approval — the approvals were there, under a name the new major stopped reading.
Fix
Pin pnpm to 10.18.3, the version used locally. CI becomes reproducible and verifies what developers actually run, instead of drifting onto a new major on its own.
Migrating to pnpm 11 instead would mean rewriting that config as
allowBuildsand upgrading local Node first — pnpm 11 requires Node >= 22.13 and this machine runs 22.6.0. Worth doing deliberately, not as a side effect of a CI fix.Verification
Every step in both jobs was run locally, including the ones that never got past the install:
pnpm install --frozen-lockfile(root + docs)--checktapioca gems --verify/dsl --verifytsc --noEmit, docs Jest suiteSummary by CodeRabbit