🏗️ Architecture: How should rspack WASM run in the browser for Angular compil...

Date: 2026-03-15
Time: 23:13:29 UTC
Session: gspace1-224.6
Agent: angular
Confidence: 98%
Status: ✅ Documented

📋 Decision Context

Question:

How should rspack WASM run in the browser for Angular compilation?

Task: Fix rspack WASM compilation in browser

🎯 Decision Made

Chosen:

Run rspack in a dedicated Web Worker (rspack-compiler.worker.js). Main thread sends enriched files via postMessage, worker compiles via rspack WASM, returns compiled assets as transferable ArrayBuffers.

Options Considered:

1. Run rspack on main thread with Zone.js workarounds
2. Run rspack in Web Worker (chosen)
3. Use esbuild-wasm instead of rspack (no decorator support)
4. Server-side compilation endpoint (network round-trip)

💭 Reasoning

Root cause: rspack WASM uses SharedArrayBuffer + Atomics.wait() for thread synchronization between its main WASM module and the WASI worker (wasi-worker-browser.mjs). Atomics.wait() is permanently blocked on the browser main thread (spec-mandated, all browsers). This caused RuntimeError: unreachable when rspack's NAPI bridge tried to wait for WASM operations. Previous diagnosis of 'memfs split-brain' was incorrect — traced the full module graph and confirmed memfs identity IS preserved through static ESM import chain. The real blockers were: (1) Atomics.wait on main thread, (2) Zone.js intercepting memfs ENOENT errors breaking NAPI callbacks, (3) missing ESM output config (experiments.outputModule), (4) window undefined in worker context. Moving compilation to a Web Worker solves ALL of these: no Zone.js interference, Atomics.wait allowed, clean global scope.

📁 Files Involved

• apps/gograb-space/src/rspack-compiler.worker.js
• libs/libs-structural/platform-preview/src/lib/services/bundler.service.ts
• tools/scripts/build/bundle-rspack-browser.ts

🔗 Related

• Decision ID: dev_1773616409382_6ncaho5
• Session: 224
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation