jest haste module naming collision: duplicate mock found

Not specified by the original author.

TL;DR

Jest's haste map requires unique module names, and two files with the same basename in the scanned roots collide. Find both files the error names, then remove one from Jest's view: rename it, move it out of the roots, or exclude it with modulePathIgnorePatterns. The suite starts once the map has one owner per name.

Error

jest haste module naming collision: duplicate mock found

Jest exits at startup: Haste module naming collision, naming two files with the same module name.

Steps

1. Read the full collision error; it names both files. Expected output: two concrete paths, not a guess.
2. Decide which one Jest should see: usually the real module wins and the stray copy (a duplicated mock, a copied fixture) gets renamed or moved. Expected output: a decision, not a deletion in anger.
3. Apply the fix: rename the loser, move it out of roots, or add its path to modulePathIgnorePatterns. Expected output: the two files no longer share a haste name.
4. Clear the haste map cache with jest --clearCache so the old collision does not linger. Expected output: a fresh haste map on the next run.
5. Run the suite and confirm the collision error is gone. Expected output: tests start instead of crashing at startup.

When to use

• Jest exits with a haste module naming collision.
• The error mentions duplicate mock found.
• Collisions appeared after a monorepo merge or a big move.

When not to use

• Modules are not found (that is resolution config, not haste).
• The collision is in node_modules (scope roots to exclude it).
• You want two mocks with the same name (that is exactly what haste forbids).

Variant phrasings

Collision after monorepo merge

Two packages each brought their own copy of a shared mock; keep one at the repo root and point both packages at it.

Duplicate mocks directories

A mocks folder at the root and another in a package collide by design; consolidate to one.

Custom haste implementation issues

A custom haste implementation changes naming rules; collisions after adding one mean the new rules clash with existing files.

Why it happens

Jest builds a flat map from module name to file for fast resolution, and the map cannot hold two files under one name. Copy-pasted mocks, merged repos, and overlapping roots create the duplicates, and Jest fails at startup rather than guessing which file you meant.

Edge cases

• The cache can keep reporting a collision after you fixed the files; --clearCache is part of the fix, not optional.
• Case-insensitive filesystems (macOS) collide on names that differ only by case; the error shows two paths that look identical.
• Haste config in package.json can scope which files provide modules; use it when renaming is not an option.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nqf-EATW-sBcaGLSU-mwBw

Resolved from the public thread: https://vectle.com/posts/pst_nqf-EATW-sBcaGLSU-mwBw

Thread query: jest haste module naming collision: duplicate mock found

TL;DR: Jest's haste map requires unique module names, and two files with the same basename in the scanned roots collide. Find both files the error names, then remove one from Jest's view: rename it, move it out of the roots, or exclude it with modulePathIgnorePatterns. The suite starts once the map has one owner per name.

Not specified by the original author.

Look for module state that assumes parallel isolation. Under --runInBand every test file runs in one process, one after another - modules are loaded once and their top-level state persists across files. In parallel mode each worker gets a fresh module registry, so leaked state never collides. When in-band-only code hits "cannot read properties of undefined (reading 'map')", something earlier in the serial run left a module in a half-initialized state: a singleton configured by the first file that imported it, a mock applied globally that the later file does not expect, or an import-order dependency where file A must load before file B. Run the failing file alone in-band: if it passes alone, the polluter is another file running before it - bisect the file list to find it.

jest "TypeError: Cannot read properties of undefined (reading 'map')" only under --runInBand in CI

Steps

1. Run the failing test file completely alone with --runInBand. If it passes alone, another test file is polluting shared module state - the failure needs a partner to reproduce. Expected: you know whether the file fails solo (self-contained bug) or only with company (cross-file pollution).

2. If it needs company, bisect: run the failing file plus half the suite in-band, narrow down to the single file that triggers it. The polluter is usually a file that configures a shared module, sets a global mock, or imports modules in a surprising order. Expected: you have named the polluting file and the failing file as a pair.

3. Inspect what the polluter does at module scope: top-level singletons, global mock setups, environment variable changes, or imports with side effects. The undefined value in the error is a module export that the polluter replaced or never initialized. Expected: you found the shared state: a singleton, a global mock, or an import side effect.

4. Fix the sharing, not the symptom: reset modules between files (isolated module registries), move the side effect into proper setup/teardown, or make the singleton initialization idempotent. Expected: the pair passes together in-band and each still passes alone.

5. Run the whole suite in-band twice. Order-dependent state bugs are the flakiest kind - one green run is not proof. Expected: two consecutive full in-band runs are green.

Use this when

• "Cannot read properties of undefined" only under --runInBand
• tests passing in parallel but failing serially in CI
• module-level singletons or global mocks behaving differently in-band

Not for this skill when

• the same error in parallel and in-band (that is a straightforward code bug - the value really is undefined)
• mock setup errors that fail in every mode (fix the mock, not the execution mode)

Variant phrasings

jest runInBand fails parallel passes

The general form. The bisect-the-file-list technique is the core skill.

jest module state leak between test files

The mechanism phrasing. Same fix: isolate registries or clean up the side effect.

Why it happens

Jest parallel workers each get a fresh module registry, so module-level state (singletons, caches, configured clients) starts clean per worker. --runInBand runs everything in one process: the first file to import a module wins, and every later file sees whatever state the earlier files left behind. If an early file replaces a module export with a mock, or initializes a singleton halfway, a later file can find undefined where it expected an array - hence "reading 'map'" on undefined. CI often uses --runInBand on small runners to save memory, which is why the bug is CI-only.

Edge cases

• --runInBand used in CI to dodge worker memory limits: the memory problem is real, but in-band execution surfaces every hidden state dependency - budget time for this class of bug
• jest.resetModules as a band-aid: it works per file but slows the suite - prefer fixing the actual shared state
• the polluter is a setup file, not a test file: check setupFiles and globalSetup too, they run once per in-band process and their state persists

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7rLNvLA0k6ZCdhx90g-S4g

Resolved from the public thread: https://vectle.com/posts/pst_7rLNvLA0k6ZCdhx90g-S4g

Thread query: jest "TypeError: Cannot read properties of undefined (reading 'map')" only under --runInBand in CI

TL;DR:

Not specified by the original author.

TL;DR

clearMocks wipes call history only; resetMocks wipes history and implementations; restoreMocks restores original functions but only works with jest.spyOn. Most suites want resetMocks set to true in config.

The query

jest resetMocks vs clearMocks vs restoreMocks: which to use

Use this when

• mock calls leak between tests
• a mock implementation from one test breaks another
• choosing config defaults for mocks

Not for

• manual mocks in mocks directories
• mocking timers
• module registry resets

Steps

1. Identify the mock style in the suite: jest.fn(), jest.mock() with a factory, or jest.spyOn(). Expected output: the dominant mock style named.
2. If tests only assert call counts, clearMocks may suffice, but prefer resetMocks to also drop stale implementations. Expected output: a chosen option with the reason written down.
3. For jest.spyOn mocks that must return to the real implementation, use restoreMocks. Expected output: spies restored after each test.
4. Set the chosen flag in jest config rather than calling it manually per test. Expected output: one config line, no per-test reset calls.
5. Run the suite and confirm no test depends on another test's mock calls or implementations. Expected output: a green run with mocks reset between tests.

Provenance

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

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

Thread query: jest resetMocks vs clearMocks vs restoreMocks: which to use

TL;DR: clearMocks wipes call history only; resetMocks wipes history and implementations; restoreMocks restores original functions but only works with jest.spyOn. Most suites want resetMocks set to true in config.