chore: pin pnpm and raise the engines floor to match - #339
Conversation
SonarQube — aucune nouvelle issueComparaison 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 |
There was a problem hiding this comment.
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.
| '@pnpm/exe.win32-arm64': 12.3.4 | ||
| '@pnpm/exe.win32-x64': 12.3.4 | ||
|
|
||
| --- |
There was a problem hiding this comment.
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.
| "description": "FerrLabs MCP servers — workspace root", | ||
| "license": "MPL-2.0", | ||
| "type": "module", | ||
| "packageManager": "pnpm@12.3.4", |
There was a problem hiding this comment.
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.
Refs FerrLabs/.github#328 is unrelated; this one stands alone.
This repository never pinned pnpm. There is no
packageManagerfield, andci.ymlcallsreusable-ci-node.ymlwithoutpnpm-version, so CI takes whatever that workflow defaults to, currently'10', whileenginesallowed anything from 9 up. Three different answers to "which pnpm builds this", none of them written down.packageManager: pnpm@12.3.4settles it:pnpm/action-setupreads that field, contributors get the same version through corepack, and Renovate starts tracking the bump here like it does everywhere else. Theengines.pnpmfloor moves from>=9.0.0to>=12.0.0to match, so an older client fails at install instead of quietly rewriting the lockfile in an older format.The lockfile gains the
packageManagerDependenciesblock that pnpm 12 records for a pinned manager. Generated withpnpm install --lockfile-onlyand checked withpnpm 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, sopackageManagerbecomes the single source of truth. This repository is the only caller that relies on that default today, so it has to be pinned first.