Skip to content

chore: pin pnpm and raise the engines floor to match - #339

Open
BryanFRD wants to merge 1 commit into
mainfrom
chore/pin-pnpm
Open

chore: pin pnpm and raise the engines floor to match#339
BryanFRD wants to merge 1 commit into
mainfrom
chore/pin-pnpm

Conversation

@BryanFRD

@BryanFRD BryanFRD commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

Refs FerrLabs/.github#328 is unrelated; this one stands alone.

This repository never pinned pnpm. There is no packageManager field, and ci.yml calls reusable-ci-node.yml without pnpm-version, so CI takes whatever that workflow defaults to, currently '10', while engines allowed anything from 9 up. Three different answers to "which pnpm builds this", none of them written down.

packageManager: pnpm@12.3.4 settles it: pnpm/action-setup reads that field, contributors get the same version through corepack, and Renovate starts tracking the bump here like it does everywhere else. The engines.pnpm floor moves from >=9.0.0 to >=12.0.0 to match, so an older client fails at install instead of quietly rewriting the lockfile in an older format.

The lockfile gains the packageManagerDependencies block that pnpm 12 records for a pinned manager. Generated with pnpm install --lockfile-only and checked with pnpm install --frozen-lockfile, which passes.

This also unblocks the org-wide change that flips pnpm-version's default in the reusable workflows from '10' to empty, so packageManager becomes the single source of truth. This repository is the only caller that relies on that default today, so it has to be pinned first.

@BryanFRD
BryanFRD enabled auto-merge (squash) September 7, 2026 08:47
@github-actions

github-actions Bot commented Sep 7, 2026

Copy link
Copy Markdown

SonarQube — aucune nouvelle issue

Comparaison entre le projet bac à sable de cette PR et la branche par défaut : SonarQube Community n'analyse pas les PR, ce delta est calculé côté CI. Détail

@ferrfleet ferrfleet Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The intent is right and the reasoning in the description holds. Two things stop it as committed.

Blocking: ci.yml still gets pnpm 10, and the new engines floor rejects it. .github/workflows/ci.yml calls reusable-ci-node.yml with no pnpm-version, so the default applies, which the description says is currently '10'. Raising engines.pnpm to >=12.0.0 in the same commit means CI installs with a pnpm that the manifest forbids, and packageManagerDependencies in the lockfile is a pnpm 12 construct that pnpm 10 has no reason to understand.

The description frames the reusable-workflow default flip as something this PR unblocks, which puts the ordering the wrong way round: this repo is the last caller relying on that default, so it needs a pnpm 12 runner before it can require pnpm 12. Either land the default flip in FerrLabs/.github first and bump the pinned SHA here, or pass pnpm-version: '12.3.4' explicitly in ci.yml in this PR and drop it again once the default is empty. The explicit input is the smaller step and keeps the two repos independent.

The second blocking finding is the lockfile itself, inline.

Comment thread pnpm-lock.yaml
'@pnpm/exe.win32-arm64': 12.3.4
'@pnpm/exe.win32-x64': 12.3.4

---

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Blocking: this makes pnpm-lock.yaml two YAML documents, not one.

I read the file at 14efc95: it starts with --- on line 1, a first document holding only lockfileVersion: '9.0', an importers entry with just packageManagerDependencies, and the pnpm@12.3.4 packages/snapshots. Then this --- on line 101, then a second lockfileVersion: '9.0' document (line 102) containing the real settings, overrides, all workspace importers and every dependency.

pnpm writes a single document. A YAML loader given this stream either errors on the multi-document input or takes only the first document, in which case the lockfile declares zero dependencies. Test / Test & Build and Test / Quality (knip, madge, audit) both fail on this commit, which is consistent with that.

This doesn't fit a suggestion block, since the fix is the whole file: drop the current pnpm-lock.yaml, check out the one from main, and regenerate with pnpm 12.3.4 (pnpm install --lockfile-only) so the packageManagerDependencies block is merged into the existing document rather than prepended as a new one. The result should have exactly one lockfileVersion: line and no --- separators.

The PR body says pnpm install --frozen-lockfile passed against this file. Worth rechecking which file that ran against, because the committed one is not it.

Comment thread package.json
"description": "FerrLabs MCP servers — workspace root",
"license": "MPL-2.0",
"type": "module",
"packageManager": "pnpm@12.3.4",

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: no integrity hash on the pin. Corepack accepts pnpm@12.3.4 bare, but with pnpm@12.3.4+sha512-... it verifies the downloaded tarball before running it. corepack use pnpm@12.3.4 writes the hashed form. Renovate keeps the hash updated on bumps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant