What this usually means
macOS and Windows use case-insensitive filesystems by default. A file named `Header.tsx` can be imported as `./header` or `./Header` or `./HEADER` — the OS finds it regardless. Linux filesystems are case-sensitive. `./header` and `./Header` are two different files. If your import statement does not match the actual filename's casing exactly, Linux will not find the file.
The first ten minutes \u2014 establish facts before touching code.
- 1Check the exact casing of the file on disk: `ls -la` or use your file explorer. Compare character by character against the import statement.
- 2Check if the error happens on a different file system. If you develop on macOS and deploy to a Linux container, case sensitivity is the first suspect.
- 3Search your codebase for imports of the failing module. Check every import path's casing against the actual filename.
- 4Run a case-sensitivity check: `find . -type f | sort` and compare against all import paths in your code.
- 5Enable case-sensitive filesystem checks in your editor or ESLint plugin to catch mismatches early.
The specific files, logs, configs, and dashboards that usually own this bug.
- searchThe failing import statement — compare its path to the actual filename on disk
- searchCI build logs — the exact error line with the module path
- searchAll other imports of the same file — one might have correct casing, another might not
- searchGit history — did someone rename the file but only change some imports?
- searchDockerfile or deployment config — the OS of the build/run environment
Practical causes, not theory. These are the things you will actually find.
- warningDeveloper created or renamed a file with different casing than the import statement
- warningGit does not track case-only renames on case-insensitive filesystems by default
- warningAuto-import in the editor inserted a path with wrong casing
- warningA library or component was moved between case-sensitive and case-insensitive environments
- warningBuild tool or bundler resolves paths differently in production mode
Concrete fix directions. Pick the one that matches your root cause.
- buildFix the import statement to match the exact filename casing on disk
- buildRename the file to match the import convention (all lowercase, kebab-case, or PascalCase — pick one and enforce it)
- buildConfigure ESLint with `import/no-unresolved` or a case-sensitivity plugin
- buildRun CI on a Linux runner to catch case mismatches before they reach production
- buildSet `core.ignorecase=false` in Git config so Git tracks case changes
A fix you cannot prove is a guess. Close the loop.
- verifiedFix the import casing, push to CI (Linux runner), and confirm the build passes.
- verifiedSearch the codebase for any remaining case-mismatched imports and fix them.
- verifiedAdd a lint rule that checks import paths exist with exact casing.
- verifiedTest the build on a case-sensitive filesystem (Linux CI, or macOS with a case-sensitive volume).
- verifiedVerify that renaming a file and updating all imports works end-to-end without case issues.
Things that make this bug worse or harder to find.
- warningFixing only one import and leaving other case mismatches in the codebase
- warningRenaming the file instead of fixing the import — both work but pick one convention
- warningUsing inconsistent file naming conventions across the project
- warningAssuming the problem is a missing dependency when the error says 'module not found'
- warningNot enabling case-sensitive CI checks because 'it works on my machine'