`assert-dist-built.mjs` validated the emitted renderer chunks by spawning
`node --input-type=module --check` once per chunk. A real bundle here emits
~960 `.js` chunks (31 MB), so the postbuild step performed ~960 sequential
process creations: 47-80 s wall clock measured on an idle machine (median
77 ms per spawn, worst 446 ms). That made the update's build step depend on
~960 successful process creations.
On Windows one spawn stalled past its 60 s budget and returned ETIMEDOUT
(`could not run node to syntax-check nord-D92QzZWU.js`), which failed
`npm run build` and aborted the entire update (receipt outcome "failed",
exit 1) even though vite had reported `built in 54.73s`. Nothing was wrong
with the bundle or with node - a single process creation was slow.
Parse every chunk in one child instead: `scripts/check-chunks-parse.mjs`
uses `vm.SourceTextModule` - the in-process module parser, hence
`--experimental-vm-modules` - and writes a JSON verdict on stdout. It
reports the same early errors as `node --check`: invalid destructuring
patterns and duplicate declarations still fail, so the guard keeps catching
the corrupted-silent-fail bundle it was written for. Same verification now
costs one process creation and ~1.5 s instead of ~960 spawns and 47-80 s.
The verdict carries `kind`, and the guard reports `harness` when the check
could not run versus `bundle` when the build is defective. The line is drawn
at the checker: only a SyntaxError is a bundle defect; an unreadable chunk or
an unavailable vm API is a failure of the check itself. Previously every
failure printed "The renderer bundle is missing or incomplete ... Re-run the
build", so a blocked or stalled node process was reported as a bundle defect
and sent at least one investigation after a problem that did not exist.
