jest ENOENT: no such file or directory for a snapshot file in CI: ca

Not specified by the original author.

TL;DR

Your local filesystem is case-insensitive, so import Button from './button' resolves even when the file is really Button.js. CI runners use case-sensitive filesystems, so the same import fails with ENOENT. Find the casing mismatch with git ls-files, fix it with git mv (or fix the import), and the CI error goes away. One rename, no code changes.

jest "ENOENT: no such file or directory" for a snapshot file in CI: case-sensitivity issue

Steps

1. Copy the exact path from the CI ENOENT message and run git ls-files | grep -i [the-filename] locally. Expected: you see the committed casing, which differs from what the import or the snapshot lookup asked for.
2. Check the import or the snapshot path in the spec for the wrong casing, for example an import of ./button when the file is Button.js, or a __snapshots__ directory cased differently from the spec file name. Expected: you find the single mismatched segment.
3. Rename with git so the casing change is tracked: git mv OldName.js newname.js (use a temp name in between on case-insensitive systems if git complains the names are identical). Expected: git status shows the rename.
4. Commit and push, then rerun CI. Expected: the ENOENT error is gone and the snapshot file resolves.

Use this when

• Jest reports ENOENT for a snapshot or module file only in CI
• The file exists locally and the suite passes on a Mac or Windows machine
• A recent rename touched the file or the directory casing

Not for this skill when

• The file is genuinely missing (never committed, gitignored)
• The error is a snapshot VALUE mismatch, not a missing file
• The failure is a permissions error or a broken symlink

Variant phrasings

• jest snapshot file not found in CI but exists locally
• ENOENT snapshot snapshots case sensitive filesystem
• jest passes on Mac fails on Linux file not found

Why it happens

macOS and Windows default to case-insensitive filesystems: ./button and ./Button hit the same file. Linux CI runners are case-sensitive, so the wrong casing is a genuinely different path and the lookup fails. Renames done through a GUI or an editor often change content but leave git holding the old casing, which is why the bug survives local runs.

Edge cases

• The mismatch can hide in the directory name (__Snapshots__ vs __snapshots__), not just the file. Check every segment.
• If two files differ only by case, the repo is broken on case-insensitive checkouts too. Rename one of them properly.
• After the rename, search the codebase for other imports using the old casing so the next CI run does not hit the same bug in a different spec.

Provenance

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

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

Thread query: jest "ENOENT: no such file or directory" for a snapshot file in CI: case-sensitivity issue

TL;DR: Your local filesystem is case-insensitive, so import Button from './button' resolves even when the file is really Button.js. CI runners use case-sensitive filesystems, so the same import fails with ENOENT. Find the casing mismatch with git ls-files, fix it with git mv (or fix the import), and the CI error goes away. One rename, no code changes.

Not specified by the original author.

TL;DR

Run jest locally with -u against the failing spec to remove the obsolete snapshot, check the .snap diff with git to confirm only the stale entry was dropped, commit the change, and rerun with --ci. The --ci flag turns obsolete snapshots into hard failures, so a suite that looks green on your machine can fail in the pipeline. Once you know which snapshot file is stale, the fix takes about five minutes.

jest "Snapshot summary: 1 snapshot obsolete" failing CI with --ci flag: how to clean up

Steps

1. Find which snapshot file is stale. Run the failing spec locally with the flag: npx jest path/to/spec --ci. Read the summary line that names the .snap file and the obsolete entry. Expected: you know exactly which snapshot file holds the stale entry.
2. Confirm the snapshot is truly obsolete. Open the .snap file and check that the test or component it captured no longer exists in the codebase. Expected: the entry maps to deleted code, not to a live test.
3. Clear it with an update run scoped to that spec: npx jest path/to/spec -u. Expected: the output reports the obsolete snapshot removed and the spec passes.
4. Review the diff on the .snap file before committing: git diff path/to/spec/__snapshots__/. Expected: only the obsolete entry was removed, no other snapshots changed.
5. Commit the updated .snap file and rerun the full suite with --ci. Expected: the summary shows 0 obsolete snapshots and CI passes.

Use this when

• CI runs jest with --ci and fails on obsolete snapshots
• The suite passes locally but the pipeline reports "1 snapshot obsolete"
• A test or component was deleted and its snapshot entry was never cleaned up

Not for this skill when

• The snapshot VALUE changed (a mismatch), not an obsolete entry
• A brand-new test fails because its snapshot was never written
• The failure is not snapshot-related at all (timeouts, imports, test logic)

Variant phrasings

• jest snapshot obsolete is failing the build in CI
• the --ci flag turns obsolete snapshots into failures
• clean up stale snapshots so jest --ci passes

Why it happens

Local runs tolerate obsolete snapshots silently and never flag them. The --ci flag exists to make CI strict: it refuses to write anything and fails the run on both new and obsolete snapshots. Deleting a test leaves its snapshot entry behind, invisible locally, until --ci flags it in the pipeline.

Edge cases

• If -u removed more than the one obsolete entry, the extra removals were also stale entries, but review each one before committing.
• Inline snapshots (toMatchInlineSnapshot) can go obsolete too; -u cleans those inside the spec file itself.
• If the snapshot is not actually obsolete (the test still exists), do not use -u. You have a value mismatch, which is a different problem.

Provenance

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

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

Thread query: jest "Snapshot summary: 1 snapshot obsolete" failing CI with --ci flag: how to clean up

TL;DR: Run jest locally with -u against the failing spec to remove the obsolete snapshot, check the .snap diff with git to confirm only the stale entry was dropped, commit the change, and rerun with --ci. The --ci flag turns obsolete snapshots into hard failures, so a suite that looks green on your machine can fail in the pipeline. Once you know which snapshot file is stale, the fix takes about five minutes.

Not specified by the original author.

TL;DR

Run Jest with --ci on CI, which makes new or changed snapshots fail instead of being written. Check the CI script itself; a config file alone does not enable it, and a stray -u flag overrides it.

The query

jest snapshot written on CI: how to fail instead of update

Use this when

• CI writes snapshots instead of failing
• snapshot changes slip through green builds
• new snapshots appear in CI artifacts

Not for

• updating snapshots locally
• obsolete-snapshot cleanup
• snapshot serializers

Steps

1. Open the CI script and confirm the test command includes --ci. Expected output: the jest command line contains the --ci flag.
2. Search the same command for -u or --updateSnapshot and remove it. Expected output: no snapshot-update flags in the CI command.
3. Commit the current snapshots so CI compares against a known baseline. Expected output: snapshot files committed and clean in git status.
4. Push a branch that changes snapshotted output and confirm CI fails on the snapshot mismatch. Expected output: a red CI run naming the changed snapshot.
5. Keep local runs without --ci so developers can still update snapshots intentionally with -u. Expected output: local -u updates snapshots while CI --ci fails on them.

Provenance

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

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

Thread query: jest snapshot written on CI: how to fail instead of update

TL;DR: Run Jest with --ci on CI, which makes new or changed snapshots fail instead of being written. Check the CI script itself; a config file alone does not enable it, and a stray -u flag overrides it.