Migrating from Jest to Vitest: Resolving Mock Hoisting Differences

Direct Answer

Vitest does not provide a configuration knob to defer vi.mock hoisting to match Jest’s execution timing. Vitest statically hoists vi.mock calls to the top of the file to ensure dependencies are mocked before any code executes. To replicate Jest's specific import order, you must refactor the test to use vi.doMock combined with dynamic imports.

Shared in-memory fixtures cannot be accessed between Jest and Vitest during parallel execution because they run in isolated Node.js processes or workers. To maintain shared state, you must move fixtures to an external store, such as a database, Redis, or a file-based cache.

Understanding Hoisting and Import Order

In Jest, the transform-based approach sometimes allows for more flexibility in when mocks are evaluated. Vitest uses Vite's ESM-based transformation which prioritizes hoisting. If a migrated test imports a module that itself imports a mocked dependency, Vitest will ensure the mock is registered before that module is evaluated, regardless of where the vi.mock call appears in your source code.

Steps to Resolve Mocking Issues

<

• Identify order-dependent tests: Locate tests where the logic relies on a module being imported before a mock is defined.
• Switch to vi.doMock: For cases where hoisting breaks execution, replace vi.mock with vi.doMock.
• Use Dynamic Imports: When using vi.doMock, you must perform the import() inside the test function or a hook to ensure the mock is active before the module is loaded.

// Example of non-hoisted mock in Vitest
test('uses manual mock without hoisting', async () => {
  vi.doMock('./module', () => ({ data: vi.fn(() => 'mocked') }));
  const { data } = await import('./module');
  expect(data()).toBe('mocked');
});

Shared Fixtures Strategy

Since Jest and Vitest do not share memory, in-memory fixtures are effectively isolated. To avoid duplicating state or inconsistency:

1. Externalize state: Use a shared file or a lightweight key-value store for fixtures.
2. Global Setup/Teardown: Use global setup files in both runners to initialize and clean the external state before and after test suites.

Diagnostic Question: Does your application rely on specific side effects triggered during the module evaluation, or are the mocks simply providing return values?