Mocking breaks when isolate: false, singleThread: true, v1.1.2

[AriPerkkio]

Note: This issue is specifically about isolate: false, singleThread: true configuration.

Describe the bug

Likely regression from #4664, cc. @Dunqing

If two files are loading same file and the second one mocks that file, Vitest will throw Error: [vitest] Cannot mock "../src/basic.js" because it is already loaded. Did you import it in a setup file? error. Reproduction below has no setup files - just two test files importing same source file while second one mocks that file.

Reproduction

https://stackblitz.com/edit/vitest-dev-vitest-scpuyh?file=test%2Fsecond.test.ts,test%2Ffirst.test.ts

System Info

Stackblitz

Used Package Manager

pnpm

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[AriPerkkio]

Coverage tests are failing randomly, depending which file Vitest's cache decides to run first:

vitest/test/coverage-test/test/no-esbuild-transform.test.js

Lines 1 to 10 in a73c1c2

	import { expect, test, vi } from 'vitest'
	import { add } from '../src/utils'
	vi.mock('../src/utils', async () => ({
	add: vi.fn().mockReturnValue('mocked'),
	}))
	test('mocking in Javascript test should not break sourcemaps', () => {
	expect(add(1, 2)).toBe('mocked')
	})

[sheremet-va]

Not sure if it is a bug. If the file structure was a little bit different (file was imported inside another file), there would've been a situation when mocking wouldn't have worked in Vitest 1.0 (before the error that catches such bugs/features was introduced):

https://stackblitz.com/edit/vitest-dev-vitest-gxiruo?file=src%2Fbasic2.ts,package.json,test%2Ffirst.test.ts,test%2Fsecond.test.ts

The error was introduced in #4862

[roman-gula]

Same issue, is reproduced also for 1.1.3

[AriPerkkio]

Right, if this is expected behaviour then maybe the error message should be different when it's caused by disabled isolation. Seeing error message that mentions setupFiles is a bit misleading in cases like the minimal repro.

[sheremet-va]

Right, if this is expected behaviour then maybe the error message should be different when it's caused by disabled isolation. Seeing error message that mentions setupFiles is a bit misleading in cases like the minimal repro.

It is not possible to know why the error happens.

[AriPerkkio]

The possible causes could still be narrowed down based on configurations. If there are no setupFiles, do not mention that. If isolation is disabled, maybe add that one there.

[sheremet-va]

This should be fixed by #4905

This error is now thrown only for isolated environments.

[Tohid001]

@sheremet-va hey mate, I have written hundreds of test cases mocking react's particular api's that's needed mocking. And now all those tests are getting failed with this error thrown:
Please, remove the import if you want static imports to be mocked, or clear module cache by calling "vi.resetModules()" before mocking if you are going to import the file again. See: https://vitest.dev/guide/common-errors.html#cannot-mock-mocked-file-js-because-it-is-already-loaded

I have tried the resetmodules solution but it did not work for me

[divmgl]

We're having the same problem. In the v0 version of Vitest things work as expected (we're on v0.34.6). The latest version of Vitest fails with this same error.

[sheremet-va]

Please, provide reproductions when filing an issue. Any comment that basically means "+1" will be ignored.

[i-void]

I have the same issue. Reproducing is easy. In my case creating a test file with a mock for top level imported module and disable isolation (singleFork or isolation: false) is enough to see the error. For just maxFork: 1 minFork. 1 it works but this time tests are 10x slower.

[divmgl]

Please, provide reproductions when filing an issue. Any comment that basically means "+1" will be ignored.

I went into StackBlitz and attempted to recreate the issue to no avail. I spent some time in our codebase commenting out code until I narrowed down where it was happening. We have a complex web of dependencies and I noticed one function that was exported in a module that had a ton of different imports. I moved that function into a different module and the issue stopped happening.

If I had to guess, this issue occurs when there's a circular dependency between two modules that indirectly import the mocked module. Hopefully this helps as I won't be able to spend any more time on this. cc @sheremet-va