webpack watch mode intermittently reads sdkjs source mid-write, breaking the concatenated bundle and increasing build times

[j-base64]

Issue (at least on my setup)

While running npm run watch:cell (probably affects word/slide/visio too), a save often triggers an error and/or two rebuilds instead of one. When it errors, it's always the first build that fails, with this output:

ERROR in ./dummy.js 927344:1
Module parse failed: Unexpected token (927344:1)
File was processed with these loaders:
 * ./loaders/sdk-concat.cjs
| }(window));
|
> })(window);

sdk-all.js drops to under 1KB on that build. The second rebuild fires right after and produces the correct 30MB+ bundle. Not a one-off, it happens on most saves. At the end the resulting total build time is 4-6 seconds longer and affects the dev experience (from codebase edit to browser test loop duration).

Environment: reproduced consistently on WSL2.

Root cause

Checked with a raw inotifywait -m timestamp log on the edited file during a real save. One save, one CLOSE_WRITE, but 7 separate MODIFY events before it (VS Code flushes the write in chunks). webpack's default watchOptions.aggregateTimeout is 20ms (node_modules/webpack/lib/Watching.js), way too short to cover that whole write burst.

sdk-concat.cjs reads every file listed in configs/cell.json on each rebuild, not just the changed one, since the whole point of the loader is keeping ~400+ files in one shared scope. If webpack fires the rebuild before the OS finishes flushing the just-saved file, the loader reads a truncated copy of it. That breaks the brace/paren balance across the full concatenated module, hence the parse error at the tail end of the bundle instead of near the actual edit.

Normal webpack apps have small, separately-compiled modules, so a torn read on one file just fails that one module and gets silently retried next tick. Here the whole 30MB sdk-all chunk for cell is one module (hope future architecture will allow code splitting for better builds and frontend performance), so any single file's torn read takes the entire bundle down for that cycle.

Proposed fix that worked on my setup

Raise watchOptions.aggregateTimeout in webpack.sdk.factory.mjs (currently unset, so it's on the 20ms default) to something like 500ms. Incremental rebuilds already run 4-8s, so 500ms extra debounce is a small tax against removing a reproducible race. Probably easy to solve through a tiny PR.