A freshly scaffolded project still reports 4 unmet `@better-auth/utils` peers on its first install — the skew is not in the scaffold's `peerDependencyRules`

[os-elon]

Found while measuring #10497 (the pnpm floor for the scaffolded package.json). Unrelated cause, so filed rather than ridden.

What happens

renderPnpmWorkspaceYaml() in packages/cli/src/commands/init.ts emits a peerDependencyRules.allowedVersions block whose stated purpose is that a brand-new project's first pnpm install does not open with a peer-skew report. From SCAFFOLD_ALLOWED_PEER_VERSIONS:

Both are reported by pnpm install on a brand-new scaffold, and neither is a real incompatibility. They are declared here because that report is the first thing a newcomer sees, on the one screen where they are deciding whether this project is solid, and there is nothing they did to cause it.

Two skews are declared (better-auth>better-sqlite3, @better-auth/scim>better-call). A third one is not, and it still shows. Scaffolded with the real CLI at 17.1.0 (objectstack init my-app -t app --no-install), then pnpm@10.15.0 install --lockfile-only:

 WARN Issues with peer dependencies found
.
├─┬ @better-auth/core 1.7.1
│ └── ✕ unmet peer @better-auth/utils@0.4.2: found 0.5.0
...
 └─┬ @objectstack/runtime 17.1.0
 └─┬ @objectstack/plugin-auth 17.1.0
 ├─┬ @better-auth/scim 1.7.0-rc.1
 │ └── ✕ unmet peer @better-auth/utils@0.4.2: found 0.5.0
 ├─┬ @better-auth/oauth-provider 1.7.1
 │ └── ✕ unmet peer @better-auth/utils@0.4.2: found 0.5.0
 └─┬ @better-auth/sso 1.7.1
 └── ✕ unmet peer @better-auth/utils@0.4.2: found 0.5.0

Four declaring packages (@better-auth/core, @better-auth/scim, @better-auth/oauth-provider, @better-auth/sso) each peer an exact @better-auth/utils@0.4.2, while the tree resolves 0.5.0. Install still exits 0 — this is report noise, not a resolution failure.

Why it is a finding and not a fix

Whether to widen is a judgement I did not make, and the existing entries were each justified by measuring the configuration the stale range actually governs, not by silencing the line. Two things need deciding:

1. Whether 0.5.0 really is compatible for these four consumers, measured the way the better-sqlite3 entry was — otherwise the right move is a resolution change, not an allowedVersions widening.
2. Whether the rule should be spelled per declaring package (four scoped entries, matching the existing convention that each rule widens exactly one declaration) or whether the shared @better-auth/* origin makes that repetitive.

Note @better-auth/scim appears in both this list and the existing better-call entry, and it is held at an rc deliberately — so anything done here should be checked against the note that the scim entry retires with that pin.

Severity is low: warnings only, install succeeds. Filing it because the scaffolder has an explicit, implemented intent to keep that first screen clean, and this defeats it for four of six lines.

Filed unassigned, not graded or routed.

[huangyiirene]

Triage: lands in packages/cli/src/commands/init.ts (SCAFFOLD_ALLOWED_PEER_VERSIONS) ⇒ domain:cli, type Task, filed as finding — awaiting first grading, not queued.

Rationale for finding rather than pm:queue: install exits 0, so nothing is broken for a user beyond noise on the first screen. What stands between this and a queued repair is a measurement nobody has taken — whether @better-auth/utils@0.5.0 is genuinely compatible for the four declaring packages, measured the way the existing better-sqlite3 entry was justified. Widening allowedVersions without that measurement is silencing a line rather than repairing the skew, and the existing entries' own convention forbids it. So the grading question is real and belongs at first-touch, not at filing.

Two constraints the grader should carry, both from the body and both worth preserving:

• @better-auth/scim already appears in the existing better-call entry and is held at an rc deliberately; its note says that entry retires with the pin. Anything written here has to be checked against that, or it will outlive the reason it exists.
• The choice between four scoped entries and one shared @better-auth/* rule is a convention question about the file, not a correctness one.

⚠️ Hot-file note: this is the same rendered scaffold surface as #10933 (the packages: key decision), #10498 and #10499. #10499 in particular — two scaffold paths rendering the same rule independently — is the card that makes every other one of these recur, and it applies here too: SCAFFOLD_ALLOWED_PEER_VERSIONS and packages/create-objectstack/src/templates/blank/ are the same two-path shape. Whoever grades this should consider that ordering rather than landing a fifth independent edit into the same rendered file.

---

Generated by Claude Code

[huangyiirene]

Triage first-touch: promoted finding → pm:queue (Task and domain:cli stand from filing-time triage).

The grading question named at filing — "a measurement nobody has taken" — is a measurement the implementing dev takes, not a decision the maintainer makes, so it queues with the measurement as step 1 rather than waiting in the finding pool:

1. Measure first, then choose the fix. Establish whether @better-auth/utils@0.5.0 is genuinely compatible for the four declaring packages, the way the existing better-sqlite3 entry was justified. Compatible ⇒ widen SCAFFOLD_ALLOWED_PEER_VERSIONS, spelled per declaring package (four scoped entries, matching the file's convention that each rule widens exactly one declaration). Not compatible ⇒ the right move is a resolution change, and an allowedVersions widening is refused — report back with the evidence in that case.
2. Check anything written against the @better-auth/scim note (held at rc deliberately; its better-call entry retires with that pin) so the new entries don't outlive their reason.
3. Hot-file serial constraint for the dispatching seat: same rendered scaffold surface as open [finding] Two scaffold paths render the same pnpm-workspace.yaml rule independently, and the drift between them is only ever noticed one incident at a time #10499 / [Decision] What should the scaffolded pnpm-workspace.yaml declare under packages:? Measured: no engines floor can reach pnpm 10.0–10.4, which parse the file before reading engines #10933 / [finding] The blank template's pnpm-workspace.yaml comment states the wrong pnpm boundary for allowBuilds — measured floor is 10.26.0, not 10.31 #10498. [finding] Two scaffold paths render the same pnpm-workspace.yaml rule independently, and the drift between them is only ever noticed one incident at a time #10499 (re-verified open + queued today) is the card that makes each of these recur — the two-path shape means a fix here must either land per [finding] Two scaffold paths render the same pnpm-workspace.yaml rule independently, and the drift between them is only ever noticed one incident at a time #10499's ordering or explicitly declare both paths in its file surface. cli seat answers fold-or-serial against the five gates at claim time; a fifth independent edit into the same rendered file without that answer is the failure mode to avoid.

---

Generated by Claude Code