Apps: rspack build prototype

[breville]

[written by Claude]

This PR adds an optional, parallel rspack build for apps/ — nothing about the existing build changes. yarn start, yarn build, yarn test, CI, and production builds run exactly as before; the webpack path stays the default and the source of stability. The new system only runs when invoked by its own commands, so folks can try it on real work and fall back instantly, and we can discuss adoption with zero switching pressure. The touch points on shared files are two exported constants in webpack.config.js, added (unused-by-default) scripts in package.json, and one small applab source fix described below.

Rspack is a Rust implementation of webpack: it accepts the webpack 5 config surface and plugin/loader API, so our config translates nearly verbatim rather than being rewritten. It embeds swc ("Speedy Web Compiler", a Rust JS/TS compiler) as a built-in transpiler that can stand in for babel-loader and ts-loader.

The motivation: frontend devs wait ~2.5 minutes for yarn start and 12–47 seconds per rebuild. The rspack dev server starts in ~10 seconds and rebuilds in 6–20 seconds (6–7.5 with the disk copy turned off, below).

rspack.config.js translates createWebpackConfig(): same entries, aliases, loaders (including our EJS loader), externals, named runtime chunk, and splitChunks cache groups. Each deliberate divergence is marked RSPACK-DIFF with rationale. Output parity with the webpack build is 3633/3634 named manifest assets — the one gap is fonts referenced by root-relative url('/fonts/...'), which dashboard serves anyway.

Measured on an 8-core/30GB dev box, full 240-entry dev build, typecheck skipped (both systems run it as a separate process):

	webpack	rspack + swc
dev-server startup	155s	~10s
rebuild, leaf file edit	12.2s	6.0s
rebuild, util/color.js edit	47.2s	20.3s (7.5s with RSPACK_NO_WRITE=1)
build from scratch: wall / total CPU	130s / 210 CPU-s	10s / 37 CPU-s
dev-server steady-state memory	5.9GB	4.5GB

swc keeps no persistent cache, so its 10-second build IS the from-scratch build. The total-CPU column is the deeper story: rspack+swc does ~6x less compute per build, not just more parallel compute. Rebuilds are bounded by emit, not compilation — a shared-file edit recompiles one module but rewrites every entry bundle it invalidates, which is why rebuilds can exceed a from-scratch startup and why RSPACK_NO_WRITE=1 (skip the dev-server's disk copy; pages load from server memory) cuts the shared-edit rebuild to 7.5s. The disk copy stays on by default because direct-to-Rails access and anything else reading build/package still needs files.

HMR with React Fast Refresh works as under webpack (HOT=1), verified by hot-applying an edit into a live page with no reload and state preserved — so the rebuild rows above are the full editor-save-to-patched-page latency. As with webpack, Fast Refresh hot-swaps function components in place, while edits to class components (most legacy lab UI) fall back to a full re-render through the same hot-update pipe.

The engine swap alone is not the story: rspack running our unchanged babel/ts-loader set only improves the from-scratch build from 130s to 88s. The speedup comes from swc replacing babel-loader and ts-loader. Making that safe required reproducing four babel behaviors the codebase depends on, all in config — no source codemods:

• lib/add-module-exports-shim-loader.js restores add-module-exports unwrapping and babel's rule of stamping __esModule only on modules with export declarations (unit-tested);
• isModule: 'unknown' mirrors sourceType: unambiguous, so legacy CJS files stay sloppy scripts instead of gaining "use strict";
• jsc.assumptions gives loose classes (enumerable prototype methods, which CustomMarshalingInterpreter's for..in marshaling needs) without loose spread, which babel never applies and which passes Sets through [].concat unexpanded.

Two toggles select how much swc takes over: RSPACK_SWC=ts replaces only ts-loader (conservative; the yarn start:rspack default) and RSPACK_SWC=all also replaces babel-loader (the ~10s path). All browser verification was done in RSPACK_SWC=all mode, signed in: App Lab, Game Lab, Dance Party, Sprite Lab, Web Lab 2, Music Lab including playback, and Python Lab including executing code through the pyodide web worker. Applab unit tests pass; a stock-webpack build of the applab entry on this branch succeeds.

The shakedown also surfaced dead code: src/applab/ai/dropletConfig.js (2021, intended to gate the getPrediction block behind level.aiEnabled) has never had an effect — it reads a const before its declaration, which babel silently compiles to [undefined] while swc's spec-compliant helper throws, and two further layers documented in #74080 made the gate a no-op regardless. This PR carries the minimal reorder so the file survives spec-compliant spread; #74080 deletes the module outright and supersedes the reorder once merged.

Example, from apps/:

yarn start:rspack        # dev server on the usual port, proxying to dashboard
yarn build:rspack        # one-shot dev build

Not in scope: production/minified builds, karma, grunt integration, and the circular-dependency allowlist (the rspack plugin reports cycles as warnings rather than failing). webpack.timing.config.js and webpack.rung1.config.js are the measurement harnesses behind the numbers, kept so results are reproducible; two findings from them worth keeping even if rspack is rejected: webpack's own filesystem cache is not viable at our scale (multi-GB on disk, OOM on restore), and experiments.lazyCompilation imports-only cuts stock webpack startup 155s→95s. Separately: fresh webpack builds currently fail the circular-dependency checker on staging — circular_dependencies.json is missing the direct AssetManager ⇄ AudioRecorder cycle.