#948 · home-lang/home

Found while verifying #947, but independently reproducible with a TypeScript-owned declaration (so it is not a JavaScript import-transfer defect).

Control: export const settings: { label?: string } = {}; settings.label = 42;

TypeScript 5.7.3 reports TS2322 Type 'number' is not assignable to type 'string'. Home reports TS2322 Type '42' is not assignable to type 'string | undefined'. The observed richer control also has readonly and nested fields, whose diagnostic codes and positions already agree. The mismatch is source-literal widening and optional write-target display in generic assignment reporting, not an admitted-JS special case.

Acceptance: reproduce with TypeScript-owned and checked-JS-imported shapes, fix the general assignment diagnostic construction without suppressing errors or changing assignability, retain literal-vs-literal diagnostics and exactOptionalPropertyTypes cases, and pass guarded checker/Program/CLI suites. Related #846 and #947.

Completed by 5e31d08 on origin/main, authored/committed as glennmichael123 without coauthors. The checker now selects the concrete member of a two-member T | undefined assignment target for diagnostic presentation when a concrete non-nullish source fails, and widens fresh literal source names accordingly. Assignability itself is unchanged; nullish, unknown, and union sources continue to report against the full union. The new checker regression covers number, boolean, number | undefined, null, and literal-vs-literal cases. Fresh TypeScript 5.7.3 and rebuilt home-tsc match the real-file matrix on codes, positions, messages, and secondary chain, and the richer checked-JS import control from #947 now matches all four diagnostics exactly. Serial 3,840 MB guarded checker 4685/4685, Program 425/425, CLI 85/85, and home-tsc build passed. Existing exactOptionalPropertyTypes checker controls remain green. This closes the independently reproduced diagnostic gap; it does not close the broader #846 admission issue.