Problem
Home loses tuple element positions when a Map<K, V> is spread into an array and consumed by chained filter / map callbacks with destructured parameters. For [string, Flags], both callback bindings become string | Flags; TypeScript preserves the tuple and infers the final key array as string[].
This accounts for the three remaining TS2345 diagnostics at src/v4/core/schemas.ts:2827:100, :2830:52, and :2830:89 in the pinned Zod 4.5.2 graph.
Fair oracle
Strict same-file reduction in /tmp/home-ts-map-callback-tuples:
type Flags = { l?: true; r?: true };
const entries = new Map<string, Flags>();
const bothKeys = [...entries]
.filter(([, flags]) => flags.l && flags.r)
.map(([key]) => key);
const valid: string[] = bothKeys;- TypeScript 6.0.3: clean.
- Native TypeScript 7.0.2: clean.
- Current Home ReleaseFast: two false TS2339 diagnostics on
flags.l/flags.r, then TS2322 becausebothKeysis(string | Flags)[].
The appended negative changes only the final annotation to number[]:
- TS 6 and TS 7: exactly one TS2322,
string[]not assignable tonumber[]. - Home must retain exactly that negative after the fix.
Acceptance
- Preserve positional
[K, V]tuple information through Map iteration, array spread, contextual callback destructuring, and chained array methods. - No special cases for Zod,
bothKeys, property names, or source locations. - Add a permanent positive/negative checker regression.
- Run focused and full checker suites plus Program.
- Compare the complete pinned Zod diagnostic-key set against post-#659 main; expected target is removal of the three identified TS2345 keys with zero additions, but the exact measured delta decides admission.
- Keep Zod untimed until its diagnostic gate reaches zero; document accepted results in the README and
TS_PERFORMANCE.mdunder #416.