2026 Frontend Pitfall Checklist:
Rspack vs esbuild on a Remote Mac — Cache, Cold Start & Workers
Large frontends on a rented remote Mac pay twice for bad bundler policy: once in wall-clock minutes and again in flaky CI when caches collide. This checklist contrasts Rspack (webpack-shaped graphs plus filesystem cache) with esbuild (Go-parallel, single-pass speed), names executable directories and environment variables, and ends with a three-step ship gate. Use it next to our Vite and Webpack cache guide and monorepo remote-cache checklist so turbo tasks and bundler layers agree on keys.
01 Scenario and baseline
Assume a large monorepo or a multi-package workspace built on a remote Mac runner: installs land on APFS, builds compete with sshd and optional GUI remoting, and CI restores tarballs or object storage for node_modules and tool caches. Your baseline must separate cold start (no bundler cache, or first run after clone) from incremental (second production build on the same commit with cache intact).
Record four numbers per toolchain: cold wall time, warm wall time, peak resident set size, and total cache bytes on disk. Attach the git SHA, lockfile hash, and exact node -v / Rspack / esbuild versions. Without that tuple, “fast on my branch” is not reproducible when you merge. For CSS and PostCSS-heavy pipelines, cross-check memory guidance in our Tailwind v4 and PostCSS memory matrix before you blame the bundler alone.
02 Rspack vs esbuild applicability boundaries
Rspack targets teams migrating from webpack: loaders, splitChunks, module federation-style patterns, and a filesystem cache that survives process restarts when configured. It is the right default when your graph is huge, custom, and you need incremental rebuilds across days on the same workspace disk.
esbuild is strongest when you want minimal configuration and maximum single-shot throughput: libraries, internal packages, or pipelines that call the API/CLI for transpile and bundle steps. It does not give you a webpack-grade persistent module graph cache; speed comes from aggressive parallelism and a tight implementation. Mixing both is common: esbuild for focused packages, Rspack for the application shell that needs loader depth.
| Dimension | Prefer Rspack | Prefer esbuild |
|---|---|---|
| Loader and plugin depth | Heavy custom loaders, legacy asset graph | Mostly TS/JS, JSON, limited custom plugins |
| Persistence goal | Multi-day warm workspaces; CI cache restore | Ephemeral CI steps; speed without long-lived cache |
| Operational owner | Teams already fluent in webpack config | Teams optimizing for minimal config surface |
03 Cold start and incremental comparison table
The table below is your acceptance shorthand. Tweak paths to match your repo layout; keep one cache root per major tool version so restores do not deserialize incompatible blobs.
| Topic | Rspack (webpack-shaped) | esbuild |
|---|---|---|
| Cold start profile | First build after cache purge; pays graph compile and module read | Usually fastest cold among Node bundlers; still disk-bound on huge entry trees |
| Incremental profile | Strong when cache.type: 'filesystem' enabled and keyed correctly |
Incremental benefit often from skipping work via wrapper or monorepo task graph, not a webpack-style module cache |
| Typical cache directory | node_modules/.cache/rspack or explicit cache.cacheDirectory (e.g. .rspack-cache at repo root) |
No first-party persistent module cache; store build outputs or use upstream task cache (Turborepo, Nx) |
| Persistent cache switch | cache: { type: 'filesystem', buildDependencies: { config: [__filename] } } in rspack.config |
N/A at bundler core; persist artifacts at CI layer |
| Parallelism / workers | Node process; limit concurrent heavy steps; optional thread-loader patterns from webpack era | GOMAXPROCS=<n> to cap Go worker fan-out (example: export GOMAXPROCS=6) |
| Heap and thread pool | NODE_OPTIONS=--max-old-space-size=8192 (raise if RSS OOM); optional UV_THREADPOOL_SIZE=16 for fs-heavy native addons |
Not Node heap; still set conservative GOMAXPROCS when Node wrappers orchestrate esbuild |
export NODE_OPTIONS="--max-old-space-size=8192"
export UV_THREADPOOL_SIZE=16
export GOMAXPROCS=6
Adjust heap and GOMAXPROCS to your host: on an eight-performance-core class machine, leaving one or two cores free for macOS and SSH usually stabilizes tail latency.
04 Remote Mac disk and memory thresholds
Treat disk and RAM as part of the bundler contract. Filesystem caches grow with module count and with source map tiers; remote desktops also need headroom for Spotlight, Time Machine metadata, and user sessions.
| Signal | Conservative threshold | Action |
|---|---|---|
| Free disk after restore | At least 25 GB free for medium monorepos; 40 GB if you keep multiple cache generations | Prune old .rspack-cache dirs; dedupe CI cache keys; avoid storing duplicate node_modules trees |
| Cache directory growth | Warn when week-over-week growth exceeds 20% without dependency changes | Invalidate on config hash change; audit source maps and asset copies |
| Peak RSS during build | Stay below roughly RAM − 8 GB on shared 24–36 GB hosts | Lower parallelism, split packages, or shard CI jobs |
| Swap pressure | Sustained swap > 2 GB during compile | Reduce simultaneous Rspack and esbuild jobs; run sequentially |
05 Pre-release three-step acceptance and FAQ
Step 1 — Cold truth: From a clean cache state on the release SHA, run the production build once and archive the log. If cold time regresses more than fifteen percent versus the last green release without dependency major bumps, stop and diff config.
Step 2 — Warm contract: Immediate second build must drop wall time materially (typical target: at least twenty-five to forty percent vs cold for Rspack with filesystem cache). If warm is not faster, your cache path is wrong, keys are too aggressive, or antivirus-style scanning is thrashing the cache dir.
Step 3 — Shared host courtesy: With GOMAXPROCS and Node parallelism capped, confirm interactive SSH latency stays acceptable during the build. Promote only after all three pass.
Q: Should I point Rspack cache to NFS or a network volume?
A: Prefer local APFS on the remote Mac; network latency destroys filesystem cache wins.
Q: One job or two for Rspack plus esbuild?
A: If combined RSS approaches your threshold, serialize or shard by package graph; parallelize only when memory telemetry allows.
Q: Where do Turborepo and Rspack caches interact?
A: Turbo caches task outputs; Rspack caches module graph work inside the bundler task. Key both with lockfile and config hashes so remote cache hits align.
Pick Rspack when you need webpack-depth graphs and a filesystem cache you can restore in CI; pick esbuild when you want brutal single-pass speed and can accept cache strategy at the orchestration layer. Instrument cold vs warm, protect disk and RAM headroom on remote Mac hosts, and ship only after the three-step gate passes.
When you are ready to run these builds on dedicated Apple Silicon, open the MacWww home page, review plans and pricing for transparent rental options, and use the help center for SSH, console, and automation setup. Continue with the frontend and DevOps blog index for adjacent checklists.
If your team needs predictable macOS runners for Rspack and esbuild pipelines, purchase or reserve capacity through MacWww so cold starts happen on NVMe-local workspaces instead of oversubscribed shared VMs.
Run Rspack and esbuild on a Rented Mac
Local APFS cache dirs, real core counts for GOMAXPROCS tuning, and room for monorepo installs. Start from the home page, compare pricing, then follow help docs to wire your CI runner.