vi.fn "memory leak" with `isolate: false`

[andrewbrennanfr]

Clear and concise description of the problem

In our project, we have a need to use isolate: false and fileParallelism: false in vitest.

We have seen that under this configuration, the number of vitest mocks being kept in memory grows as your test suite runs. This is not surprising given the shared context.

What is surprising, is there is no clear mechanism to control this.

The result is that calling functions like clearAllMocks or restoreAllMocks get progressively slower over time (as we simply loop over all active mocks) - without ever having a way to reduce the size of the set.

Here is a reproduction 👉 https://stackblitz.com/edit/vitest-dev-vitest-y6nkb7na?file=vite.config.ts,test%2Ftest01.test.ts,vitest.setup.ts,test%2Ftest05.test.ts,test%2Ftest04.test.ts&initialPath=__vitest__/

I have 5 test files, that each create a large number of mocks and you can see the performance of clearAllMocks degrades over time - relative to the number of mocks being created.
This is an extreme case (with 1000's of mocks created) - but in our real-world case, we aren't mocking many functions - but having a lot of tests (5000+ tests) & even mocking a reasonable number of functions per test, get's out of control quickly.

Using isolate: true, does solve this problem - because the context is reset between tests. But this introduces other problems we then have to overcome.

Suggested solution

I find it surprising there is no way to "clean/kill mocks" that are in memory.
We have the power to clean up other parts of shared context unstubAllGlobals or unstubAllEnvs are maybe good examples?
I'd kind of expect some killAllMocks function.

Alternative

I guess there is an argument that we should mock less things. Or not run with isolate: false.
But if we imagine for a second, that there is a use case for mocking a large number of functions in a shared context (we have one in our project) - there is not equal alternative.

Alternatively I guess we could also say that resetAllMocks or restoreAllMocks should be keeping this list under control itself. I don't see any reason that we would want to just let this set grow forever as my tests run.

Additional context

I'd be open to a suggestion on how to solve this problem with existing methods - without resorting to:

• Changing isolate:false or fileParallelism: false
• Mocking less things

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[MikeDabrowski]

We're seeing what looks like the same underlying pattern, though triggered by test fixtures rather than vi.fn mocks specifically — worth noting in case it points to a broader "nothing gets released under isolate: false" issue rather than something mock-registry-specific.

Our setup: Angular + Vitest, ~8500 tests across ~970 files, pool: 'threads'/'vmThreads', isolate: false, restoreMocks: true, mockReset: true (for the same reason — perf, at this test count isolate: true is too slow to be usable in CI).

Running with logHeapUsage: true, process.memoryUsage().heapUsed climbs steadily for the whole run rather than staying flat between files:

sample 0:    94 MB
sample 500:  238 MB
sample 1000: 497 MB
sample 1500: 879 MB
sample 2000: 1144 MB
sample 2500: 1250 MB
sample 3000: 1453 MB
sample 3500: 1691 MB

Of ~3580 consecutive test-to-test deltas, 2259 were increases vs. 783 decreases — so growth dominates, but it's not that GC never runs: the 10 largest single-step drops (600–1200 MB each) all cluster very late in the run, once heap pressure is already high, suggesting GC is deferred rather than truly blocked. That's consistent with some memory (real garbage) eventually getting reclaimed while another category (retained by Vitest itself, e.g. the mock registry this issue describes, but possibly also fixtures/DI graphs) never does.

Switching to isolate: true does stop the growth for us too, but became impractical at this scale — a partial run at ~1/5 the speed of isolate: false before we gave up.

Given clearAllMocks/restoreAllMocks/resetAllMocks are already the documented way to reset state between tests, it'd be a meaningful win if they (or a new explicit API, as suggested above) could also drop the retained references so long suites don't have to choose between speed (isolate: false) and bounded memory.