Dentolize · Sandbox Build Optimizations Walkthrough
On this pageWhat to testEdge cases worth probingWhat's out of scope for this PR

For Quality

What to test

This PR's own test plan (all unchecked at the time of writing) is the right starting checklist:

  1. Merge and let a sandbox rebuild happen automatically — the sandbox overlay

Dockerfile already sets ENV SANDBOX_BUILD=true (Dockerfile:156), so no manual trigger should be needed.

  1. Watch docker stats during a clinic-web sandbox rebuild. Peak memory should

drop from roughly 5 GB (pre-PR baseline) toward ~1.5–2 GB.

  1. Rebuild the same branch a second time. The second build should be visibly

faster than the first, since /tmp/webpack-cache is warm — this validates the filesystem cache is actually being hit, not just configured.

  1. Run a production build (yarn clinic:web:build:prod:test, which does not set

SANDBOX_BUILD) and confirm it behaves identically to before this PR — same build time, same worker count, no filesystem cache. This is the regression check that matters most, since it's the guarantee this PR makes explicit in its description.

Edge cases worth probing

  • A branch with a real TypeScript error. Since ForkTsCheckerWebpackPlugin is

skipped for sandbox builds, confirm (as expected, not as a bug) that such a branch still produces a sandbox preview — and separately confirm the type error is still caught somewhere else (local dev server, editor, or CI) so it doesn't silently ride along into a later production build.

  • Two different branches sharing the build cache. The cache directory

(/tmp/webpack-cache) is shared across all branches, not per-branch. Build two divergent branches back-to-back and confirm each gets a correct build — no assets or chunks leaking from one branch's build into another's. Webpack keys cache entries by content hash, which should prevent this by construction, but it's the one part of this PR's design that's worth an explicit adversarial check rather than taking on faith.

  • SANDBOX_BUILD set to something other than 'true'. The guard uses strict

string equality (=== 'true'); confirm '1', true (boolean), or an empty string all correctly leave the optimizations off, matching production behavior.

  • Non-production mode with SANDBOX_BUILD=true set. The guard also requires

isProduction; confirm yarn start (dev server) is unaffected even if SANDBOX_BUILD leaks into a local dev environment's variables.

What's out of scope for this PR

  • There is no application UI to test — no screen, permission, or data flow changed.
  • The proposed CI typecheck workflow (to backstop the skipped ForkTsCheckerWebpackPlugin

check) is called out as a follow-up in the PR description, not part of this change. Don't expect it to exist yet.

  • Raising SANDBOX_MAX_CONCURRENT_BUILDS from 2 to 3–4 is described as a later,

separate change enabled by this PR's memory savings — not something to verify here.