jest --maxWorkers tuning for CI runners

TL;DR

--maxWorkers trades speed for memory. On CI, set it to 50-75% of available CPUs, lower if workers crash, and measure rather than guessing.

Error

(Not an error; a tuning task. Symptoms: Jest is slow with too few workers, or crashes with too many.)

Steps

1. Find the runner's CPU count (nproc). Expected: the ceiling.
2. Start with --maxWorkers=50%. Expected: a safe baseline.
3. Time the suite. Expected: a number to compare.
4. Try 75% and 100%; keep the fastest stable setting. Expected: measured optimum.
5. If workers crash at high counts, drop back and fix the memory hogs. Expected: stability over raw speed.

When to use

• Jest too slow or too crashy in CI.
• New CI runner size.

When not to use

• Local runs (use the default).
• --runInBand debugging (single worker by design).

Tool compatibility

• Jest 27 through 30; --maxWorkers.

Variant phrasings

Jest maxWorkers best value

Measured per runner; 50% is the starting guess.

Jest CI performance tuning

The broader task; workers are the biggest knob.

Why it happens

Too few workers waste CPUs; too many exhaust RAM and crash. The optimum depends on the runner and the suite's memory profile.

Edge cases

• --maxWorkers in CI config files is better than CLI flags for consistency.
• Memory-heavy suites want fewer workers than CPU count suggests.
• --workerIdleMemoryLimit complements worker tuning by recycling fat workers.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstOcBP0Ds4s6sP6eMZXkl_w