jest Cannot find module in CI but passes locally - case-sensitive import how to find

TL;DR

Jest says it cannot find a module in CI, but the same test passes on every developer machine. The import path's letter casing does not match the file on disk: macOS and Windows filesystems ignore case, so the wrong casing resolves locally, while Linux CI resolves paths literally and fails. Diff the import specifier against the real filename with git ls-files, fix the casing in the import statement, then add a CI check so a case-only rename can never slip through again.

The query

jest Cannot find module in CI but passes locally  -  case-sensitive import how to find

Use this when

• jest reports Cannot find module only in CI, never locally
• someone recently renamed a file or moved it between directories
• the team develops on macOS or Windows and CI runs Linux
• the error names a relative import, not a node_modules package

Not for

• the module is missing everywhere, including locally (it was never installed or the file does not exist)
• a path alias like @/ is misconfigured (that is a moduleNameMapper problem, not casing)
• the error is a TypeScript type error with no jest failure

Steps

1. Copy the exact module specifier from the CI log

Open the failing CI log and copy the module string jest tried to resolve, exactly as printed, including the relative path and any alias prefix.

Cannot find module './components/Header' from 'src/pages/Dashboard.test.js'

Expected output: you have the literal specifier jest failed on, not a paraphrase of it.

2. Compare the specifier against the real filename on disk

List the tracked files with git and compare letter by letter. The mismatch is usually one capital letter, often from a file that was renamed without git noticing the case change.

git ls-files | grep -i "components/header"
# shows: src/components/header.tsx   (lowercase h)
# test imports: './components/Header' (uppercase H)

Expected output: the casing difference between the import and the tracked file is visible.

3. Reproduce it on a case-sensitive filesystem

The bug is invisible on macOS and Windows. Reproduce it in a Linux container before fixing, so you know the fix is real and not another local illusion.

docker run --rm -v "$PWD":/app -w /app node:20 npx jest src/pages/Dashboard.test.js

Expected output: the same Cannot find module error appears inside the container.

4. Fix the casing in the import statement

Change the import to match the tracked filename exactly. Do not rename the file to match the import unless the whole team agrees, because every other importer may use the other casing.

// before
import Header from './components/Header';
// after
import Header from './components/header';

Expected output: jest resolves the module and the test runs in the container.

5. Add a guard so it cannot regress

For TypeScript, enable forceConsistentCasingInFile in tsconfig. For plain JS, add a CI step that fails when any import's casing differs from the tracked file, for example a small script over git ls-files.

{
  "compilerOptions": { "forceConsistentCasingInFile": true }
}

Expected output: a future case-only mismatch fails fast in CI instead of shipping.

Tool compatibility

• jest 26 - 30
• Node 16 - 22
• Linux CI runners (GitHub Actions, CircleCI, Jenkins, GitLab CI)

Variant phrasings

• Cannot find module './Components/Header' from 'src/...' (CI only)
• TS2307: Cannot find module './utils/foo' after a rename
• jest Cannot find module '@/components/Bar' on GitHub Actions but not on Mac

Why it happens

Local filesystems on macOS (APFS default) and Windows (NTFS) are case-insensitive but case-preserving: they happily open header.tsx when you ask for Header.tsx. Linux ext4 is case-sensitive and treats them as different files. Git with core.ignorecase=true will not even record a case-only rename, so the repo looks fine while the import is wrong.

Edge cases / pitfalls

• git may silently ignore case-only renames: use git mv -f old new or set core.ignorecase=false to make them explicit
• barrel files (index.ts re-exports) hide the real filename, so check the re-export chain too
• in monorepos, the same file can be imported through two different aliases with different casing; fix all of them
• some editors auto-import with the wrong casing on save; the guard in step 5 is what actually ends the cycle

Provenance

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