You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
"_comment": "Per-file tsc error debt of the @objectstack/core TEST layer (#5286). `tsconfig.test.json` compiles `src/**/*.test.ts` — which `tsconfig.json` excludes and therefore no gate ever read — and every file below still carries errors from before that gate existed. THIS FIELD IS GENERATED: every regeneration rewrites it from scripts/check-test-typecheck.mts, and the EXACT ratchet below requires a regeneration on every repair — so an edit made here is gone by the next one. Anything true of THIS package goes in the sibling `_note` field, which is authored, is preserved verbatim, and is never written by the generator (#12624). This comment states NO cause for the errors, deliberately: the classes differ per package and per file, they move as the debt is paid down, and a cause written here is rewritten verbatim into every ledger by every regeneration — so it outlives its own repair and cannot be corrected in the file where it is read. Measure instead, before repairing anything: `tsc --noEmit --pretty false -p tsconfig.test.json` in the package prints the real classes with their TS codes. Each entry maps a file to its per-SIGNATURE error counts, never to a bare total (#13470): a signature is the TS code plus the diagnostic message with structural type blobs collapsed, and it carries NO line or column — so the pin survives edits that move code around, and only stops matching when the error itself becomes a different error. EXACT ratchet, judged by re-running tsc: a file that gains errors is red, a file that loses them is red until its number is re-recorded, a file that reaches zero is red until its entry is deleted, a signature that ARRIVES or VANISHES is red even when the file total is unchanged, and a file NOT listed here may have no errors at all. Regenerate with: pnpm --filter @objectstack/core gen:test-typecheck-debt",
3
+
"_note": "OPENED AT 4, NOT AT 98, and the difference is the CHECK rather than any repair to a test file (#14613). This package declared NO typecheck script at all until this ledger existed, so `turbo run typecheck` -- which selects only packages declaring the task -- could not reach it; the state was tracked, as a `check:type-check-coverage` DEBT entry of 98 re-measured once from 91, but nothing a contributor could RUN reported it, which is how a dispatched task came to assume `pnpm --filter @objectstack/core typecheck` existed. Measured at 84b8190ae with the dependency closure built: the undivided program (`tsc --noEmit -p tsconfig.json`, tests included, as the DEBT entry measured it) reports 98 errors over 12 files, all 12 of them `.test.ts`; the same program over only the 63 non-test source files reports ZERO; and THIS program -- the same 48 test files under vitest's own module semantics -- reports 4. So 94 of the 98 were the build config's NodeNext judging vitest-executed ESM (TS2835 x22 and the TS2347 beside them, plus the share of TS7006 x71 they cause: an import that does not resolve makes every symbol it names `any`). Not one test file was edited to retire them. That is the `check-type-check-coverage` header's own discipline applied literally -- fix the config first, then read the residue -- and it is why the 98 in that ledger was an upper bound on nothing. WHAT THE 4 ACTUALLY ARE, deliberately left ledgered rather than repaired here. Two are ONE defect twice over: `src/plugin-loader.test.ts` (TS2352) and `src/security/plugin-permission-enforcer.test.ts` (TS2739) each build a mock PluginContext literal missing `registerServiceFactory`, `replaceService` and `getServiceScoped`. ⚠️ That is the SAME shape as the 30 x TS2345 the DEBT entry for `@objectstack/metadata` records ('every one the same mock PluginContext literal missing registerServiceFactory and getServiceScoped'), and that package's repair is in flight on its own card -- so the shared fixture those two want should be authored ONCE, by whoever closes that, rather than twice in parallel. Repairing them here would have raced it. The third, `src/utils/filter-tokens.test.ts` (TS2352), is a genuine question about a signature and not a fixture typo: a `$and` array of single-key literals is asserted into `Record<string, string>[]`, and the union's absent keys are `undefined`, which no index signature of `string` admits -- repairing it means deciding whether the test's intent or the parameter's type is the wrong one. Only the fourth, `src/utils/migration-journal.test.ts` (TS6133, an unread `rows`), is mechanical, and a lone mechanical fix beside three judgement calls buys nothing while making the diff that opens this gate harder to read. ⛔ None of the 4 is a reason to widen `exclude` in `tsconfig.test.json`: the whole point of the split beside it is that the strictness flags are INHERITED and untouched. Each is red on the PR that changes it, and the ratchet is EXACT in both directions -- a file that loses its error is red until re-recorded, and reaching zero here means deleting the entry, not lowering a number.",
4
+
"entries": {
5
+
"src/plugin-loader.test.ts": {
6
+
"TS2352: Conversion of type '…' to type 'PluginContext' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.": 1
"TS2739: Type '…' is missing the following properties from type 'PluginContext': registerServiceFactory, replaceService, getServiceScoped": 1
10
+
},
11
+
"src/utils/filter-tokens.test.ts": {
12
+
"TS2352: Conversion of type '…' to type '…' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.": 1
13
+
},
14
+
"src/utils/migration-journal.test.ts": {
15
+
"TS6133: 'rows' is declared but its value is never read.": 1
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?v=4&size=40){kind=avatar}
0 commit comments