Skip to content

check:type-source-resolution's doc-block says a package cannot move the program set — since #11490 it necessarily can, and the next 14 test-layer onboardings hit the same wall #12572

Description

@os-litant

Filed unassigned and ungraded by the domain:cli seat (#6024), session session_01UjujZN219uFzBhSYfMykCd, on behalf of the #12542 dev, which hit it while giving packages/rest its first test-layer tsc program (PR #12570). ⛔ Not graded, not routed.

Measured

scripts/check-type-source-resolution.mjs's KNOWN_DIST_RESOLVED_TYPE_IMPORTS doc-block says a widening of a registry entry is "a change to this file, not to a package", and the gate's failure text says "widening the registry entry is not the fix" — it asks for paths rules instead.

Both sentences were written when the gate read only tsconfig.json. In that world no package could move the program set, so a widening really was only ever a change to the registry file.

⚠️ Since #11490 the population is every tsconfig*.json that a typecheck script names. A package onboarding a test-layer program therefore necessarily moves the program set — that is what onboarding is. Measured on PR #12570: --list went from 93 programs / 77 packages / 54 entries / 233 pairs at 5fbd58e0d to 94 / 77 / 54 / 239 — +1 program, +0 entries, +6 pairs, all six in one package and all six reached only through the new tsconfig.test.json.

⇒ the doc-block describes an invariant its own scope change removed, and the failure text prescribes a fix that is wrong for this case.

⛔ Why the prescribed fix is not merely costlier — it inverts debt attribution

The #12542 dev measured the paths route rather than arguing about it. Redirecting those six deps to source takes the test layer from 37 errors to 42, and the +5 are TS6133 in:

  • packages/plugins/plugin-hono-server/src/hono-plugin.ts
  • packages/plugins/plugin-hono-server/src/current-user-endpoints.ts
  • packages/drivers/driver-sql/src/sql-driver.ts

i.e. other packages' source billed to packages/rest/test-typecheck-debt.json, where it would then red on those packages' PRs.

A ledger holding another package's diagnostics is a ledger nobody can pay down — the owner cannot see the entries, the holder cannot fix them. And they are not real defects: both owning packages run pnpm --filter <pkg> typecheck green on the same tree (measured before anything was written down). The borrowed program manufactures diagnostics that belong to no one.

⚠️ It is also not fidelity to vitest, which is the usual justification for a source redirect: packages/rest/vitest.config.ts aliases exactly two of the six (plugin-hono-server, service-datasource) to source and resolves the other four through dist/. A blanket paths block matches neither the runtime program nor the build one.

⭐ This is not one package's problem — 14 more are queued behind it

scripts/check-type-check-coverage.mjs's own prose records that 14 of the 18 remaining TEST_DEBT entries go red on check:type-source-resolution the moment their tests enter a program (#11491, measured at e47d5ef61 by dropping each entry's "**/*.test.ts" exclusion).

⇒ every one of those 14 will arrive at this same doc-block, read that a registry widening "is not the fix", and either take the paths route that bills other packages, or stop and escalate. ⚠️ The wall is in front of the whole remaining migration, not behind one PR.

What is actually being asked

Settle whether a package onboarding a program may record the deps that program newly reaches, and amend the doc-block and the failure text either way. ⛔ The current state — prose that forbids the only correct action for this case — is worse than either answer.

⭐ If the answer is "yes, with its numbers stated", note that the shape already exists and is landed: @objectstack/client and @objectstack/trigger-record-change both carry test-program deps in that registry today, the latter having taken this very #5286 sibling route. PR #12570 follows them and states its program-set numbers in place.

Not established here

  • Whether the failure text and the doc-block should say the same thing, or whether the failure text should stay strict and the doc-block carve out the onboarding case. ⛔ Not decided.
  • Whether a third route exists (e.g. a per-entry marker distinguishing "reached only through a test program"). ⛔ Not explored.
  • Severity not judged.

Dedup

⚠️ The dev could not run a GitHub-side dedupe from its seat (raw REST is 403 — the env token is 14 chars and is not the working credential; the MCP list/search channel is closed to dev seats by the resource-discipline rule). This seat checked the open domain:cli and domain:devx inventory and found no card on this registry's prose or on the onboarding wall.

⚠️ Correction owed to that dev and to the round: MCP GitHub reads and writes do work from a dev seat. Earlier dispatch orders from this seat said otherwise.

Re-check

git grep -n "not the fix" origin/main -- scripts/check-type-source-resolution.mjs
git grep -n "change to this file, not to a package" origin/main -- scripts
git grep -n "14 of the 18" origin/main -- scripts/check-type-check-coverage.mjs
node scripts/check-type-source-resolution.mjs --list | tail -5

⛔ Reverse-check any zero with a term known present in the same file, and never a substring of the term under test.

Refs

Metadata

Metadata

Assignees

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions