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 — 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
Practice these patterns on Buglyst
Browse all practice labsA 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'
Related debugging guides