Found while measuring #10405, whose fix mirrors this file's settled shape into the CLI's renderPnpmWorkspaceYaml().
The claim, and the measurement
packages/create-objectstack/src/templates/blank/pnpm-workspace.yaml ships this comment to every scaffolded project:
Both keys are needed; they are read by different pnpm versions:
allowBuilds — pnpm >= 10.31 and pnpm 11+. pnpm 11 reads ONLY this one — onlyBuiltDependencies alone still errors.
onlyBuiltDependencies — pnpm 10.0–10.30, which do not understand allowBuilds.
packages/create-objectstack/src/template-consistency.test.ts repeats the 10.0–10.30 band in its own comment.
Measured on a probe project depending on esbuild@0.28.2, with a pnpm-workspace.yaml carrying onlyallowBuilds, one clean install per pnpm version, each with its own --store-dir (an isolated store matters: pnpm's side-effects cache will otherwise hand a later run a build the earlier run performed, and the run reads as "the key worked"):
| pnpm | allowBuilds alone |
|---|
| 10.15.0 | ignored — build not run |
| 10.18.0 | ignored — build not run |
| 10.22.0 | ignored — build not run |
| 10.23.0 | ignored — build not run |
| 10.24.0 | ignored — build not run |
| 10.25.0 | ignored — build not run |
| 10.26.0 | honoured — build ran |
| 10.28.0 | honoured — build ran |
| 10.30.0 | honoured — build ran |
| 10.33.0 | honoured — build ran |
So the floor is 10.26.0, not 10.31, and the onlyBuiltDependencies-only band is 10.0–10.25, not 10.0–10.30.
Why it is worth recording
The two load-bearing claims in that comment are both correct — both keys are needed, and pnpm 11 reads only allowBuilds (verified: with onlyBuiltDependencies alone, pnpm 11.22.0 exits 1 with ERR_PNPM_IGNORED_BUILDS and reports exactly the same ignored set as a file approving nothing at all). Nothing is broken; the template's behaviour is right.
What is wrong is a version boundary in prose that ships to users inside their own project file, and which the next author will copy the way #10405's fix nearly did. A reader on pnpm 10.28 is told by the file in front of them that their pnpm cannot read the key it is in fact reading.
Suggested landing
Correct the boundary in the template's pnpm-workspace.yaml comment and in the template-consistency.test.ts comment above the blank template pnpm build approvals block. Both are comment-only; no assertion changes. The CLI renderer's own comment already carries the measured numbers as of #10405's fix, so leaving this one is what creates a divergence between two files describing the same rule.
Filed unassigned, not graded or routed.
Found while measuring #10405, whose fix mirrors this file's settled shape into the CLI's
renderPnpmWorkspaceYaml().The claim, and the measurement
packages/create-objectstack/src/templates/blank/pnpm-workspace.yamlships this comment to every scaffolded project:packages/create-objectstack/src/template-consistency.test.tsrepeats the10.0–10.30band in its own comment.Measured on a probe project depending on
esbuild@0.28.2, with apnpm-workspace.yamlcarrying onlyallowBuilds, one clean install per pnpm version, each with its own--store-dir(an isolated store matters: pnpm's side-effects cache will otherwise hand a later run a build the earlier run performed, and the run reads as "the key worked"):allowBuildsaloneSo the floor is
10.26.0, not10.31, and theonlyBuiltDependencies-only band is10.0–10.25, not10.0–10.30.Why it is worth recording
The two load-bearing claims in that comment are both correct — both keys are needed, and pnpm 11 reads only
allowBuilds(verified: withonlyBuiltDependenciesalone, pnpm 11.22.0 exits 1 withERR_PNPM_IGNORED_BUILDSand reports exactly the same ignored set as a file approving nothing at all). Nothing is broken; the template's behaviour is right.What is wrong is a version boundary in prose that ships to users inside their own project file, and which the next author will copy the way #10405's fix nearly did. A reader on pnpm 10.28 is told by the file in front of them that their pnpm cannot read the key it is in fact reading.
Suggested landing
Correct the boundary in the template's
pnpm-workspace.yamlcomment and in thetemplate-consistency.test.tscomment above theblank template pnpm build approvalsblock. Both are comment-only; no assertion changes. The CLI renderer's own comment already carries the measured numbers as of #10405's fix, so leaving this one is what creates a divergence between two files describing the same rule.Filed unassigned, not graded or routed.