Skip to content

[finding] The scaffold pnpm-workspace.yaml that objectstack init renders still explains the RETIRED @better-auth/scim>better-call peer rule as if it were live — and both consistency tests strip comments before asserting, so no gate reads it #17093

Description

@claude

Found while re-measuring the better-auth>better-sqlite3 peer record for #16813. Out of scope there (a different entry, so a different defect), filed rather than carried.

What ships

renderPnpmWorkspaceYaml() in packages/cli/src/commands/init.ts emits a comment block above peerDependencyRules. One of its paragraphs still reads:

#   @better-auth/scim (held at a release candidate deliberately) peers an
#   exact better-call 1.3.7, while better-auth itself depends on 1.4.0. A
#   better-auth plugin has to share the host's better-call instance, so
#   the single 1.4.0 copy is the correct resolution.

Three things in it are false on today's tree:

  • The '@better-auth/scim>better-call' entry it explains is not in the rendered file. It retired with SCIM: 停在 @better-auth/scim rc.1,等正式版再整体迁移 —— rc.2 换掉了整套模型 #3653, and SCAFFOLD_ALLOWED_PEER_VERSIONS no longer contains it — init.test.ts even pins its ABSENCE (keeps the retired @better-auth/scim>better-call suppression OUT (#3653)).
  • @better-auth/scim is not "held at a release candidate deliberately". pnpm-workspace.yaml pins the whole better-auth family at an exact stable 1.7.2.
  • Stable @better-auth/scim@1.7.2 peers better-call@1.4.0, not 1.3.7, so the skew the paragraph describes does not exist.

So a project scaffolded by objectstack init today gets a pnpm-workspace.yaml whose comments explain a rule that is not in the file, on the same first screen that block exists to make trustworthy.

Why no gate catches it

The two producers are held equal by packages/cli/test/scaffold-workspace-consistency.test.ts, but that file compares the rendered allowedVersions MAP only, and says so deliberately: "The prose above each block is NOT compared: the two files explain these skews in their own words on purpose." init.test.ts and create-objectstack's template-consistency.test.ts both do .replace(/^\s*#.*$/gm, '') before asserting, for the good reason that prose must never be what satisfies an assertion about a declaration.

Every one of those choices is right on its own. The gap they leave is that a retired entry's PROSE has nothing holding it to the entry's absence — the absence pin fires on the key, and the comment survives it.

The asymmetry that makes this a defect rather than a nit

The sibling producer already got this right. packages/create-objectstack/src/templates/blank/pnpm-workspace.yaml marks the same entry retired in its own words:

#   (The '@better-auth/scim>better-call' entry that used to sit here retired
#   with the scim release-candidate pin — stable @better-auth/scim 1.7.1 peers
#   better-call 1.4.0 exactly, so the skew it declared away is gone.)

So the two scaffold paths do not merely word it differently — one records the retirement and the other still advertises the rule. A newcomer's file says one thing or the other depending on which command created the project.

Reproduce

node -e "import('./packages/cli/dist/commands/init.js').then(m => console.log(m.renderPnpmWorkspaceYaml()))"

The scim paragraph is in the output; '@better-auth/scim>better-call' is not.

Suggested shape, for triage rather than as a decision

Mirror the template's retirement wording into init.ts (the settled shape already exists next door), and consider whether the absence pin should extend to the prose — e.g. asserting the rendered comments name no key that SCAFFOLD_ALLOWED_PEER_VERSIONS does not contain. That second half is the part that would stop the next retirement leaving its explanation behind, and it is a real design question rather than a mechanical fix, which is why this card only establishes the drift.


Generated by Claude Code

Activity

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

Metadata

Metadata

Assignees

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions