ReviewOS

home-lang/home

fix(ts): preserve JSDoc types on imported JavaScript class fields

#946
Closed glennmichael123 opened this 7 days ago ·
7 days ago

Parent: #846. Related: #945 (constructor-assigned generic fields; separate path).

On origin/main ed04a5c5b, with TypeScript 5.7.3 and a freshly rebuilt Home home-tsc, this non-generic cross-file fixture differs:

// owner.js
export class Box {
  /** @type {string} */
  value = /** @type {*} */ (null);
}
// consumer.ts
import { Box } from "./owner.js";
const box = new Box();
box.value = 1;
const bad: number = box.value;

Under strict, allowJs, checkJs, noEmit, skipLibCheck, target es2022, and node resolution, TypeScript reports two TS2322 diagnostics: number is not assignable to string at (3,1), and string is not assignable to number at (4,7). Home reports two TS2322 diagnostics at the same positions but treats the field as null: literal 1 is not assignable to null, then null is not assignable to number. The source JSDoc annotation is being lost to the initializer type on the source-owned direct class-field path. The same shape with a defaulted JSDoc class template also differs, but the non-generic fixture proves this is independent of template transfer.

Acceptance: retain the declared JSDoc field type across the JS-to-TS Program/CLI import boundary, preserve the separate initializer check, match the positive and negative TypeScript diagnostics, add serial/parallel Program and real CLI regressions, and pass the relevant full guarded suites. Do not treat the field as any, suppress diagnostics, or special-case this fixture.

7 days ago

First verified slice is on origin/main as dc40a05, authored and committed by glennmichael123 without coauthors. Source-owned schema now retains direct instance/static JSDoc field types, including defaulted class-template references; the static modifier is included when associating the leading comment. Guarded Program 422/422 and CLI 85/85 passed, checker target is a successful cache hit from its 4684/4684 full run, and rebuilt home-tsc matches TypeScript 5.7.3 on concrete instance, simple static, defaulted-generic instance, and invalid owner initializer controls. Keeping #946 open: a separately reproduced static class with both a JSDoc-typed field and an unmodeled static method still falls back to the initializer type. TypeScript reports string/number TS2322, Home reports null-based TS2322. Next step is per-member static schema overlay without discarding unrelated static members.

7 days ago

The independently reproduced direct class-field cases in this issue are resolved by dc40a05 and 2eb23ca, both pushed to origin/main as glennmichael123 without coauthors. Source-owned JSDoc field types now win over initializer inference for imported instance and static fields, including a defaulted class-template field. A supported static field remains typed when a sibling static method cannot enter the complete schema; the sibling stays available through its existing projection. TypeScript 5.7.3 and freshly rebuilt Home home-tsc match on concrete instance, simple static, mixed static, defaulted-generic instance, and invalid owner-initializer controls. Positive reads/writes and negative diagnostics are covered by serial/parallel Program and CLI regressions. Final guarded Program 422/422, CLI 85/85, checker 4684/4684 and home-tsc build pass; no heavy processes overlapped and peak tree footprint stayed below 3,840 MB. This closes the reproduced field-transfer gap, not all possible JSDoc syntax or all of #846.

Sign in to comment on this issue.