Carried forward from #10405, whose body asks this directly ("Worth confirming as part of that whether the two scaffold paths should keep rendering this file independently at all") and which is about to be closed by its fix. Filing so the question survives that close.
The shape
Two independent producers write a pnpm-workspace.yaml into a new user's project, and each states the same rule in its own words:
packages/create-objectstack/src/templates/blank/pnpm-workspace.yaml — a literal file in the template, ratcheted by packages/create-objectstack/src/template-consistency.test.ts.renderPnpmWorkspaceYaml() in packages/cli/src/commands/init.ts — a string builder, ratcheted by packages/cli/test/init.test.ts.
They agree on the approved set (better-sqlite3, esbuild) and on the peer-skew declarations, and after #10405 they agree on carrying both build-approval keys. Nothing is broken right now.
Why it is worth a look anyway
The measured history is that they drift, and that the drift is invisible until a user hits it:
The general question: should there be one source for "what a scaffolded project's pnpm settings are", with both paths consuming it, or a cross-file consistency gate that fails when the two disagree?
Cost side, honestly
The two producers are genuinely different in kind — one is a static template file that also carries peerDependencyRules prose, the other builds a string from data and is parameterised for tests. Sharing them means either the CLI depending on create-objectstack (wrong direction) or a third shared module both import, for a file that is roughly twenty lines of settings. A consistency test asserting the two rendered outputs grant the same build set may be the cheaper 80%.
No action taken in #10405's PR: the fix stayed inside packages/cli on purpose, because the two sibling scaffolder cards in flight (#10317, #10323) own file surface in packages/create-objectstack.
Filed unassigned, not graded or routed.
Carried forward from #10405, whose body asks this directly ("Worth confirming as part of that whether the two scaffold paths should keep rendering this file independently at all") and which is about to be closed by its fix. Filing so the question survives that close.
The shape
Two independent producers write a
pnpm-workspace.yamlinto a new user's project, and each states the same rule in its own words:packages/create-objectstack/src/templates/blank/pnpm-workspace.yaml— a literal file in the template, ratcheted bypackages/create-objectstack/src/template-consistency.test.ts.renderPnpmWorkspaceYaml()inpackages/cli/src/commands/init.ts— a string builder, ratcheted bypackages/cli/test/init.test.ts.They agree on the approved set (
better-sqlite3,esbuild) and on the peer-skew declarations, and after #10405 they agree on carrying both build-approval keys. Nothing is broken right now.Why it is worth a look anyway
The measured history is that they drift, and that the drift is invisible until a user hits it:
allowBuildswas added to the blank template when pnpm 11 made an unapproved build script a hard error. The CLI renderer was not touched, so one of the two scaffold paths kept shipping the pre-fix shape and its users kept hittingERR_PNPM_IGNORED_BUILDSon their first command — that isobjectstack initscaffolds a project whosepnpm installexits 1 on pnpm 11 — its rendered pnpm-workspace.yaml omitsallowBuilds#10405, filed months later off a first-run audit rather than off a gate.The general question: should there be one source for "what a scaffolded project's pnpm settings are", with both paths consuming it, or a cross-file consistency gate that fails when the two disagree?
Cost side, honestly
The two producers are genuinely different in kind — one is a static template file that also carries
peerDependencyRulesprose, the other builds a string from data and is parameterised for tests. Sharing them means either the CLI depending oncreate-objectstack(wrong direction) or a third shared module both import, for a file that is roughly twenty lines of settings. A consistency test asserting the two rendered outputs grant the same build set may be the cheaper 80%.No action taken in #10405's PR: the fix stayed inside
packages/clion purpose, because the two sibling scaffolder cards in flight (#10317, #10323) own file surface inpackages/create-objectstack.Filed unassigned, not graded or routed.