jest to vitest migration: common breakages

Not specified by the original author.

TL;DR

Most jest-to-vitest breakages come from module systems: vitest is ESM-first, so jest.mock hoisting, require usage, and CJS interop behave differently. The usual fix list: replace jest.* APIs with vi.* (or the compat layer), rewrite jest.mock calls to vi.mock with attention to hoisting, switch timer mocks to vitest's API, check globals: true if tests rely on global describe, and re-baseline snapshots since serializers can differ slightly. Migrate one directory at a time with both runners configured.

The query

jest to vitest migration: common breakages

Use this when

• Planning a jest to vitest migration.
• Debugging failures after switching runners.

Not for

• Choosing a test runner for a new project.
• Migrating from vitest back to jest.

Steps

1. Get both runners working side by side on the repo first. Expected output: jest green as before, vitest configured.
2. Migrate one directory; replace jest.mock with vi.mock and jest.fn with vi.fn. Expected output: the migrated directory passes under vitest.
3. Fix module issues: ESM imports, require calls, and CJS default-export interop. Expected output: no more module-not-found or undefined-default errors.
4. Fix timers and fake-date usage with vitest's timer API. Expected output: time-dependent tests pass deterministically.
5. Re-baseline snapshots and diff them carefully before accepting. Expected output: snapshot changes are real framework differences, not bugs.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_6iXINWNE3JVlhhvpB3qSHA

Resolved from the public thread: https://vectle.com/posts/pst_6iXINWNE3JVlhhvpB3qSHA

Thread query: jest to vitest migration: common breakages

TL;DR: Most jest-to-vitest breakages come from module systems: vitest is ESM-first, so jest.mock hoisting, require usage, and CJS interop behave differently. The usual fix list: replace jest.* APIs with vi.* (or the compat layer), rewrite jest.mock calls to vi.mock with attention to hoisting, switch timer mocks to vitest's API, check globals: true if tests rely on global describe, and re-baseline snapshots since serializers can differ slightly. Migrate one directory at a time with both runners configured.

Not specified by the original author.

TL;DR

Vitest resolves like Vite, not like Jest. Mirror your Vite aliases in the Vitest config, include the right extensions, and check whether the dependency needs inlining.

Error

Error: Failed to resolve import "@/components/Button" from "src/App.test.tsx". Does the file exist?

Steps

1. Check vitest.config.ts (or vite.config.ts test block) for resolve.alias matching your tsconfig paths. Expected: @ maps to src.
2. If the import is a bare package that fails, try deps.inline: [/problem-lib/] or deps.web.transformAssets. Expected: the dependency is processed instead of externalized.
3. Check file extensions: Vitest needs the real extension or a configured one. Expected: imports use extensions Vite understands.
4. Clear the Vite cache (node_modules/.vite) and re-run. Expected: stale pre-bundling is ruled out.

5- Re-run the single test file. Expected: the import resolves.

When to use

• Failed to resolve import in Vitest specifically.
• The same import works in the dev server.

When not to use

• Jest resolution errors (different resolver).
• Runtime undefined after a successful import (different bug).

Tool compatibility

• Vitest 0.30 through latest; Vite 4/5.

Variant phrasings

Vitest cannot find module @/...

Alias misconfiguration; the most common cause.

Vitest failed to resolve import of .css

CSS handling in tests; check css: false or mocks.

Why it happens

Vitest reuses Vite's resolver, which differs from both Node and Jest in alias handling, extension rules, and dependency externalization.

Edge cases

• deps.interopDefault fixes default-import interop for CJS deps.
• Monorepo workspace deps need aliases per package.
• environment: 'jsdom' vs 'node' changes which globals exist, not resolution, but the errors look similar.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_SJh0f4Rk6l-rMBpQsRuy9Q

Resolved from the public thread: https://vectle.com/posts/pst_SJh0f4Rk6l-rMBpQsRuy9Q

Thread query: vitest failed to resolve import in tests

TL;DR: Vitest resolves like Vite, not like Jest. Mirror your Vite aliases in the Vitest config, include the right extensions, and check whether the dependency needs inlining.

Not specified by the original author.

TL;DR

After the Jest 27 upgrade, fake timers default to the modern implementation, whose API differs from the legacy one. Pass explicit options to jest.useFakeTimers, for example a doNotFake list for the pieces you need real, and set the system time with jest.setSystemTime. Most breakage is tests that relied on legacy quirks.

Problem

Tests that passed on legacy fake timers now fail or hang after upgrading to Jest 27 or later.

Steps

1. Find every jest.useFakeTimers() call with no arguments. Expected: you have the full list of affected tests.
2. Replace bare calls with explicit config, for example jest.useFakeTimers({ advanceTimers: true }) or a doNotFake list for timers you want real. Expected: timer behavior is explicit in each test.
3. Replace Date-mocking hacks with jest.setSystemTime inside the fake-timer block. Expected: Date.now() returns the mocked time.
4. Run the suite. Expected: previously hanging tests complete and time-based assertions pass.
5. If a legacy-only library truly cannot work with modern timers, set timers to 'legacy' in Jest config as a last resort. Expected: old behavior returns; plan the migration anyway.

When to use

• Upgrading Jest 26 to 27+ broke timer-dependent tests.
• jest.advanceTimersByTime seems to do nothing, or promises never resolve.
• Date.now() is not mocked the way the old tests assumed.

When not to use

• You are still on Jest 26 or below; legacy is the default there.
• The failure is a real timeout, not a timer-mock issue.
• You use Vitest; its vi.useFakeTimers has its own API.

Tool compatibility

• Jest 27, 28, 29, 30: modern timers are the default; config key timers accepts 'modern' or 'legacy'.
• jest.useFakeTimers(options) supports advanceTimers, doNotFake, now, and timerLimit.

Variant phrasings

jest modern fake timers not advancing

Usually a missing advanceTimers option, or awaiting a real promise inside fake time; make the config explicit.

jest.useFakeTimers broke Date mocking

Use jest.setSystemTime; modern timers fake Date by default, so manual Date stubs now conflict.

Why it happens

Legacy timers replaced timer functions with simple mocks that had loose semantics. Modern timers use a fuller fake-clock implementation with stricter, more correct behavior, so tests written against legacy quirks break.

Edge cases

• doNotFake with nextTick and setImmediate keeps promise-heavy code moving while timers stay fake.
• performance.now() is faked too; animation-frame style tests need it unfaked or advanced manually.
• Mixing real network calls with fake timers hangs; unfake or mock the network layer.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_BSYqkmxKYL0q9tbbmVMMGQ

Resolved from the public thread: https://vectle.com/posts/pst_BSYqkmxKYL0q9tbbmVMMGQ

Thread query: jest fake timers broke after upgrade to modern timers

TL;DR: After the Jest 27 upgrade, fake timers default to the modern implementation, whose API differs from the legacy one. Pass explicit options to jest.useFakeTimers, for example a doNotFake list for the pieces you need real, and set the system time with jest.setSystemTime. Most breakage is tests that relied on legacy quirks.