Jest watch mode mock restoration configuration to prevent memory leaks

Answer

Jest does not automatically turn on restoreMocks when running in watch mode; you must enable it yourself if you want mock‑related state to be cleared between test runs.

Confirmed facts

• restoreMockstrue causes Jest to deep‑clone each mocked module before every test, guaranteeing a clean implementation but adding CPU and memory work proportional to the mock size.
• In watch mode the Node process stays alive between runs, so any mock state or module cache that isn’t cleared can accumulate, leading to observable memory growth over successive runs.

Likely explanation

Enabling restoreMocks in watch mode would stop mock‑related leaks because each test starts with a fresh clone, but the cloning cost is paid on every test pass. For small‑to‑medium mocks the overhead is usually modest; for large or numerous mocks it can become noticeable and slow down the feedback loop.

Steps to enable mock restoration in watch mode

1. Add restoreMocks: true to your Jest configuration (e.g., jest.config.js).
2. If you want the flag only for watch runs, create a watch‑specific config file (e.g., jest.watch.config.js) that sets restoreMocks: true and start Jest with jest --config jest.watch.config.js --watch.
3. Optionally, make the setting conditional on an environment variable that Jest sets in watch mode (process.env.JEST_WATCH_MODE is not built‑in, so you can rely on a separate config file as shown above).

Verification

1. Run the suite in watch mode with the default (restoreMocks:false) and monitor memory over several cycles (e.g., node --inspect or --detectOpenHandles). Note the baseline growth.
2. Repeat the run with restoreMocks:true (or the watch‑specific config) and compare memory growth and test execution time.
3. If the clone cost is a concern, profile it with jest --verbose or wrap jest.resetModules() in a timer to see the per‑run overhead.

Missing diagnostic detail

To decide whether the performance impact is acceptable, we need to know the approximate size or complexity of the modules you are mocking (e.g., number of lines, dependencies) and how frequently your test suite runs in watch mode. With that information you can judge if the clone overhead is negligible for your workflow.