Jest 27.4.0 Watch Mode Worker Reuse vs Teardown After Haste Map Leak Fix

Worker lifecycle behavior in watch mode after the Haste map memory leak fix

Jest 27.4.0 resolved the unbounded memory growth caused by the Haste map cache retaining references to deleted files during watch mode runs with --maxWorkers > 1. The fix improves cache invalidation in @jest/haste-map and applies automatically when upgrading from 27.3.x.

However, Jest still reuses worker processes across test runs in watch mode rather than tearing them down and recreating them. This design leaves file handles, timers, or event listeners from test code or third-party libraries potentially accumulated across runs. The --detectOpenHandles flag may surface these as apparent leaks, though some originate outside Jest's control.

The goal is to understand whether the current worker reuse strategy is intentional for performance, and whether a configuration option or future version might introduce explicit worker teardown between watch-mode test runs to guarantee handle release.

Is worker reuse in watch mode a deliberate performance trade-off that will remain the default? Could a --forceWorkerTeardown flag or similar be added to opt into clean process isolation per run? Does the Jest team consider the current handle retention an acceptable limitation or a target for future improvement?