Overview

What this PR is

PR #412, "perf(clinic-web): sandbox-gated CRA build optimizations," changes exactly one file: packages/clinic-web/craco.config.js. It adds three build-time optimizations to the clinic-web (React) build, but all three are wrapped in a single guard:

if (isProduction && process.env.SANDBOX_BUILD === 'true') {
  // ...three optimizations...
}

SANDBOX_BUILD is an environment variable that only exists in the internal sandbox build pipeline (the system that spins up disposable preview deployments per branch — the same kind of environment you'd use to demo or test a feature branch before it merges). It is never set for real customer-facing builds. Practically, that means:

• Nothing in the clinic-facing product changes. No screen, workflow, permission,

or data model is touched. Doctors, receptionists, patients, and accountants using Dentolize will never notice this PR happened.

• Nothing in the production build pipeline changes. yarn clinic:web:build:prod,

build:with-sourcemaps, and every other production build script never sets SANDBOX_BUILD=true, so the new code path is dead weight for them — it never runs.

• What it does change is how long a sandbox preview build takes to run and how

much memory it consumes while doing so, on the internal host that builds those previews.

Why it exists

The sandbox host that builds per-branch preview deployments was OOM-killing itself: two concurrent clinic-web builds at ~5 GB of peak memory each were enough to exhaust the host, so the host had been serializing builds through a semaphore (running them one at a time) as a workaround. This PR — paired with a DISABLE_ESLINT_PLUGIN=true environment variable already set in the sandbox overlay Dockerfile — is aimed at cutting that peak from roughly 5 GB down to 1.5–2 GB per build, freeing up headroom to eventually raise the number of sandbox builds the host runs at once.

The three optimizations, in one sentence each

1. Cap Terser (the JS minifier) to 2 parallel workers instead of one per CPU core

(32 on the sandbox host), because each worker holds a full copy of the bundle's syntax tree in memory.

1. Skip ForkTsCheckerWebpackPlugin, which runs a full TypeScript type-check in a

side process during the build — sandbox previews don't need to gate on type errors, since developers already see those in their local editor and dev server.

1. Turn on webpack's persistent filesystem cache, backed by a Docker BuildKit

cache mount, so a second build of the same (or a similar) branch can reuse work from a previous build instead of redoing it.

Each of these is explained in full — plain-language and technical — in Feature breakdown.

A note on this documentation run

This walkthrough would normally include annotated screenshots captured live from the PR's sandbox preview. For this PR, the sandbox preview host, API, and terminal were all unreachable (HTTP 404) at the time this documentation was generated — consistent with the PR's own premise, since this is exactly the kind of build that spins up that preview. There is also no application UI to screenshot regardless: this change never touches a screen a clinic or patient user would see. See Walkthrough for what a reviewer would check instead.