Discovered while doing #1839 (the vitest/Storybook exact-pin untangle).
Untying the @vitest/browser peer knot required regenerating clients/web/package-lock.json, which floated every other in-range dependency to current. One of those floats — zod 4.3.6 → 4.4.3 — makes clients/web's tsc -b run out of memory:
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
sh: line 1: 16604 Abort trap: 6 tsc -b
It dies at the ~4GB default heap after ~29s. Reverting zod to 4.3.6 and changing nothing else makes tsc -b exit 0 immediately, so the attribution is unambiguous.
The hold
clients/web/package.json now declares "zod": "~4.3.6" (was ^4.3.6) so the vulnerable-to-OOM 4.4.x line cannot be picked up by a fresh resolve. This is a deliberate, temporary hold, not a preference — it needs removing once the underlying issue is addressed.
Note the divergence this creates: the root and clients/tui still declare ^4.3.6, and clients/tui currently resolves 4.4.3 without trouble (it does not typecheck the same web-side generic-heavy surface). So the constraint is web-specific today, which is itself worth confirming rather than assuming.
What to do
- Reproduce against zod
4.4.x and find whether it is a zod regression (worth an upstream issue) or a pathological inference site in our own code that 4.4 merely made expensive.
- If it is ours, fix the inference site — a hot spot is more likely to be one or two schemas than the whole surface.
tsc --generateTrace / --diagnostics will point at it.
- If it is upstream, track the zod issue and re-test on each 4.4.x patch.
- Either way, restore
clients/web to ^4.3.6 (or move all three manifests forward together) so the three declared ranges agree again.
Raising the heap with --max-old-space-size is a workaround, not a fix, and would hide a real regression in typecheck cost — prefer diagnosing it.
Discovered while doing #1839 (the vitest/Storybook exact-pin untangle).
Untying the
@vitest/browserpeer knot required regeneratingclients/web/package-lock.json, which floated every other in-range dependency to current. One of those floats — zod4.3.6→4.4.3— makesclients/web'stsc -brun out of memory:It dies at the ~4GB default heap after ~29s. Reverting zod to
4.3.6and changing nothing else makestsc -bexit 0 immediately, so the attribution is unambiguous.The hold
clients/web/package.jsonnow declares"zod": "~4.3.6"(was^4.3.6) so the vulnerable-to-OOM 4.4.x line cannot be picked up by a fresh resolve. This is a deliberate, temporary hold, not a preference — it needs removing once the underlying issue is addressed.Note the divergence this creates: the root and
clients/tuistill declare^4.3.6, andclients/tuicurrently resolves 4.4.3 without trouble (it does not typecheck the same web-side generic-heavy surface). So the constraint is web-specific today, which is itself worth confirming rather than assuming.What to do
4.4.xand find whether it is a zod regression (worth an upstream issue) or a pathological inference site in our own code that 4.4 merely made expensive.tsc --generateTrace/--diagnosticswill point at it.clients/webto^4.3.6(or move all three manifests forward together) so the three declared ranges agree again.Raising the heap with
--max-old-space-sizeis a workaround, not a fix, and would hide a real regression in typecheck cost — prefer diagnosing it.