Which strategy should I use for Prepare on Jest 30 Now or Defer Until Jest 31 Is Officially Released?

Frontend and Node teams need to decide whether to do Jest-related ESM and fake-timer cleanup on the current Jest 30 line now or defer that work until Jest 31 has an official release and migration guide.

Upgrade to Jest 30.3.x now if you can meet Node 18+/TS 5.4+; defer only when CommonJS mocks or timer-heavy suites make cleanup too expensive before Jest 31 is real.

Blockers

Who this is for

Candidates

Upgrade to Jest 30.3.x now and do the ESM and timer cleanup on the stable line

As of 2026-04-03, the latest official stable Jest release is 30.3.0, released on 2026-03-10, while the official "Next" docs are explicitly unreleased rather than a published Jest 31 migration target. Jest 30 already changed major compatibility baselines: Node 18+ is required, the minimum TypeScript version is 5.4, and `jest-environment-jsdom` moved to JSDOM v26. Jest 30 also expanded ESM support, including `import.meta.*`, `file://` paths, and native `.mts`/`.cts` handling, but the official ESM docs still label ESM support as experimental. Fake-timer behavior is still moving on the stable line: Jest 30 upgraded `@sinonjs/fake-timers` to v13, and Jest 30.3.0 updated that dependency again to v15.

When to choose

Use this when you are still on Jest 29.x or earlier, can meet the Jest 30 baseline of Node 18+ and TypeScript 5.4+, and want to reduce later upgrade risk before any official Jest 31 release. This is the stronger fit if your repo already uses native ESM or is actively moving toward it, or if you have timer-heavy tests that rely on precise scheduling and want to flush out fake-timer issues on the current stable line rather than during a future major.

Tradeoffs

You get current stable fixes and can remove legacy matcher and config debt sooner, but you still absorb Node, TypeScript, jsdom, ESM, and timer-related churn. This is not a low-effort bump for large suites that rely on CommonJS-style mocking or precise timer scheduling.

Cautions

Official Jest docs still require `--experimental-vm-modules` for native ESM, require transforms to emit ESM, and state that `jest.mock` hoisting does not work for ESM static imports. ESM mocking still relies on `jest.unstable_mockModule`, and timer-sensitive tests may change behavior as Jest updates `@sinonjs/fake-timers`.

Defer Jest 31 planning and pin to your current supported Jest line until official 31 release notes exist

As of 2026-04-03, Jest does not publish an official Jest 31 release or Jest 31 upgrade guide in the sources reviewed; the docs label "Next" as unreleased, and the current stable line is still 30.x. That means there is no verified official breaking-change list for Jest 31 yet. What is verified today is that ESM remains experimental in official docs, ESM mocking is still marked unstable, and fake timers are still changing underneath Jest 30 via `@sinonjs/fake-timers` upgrades.

When to choose

Use this when the suite is large, fake-timer-heavy, or still depends on CommonJS mocking patterns that are expensive to unwind. The decisive factor is lack of an official, stable Jest 31 migration contract as of 2026-04-03.

Tradeoffs

You avoid guessing at unreleased breakage, but you also postpone modernization work around native ESM and timer assumptions. If you are still below Jest 30, delay also means you keep carrying older matcher aliases, older environment baselines, or older resolver behavior until you schedule a real migration.

Cautions

Do not treat the unreleased "Next" docs as a final Jest 31 contract. Also note that 30.x already includes ESM-related changes and continued fake-timer dependency updates, so pinning only buys time if you intentionally freeze your Jest version.

Facts updated: 2026-04-03
Published: 2026-04-03

Try with your AI agent

$ npm install -g pocketlantern
$ pocketlantern init
# Restart Claude Code, Cursor, or your MCP client, then ask:
# "Which strategy should I use for Prepare on Jest 30 Now or Defer Until Jest 31 Is Officially Released?"
Missing something? Request coverage