fix(ts-checker): reconcile checked-JS constructor diagnostics with TypeScript 5.7.3

Evidence

The guarded zig build test -Dfilter=ts_checker -j1 run on 2026-10-30 completed 4,705 pass / 11 fail / 4,716 total, with a 2,270 MB peak counted tree footprint. These failures are concentrated in checked-JavaScript constructor, this, prototype, JSDoc and virtual multi-file expectations. The exact failing test names are:

• parity final checkjs virtual constructor function conflicts with sibling class
• current tsgo checked JS void-zero assignments declare implicit-any expandos
• tsgo parity batch treats nullish JS this initializers as non-constructable
• inferred JavaScript constructors remain value-only in JSDoc
• checked JavaScript functions stay value-only heritage bases
• prototype owner recovery stays within its virtual function
• strict checkjs prototype methods keep ordinary function this
• checkjs prototype object functions report implicit params and missing this members
• constructor templates stay outside separately declared prototype methods
• checkjs prototype property @type access does not declare constructor
• CommonJS sub-functions use the prior whole-export function type

Several expectations are based on older tsgo behavior and conflict with TypeScript 5.7.3. Independent real-file controls for the exact fixture sources show, for example: the nullish constructor case has three TS2322 and no TS2683/TS7009; the ordinary prototype method writes have four TS2322 and no TS2683; the Color.prototype method case has two TS7006 and one TS2339; and the C.prototype.x JSDoc access case has TS2322 rather than TS2683/TS7009. The void 0 expando fixture has five TS2339, while Home currently reports fewer, so changing its assertion alone would hide a real false negative. Some other fixtures need their file/module settings checked against the TypeScript control before adjusting expectations.

Acceptance

Reproduce each failing fixture under pinned TypeScript 5.7.3 with matching file, module and compiler options. Fix Home semantics where diagnostics differ; update only expectations that are demonstrably stale. Keep exact diagnostic codes and useful messages asserted, with no blanket suppression or fixture-name branches. Rerun the focused controls and the full checker suite under the authorized 3,840 MB guard. This issue is related to admitted-JavaScript parity #846, constructor follow-up #966, and the wider port #66.

2026-11-02 progress: 228b129f3, d7ce02aea, and 0632dcbd6 are pushed to origin/main as Glenn without coauthors. Checked-JavaScript constructor inference now uses the function's this member assignments even under noImplicitAny, and two recovery tests were corrected against exact TypeScript 5.7.3 real-file controls. The guarded home-tsc build and 134/134 exact admitted-JavaScript CLI oracle streams passed. The #966 chained CommonJS prototype edit/revert LSP test also passed with the dedicated guarded test-ts-lsp step (1,957 MB peak counted tree footprint) and is pushed as 0632dcbd6.

A fresh full guarded ts_checker run after those commits completed 4,705 pass / 11 fail / 4,716 total, with a 2,245 MB peak counted tree footprint and 46% host low-water. The remaining 11 failures include virtual sibling-class ownership, void-zero expandos, JSDoc constructor type references, prototype-method instance writes and receiver display, constructor templates, nested expando functions, JSDoc prototype property types, CommonJS sub-functions, and two wider checked-JS this assignment cases. TypeScript 5.7.3 controls show the latter Installer fixture should emit TS7008, four TS2322 and TS2531 (Home currently misses those), and the nested-assignment fixture should emit two TS2339 plus two TS7053. The constructor-template fixture emits no diagnostics even under --strict. These remain genuine semantic/expectation work; this issue stays open. See #966, #846, and #66.

Pushed a17074639 to origin/main as glennmichael123: checked-JS prototype methods now resolve this to the inferred constructor instance before checking member writes. The Color.prototype and strict constructor-write fixtures were independently checked against TypeScript 5.7.3 and both focused Home tests pass under the 3,840 MB guard. git diff --check passes.

The full 4,716-test checker suite and 134-stream CLI audit remain pending for this commit. Host memory fell to 31–32% while a separate Zig test run in another project was active; I am waiting for the agreed >=40% threshold before running them. The prior verified full-suite baseline remains 4,705 pass / 11 fail.

Pushed 476a8e4eb to origin/main as glennmichael123, without coauthors. In checked JavaScript, a function that initializes instance members through this now resolves as an instance type in a JSDoc name position before the bare-function value-only check. The exact TypeScript 5.7.3 .js control has zero diagnostics; the focused Home checker test passes with zero diagnostics and zero unmodeled-any sites under the 3,840 MB guard (1,809 MB peak counted tree footprint).

I also reproduced three other affected fixtures against TypeScript 5.7.3: nested CommonJS expando and whole-export sub-functions each have zero diagnostics; prototype @type property access reports exactly one TS2322. Their Home test corrections remain uncommitted pending the full checker run. The guarded full suite is queued to start when host memory reaches the agreed 40% threshold. #966 and #846 remain linked.

Pushed 316fb86ce to origin/main as glennmichael123, without coauthors. It corrects two stale checker expectations against TypeScript 5.7.3: the strict variable-constructor prototype object has one TS2339 (addon) and the CommonJS whole-export sub-function fixture has zero diagnostics. Both focused controls pass in Home under the 3,840 MB guard.

A full guarded checker run including local in-progress corrections completed 4,708 pass / 8 fail / 4,716 total (2,133 MB peak counted tree footprint). One of those eight was the strict prototype-object expectation corrected and focused-tested in 316fb86ce. The other seven are virtual sibling-class ownership, void-zero expandos, constructor templates, nested expando functions, prototype @type write checking, the Installer implicit-any array/nullable access case, and nested this access diagnostic codes. I am diagnosing those as semantic differences; the remaining local edits are uncommitted. The 134-stream CLI audit for this batch remains pending.

2026-11-02 checkpoint: 801061ed5 and f39287d68 are pushed to origin/main under Glenn's author/committer identity. The first applies a bare /** @type {T} */ C.prototype.x; declaration to the constructor instance and checks incompatible this.x writes; the exact TypeScript 5.7.3 control reports one TS2322, and Home's focused and related prototype tests pass. The second fixes nested CommonJS object exports: inferred object literal receivers accept nested writes, declared/scalar receivers retain TS2339, and a nested module["exports"]["d"].e write becomes visible through require. The real two-file TypeScript control has zero diagnostics; Home's focused tests and the 52-test CommonJS checker group pass.

The full checker suite, LSP revision coverage, and 134-stream CLI audit have not been rerun on these commits. The remaining Installer TS7008/TS2531 and other checked-JS constructor cases remain open; no full-suite parity claim yet. Related: #966, #846, #66.

2026-11-02 differential checkpoint against TypeScript 5.7.3 (guarded tsc --allowJs --checkJs --noEmit --strictNullChecks --noImplicitAny):

• A constructor-only this.a = [] has no TS7008. A prototype method that reads or writes this.a causes one TS7008 at the constructor's empty-array assignment. An empty prototype method, or one using only another field, does not.
• A concrete later constructor assignment (this.a = [1] or this.a = 1) removes that TS7008; null/undefined assignments do not. If the field can be null, an unguarded this.a.push(...) also causes TS2531.
• The exact Installer control has six diagnostics: TS7008, four TS2322, TS2531. Home currently emits four TS2322 plus five secondary TS2551 for the missing twices field. The corrected focused test intentionally fails until that field inference and nullability are fixed.

A source-side TS7008 rule is being validated under the 3,840 MB Zig guard. Host memory fell below the required 40% threshold, so no further Zig build has been started. This remains linked to #966 and #846.

TypeScript 5.7.3 controls for the checked-JavaScript constructor work:

• The existing jsdocTemplateTag4.js fixture reports zero diagnostics with --allowJs --checkJs --noEmit --strict (and also with strict disabled). Home's existing checker test expects six TS2304, two TS2683, and three TS2339; those expectations are stale relative to this control and need a Home-side parity fix before changing the assertions.
• A separate constructor fixture with this.items = [] reports TS7008 when a prototype method reads the field, writes it, or captures it in an arrow. An unused field and a field given a concrete constructor value do not report TS7008. The focused Home test now covers all five cases and expects exactly three TS7008 diagnostics.

The current checker, Program, and LSP edits remain uncommitted pending compiled Zig verification. zig fmt --check, zig ast-check, and git diff --check pass for the checker edit. Host memory is 31%, below the agreed 40% threshold for a guarded Zig build; no build has been started.

Additional TypeScript 5.7.3 controls, run against the exact checker fixture sources with --allowJs --checkJs --noEmit --skipLibCheck --pretty false:

• jsdocTemplateTag4.js (Multimap, Multimap2, Ns.Multimap3): zero diagnostics with strict both on and off. The existing Home test expected 11 diagnostics.
• The Cls<T> prototype-method fixture: zero diagnostics under --strict. TypeScript's emitted declaration has class Cls<T extends string> with m<V extends string>(t: T, v: V): V, confirming constructor T is in the method's scope.
• The Zet<T> prototype assignment fixture: exactly one TS2322 (Type 'boolean' is not assignable to type 'number'.) with strict both on and off; no TS2304 or TS7009.

I corrected the three Home test expectations to those proven controls. The implementation still has explicit paths that diagnose constructor template references as unsupported (reportUnsupportedJsConstructorTemplateReference and reportPrototypeConstructorTemplateReferences); those must be replaced by real scope resolution. The edits are not committed: compiled verification is pending the 40% host-memory gate (currently 33%). zig fmt --check, zig ast-check, and git diff --check pass.

Guarded compiled checker results after the constructor/this work in the local working tree:

• checked JavaScript constructors check instance writes under noImplicitAny: passes with the exact TypeScript 5.7.3 counts (TS7008 ×1, TS2322 ×4, TS2531 ×1). The missing twices field came from identifier-form this choosing a method-local receiver before the constructor instance; the local fix makes the constructor receiver visible while preserving explicit this handling.
• JavaScript constructor empty arrays become implicit any on prototype use: passes for read, write, arrow capture, unused field, and later concrete constructor write.
• untagged constructor template remains in prototype method scope: passes after replacing the synthetic TS2304 path with constructor template resolution.
• Still failing: constructor templates remain in separately declared prototype methods has five prototype-shape/this diagnostics against TypeScript's zero; constructor templates scope prototype JSDoc without constructor tag still has TS7009 against TypeScript's sole TS2322; the method-template shadow fixture misses TypeScript's TS2322; an explicit JSDoc function(this: {v: number}): void fixture reports TS1005 and checks this as the constructor instead of the declared object.

The constructor edits remain uncommitted and unpushed while these real semantic differences are resolved. The independent CommonJS Program/LSP chunk was pushed as bd3371310 and is tracked on #966.

TypeScript 5.7.3 controls run today with matching checked-JS settings:

• An untagged Box<T> function that writes this.value accepts @type {Box<number>}; assigning box.value to a JSDoc string variable produces exactly one TS2322 (number to string). The generic constructor reference must instantiate the instance member, not recover to any.
• @type {function(this: {v: number}): void} on C.prototype.m produces exactly one TS2339 for this.arg; the Closure-style JSDoc function type is valid and gives the method an explicit receiver.
• The exact object-property fixture in the checker test (function(number): number on three members, strictNullChecks and noImplicitAny) produces seven TS2322 and one TS2345, with no TS1005 or TS7006. The existing expectation of three syntax errors is stale.
• Cp.prototype = { m1() {...}, m2() {...} } with Cp constructor fields produces no diagnostics; those methods see the constructor instance fields.

Focused checker code and regression tests are local; zig fmt --check and zig ast-check pass. No compile, commit, or push is claimed yet: host kern.memorystatus_level is 28, below the agreed 40% gate for the guarded 3,840 MB Zig build. I will run the focused tests and full suite when the gate permits.

Additional exact TypeScript 5.7.3 checked-JS control: /** @type {identity} */ and /** @type {identity<number>} */ for a call-only generic JavaScript function both resolve to the function type (typeof identity in emitted declaration text), not TS2749. Assigning the result of identity(1) to that type produces one TS2322 (number vs <T>(value: T) => T). The local checker patch now distinguishes this from a function that writes this, whose JSDoc name denotes the constructed instance.

The older generic JavaScript constructor patterns keep tsgo diagnostics test was also checked verbatim with TypeScript 5.7.3: it emits zero diagnostics. Its expected TS7009/TS2749/TS2339 are stale and have been corrected locally.

The guarded Zig build has not run. A 30-second launch check stayed below the agreed 40% host-memory threshold (last sample 35%) and exited without starting the compiler. No commit or push is claimed for these local edits.

Checkpoint: the first guarded focused checker build completed under the 3,840 MB guard (about 1.7 GB peak tree footprint). The new Box<number> regression test still failed: Home emitted no TS2322 for assigning box.value to string. This is a real remaining semantic gap, so the constructor patch is not ready to commit.

Root cause found in the shared JSDoc scanner: a single-line comment such as /** @template T @param {T} t */ yielded only the first tag, losing the constructor parameter type. TypeScript 5.7.3 recognizes both tags and gives Box<t>.value type T. A local parser change now scans multiple tags per line outside nested type syntax, with focused parser coverage; it has passed static syntax/diff checks but has not yet passed compiled tests. The host memory admission level stayed 32–37 (required: at least 40) during this turn, so no further Zig build was started. Next: guarded parser test, focused checker regression, then remaining constructor cases and full suite.

Verified checkpoint: 90b9d6325 is on origin/main, authored as glennmichael123 with no coauthor. It ports same-line JSDoc tag scanning: the standalone parser suite passed 23/23 (127 MB guarded peak), and the focused Box<number> checker regression passed (1,679 MB guarded peak). The parser fix removed the missing @param {T} that had erased the constructor's generic field type.

The first full checker run after that parser fix completed 4,716 pass / 10 fail out of 4,726, 2,311 MB guarded peak. The remaining failures are not declared solved. Direct TypeScript 5.7.3 controls identified stale expectations for a JSDoc Value[] parameter and six callable JSDoc receivers; both corrected focused Home tests now pass locally. A separate valid Closure-style function(): string return annotation exposed a real missing async TS1064/TS1055 check; the local semantic fix passes focused ESNext and ES5 controls. The combined full suite, LSP revisions and CLI audit still need reruns before the checker patch can be pushed. A subsequent guarded run was correctly refused at 38% host memory against the 40% admission threshold.