Jest fails with Cannot find module 'fastly:secret-store' for Fastly Compute@Edge app

Not specified by the original author.

TL;DR

Jest cannot resolve the fastly: namespace imports because those modules only exist inside the Compute@Edge runtime.

Steps

1. Importing fastly:secret-store (or other fastly: namespaced modules) fails under Jest with Cannot find module 'fastly:secret-store' even though the app builds and deploys fine. Jest cannot resolve the fastly: namespace imports because those modules only exist inside the Compute@Edge runtime. Maintainers from Fastly recommend using the community jest preset ysugimoto/jest-preset-fastly-js-compute, which maps the fastly: imports to local mocks; the maintainer explicitly called it the exact integration they recommend for Fastly JS apps under Jest. The reporter confirmed that PR 9 on that preset resolved their issue and the thread was closed.
2. What actually fixes it (verified in the thread):
3. Use the jest preset ysugimoto/jest-preset-fastly-js-compute in your jest config: it maps fastly: namespaced imports to local mocks so tests can run outside the Compute@Edge runtime. This is the integration Fastly's own maintainer recommends for Jest users, and the reporter confirmed that a preset update (PR 9) fixed their failing tests. Source: https://github.com/fastly/js-compute-runtime/issues/597

When to use

You are seeing this: The situation: Importing fastly:secret-store (or other fastly: namespaced modules) fails under Jest with Cannot find module 'fastly:secret-store' even though the app builds and deploys fine. Use this skill when you run into "Jest fails with Cannot find module 'fastly:secret-store' for Fastly Compute@Edge app".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Sources

• https://github.com/fastly/js-compute-runtime/issues/597

Someone asked: Importing fastly:secret-store (or other fastly: namespaced modules) fails under Jest with Cannot find module 'fastly:secret-store' even though the app builds and deploys fine. Jest cannot resolve the fastly: namespace imports because those modules only exist inside the Compute@Edge runtime. Maintainers from Fastly recommend using the community jest preset ysugimoto/jest-preset-fastly-js-compute, which maps the fastly: imports to local mocks; the maintainer explicitly called it the exact integration they recommend for Fastly JS apps under Jest. The reporter confirmed that PR 9 on that preset resolved their issue and the thread was closed. The verified answer: Use the jest preset ysugimoto/jest-preset-fastly-js-compute in your jest config: it maps fastly: namespaced imports to local mocks so tests can run outside the Compute@Edge runtime. This is the integration Fastly's own maintainer recommends for Jest users, and the reporter confirmed that a preset update (PR 9) fixed their failing tests. Source: https://github.com/fastly/js-compute-runtime/issues/597 Full thread: https://vectle.com/threads/thr_rIMGAbw33e3H90R76knL1A

Not specified by the original author.

TL;DR

Put the most specific mapper entries first, write each key as a full regex, and point values at [rootDir]-anchored paths. Jest never reads tsconfig paths or bundler alias settings, so every alias needs its own mapper entry. Double-check you edited the config file Jest actually loads.

Problem

Tests fail with Cannot find module for an aliased import like @app/utils, even though the app builds fine.

Steps

1. Open the Jest config Jest actually uses and confirm the moduleNameMapper block is in it, not in a stale or unused config file. Expected: npx jest --showConfig prints your mapper entries.
2. Write each key as a regex with start and end anchors, for example "^@app/(.*)$". Expected: the key matches the full import specifier.
3. Map the value to a [rootDir]-anchored path with a $1 capture, for example "[rootDir]/src/$1". Expected: the resolved path points at a real file.
4. Order entries from most specific to most generic, with catch-all patterns last. Expected: npx jest --showConfig lists specific patterns above generic ones.
5. Run one failing test file. Expected: Cannot find module is gone for the aliased import.

When to use

• Jest 29 or 30 reports Cannot find module for imports using @, ~, or other aliases.
• Aliases work in the bundler or tsc but not under Jest.
• You added a new alias prefix and new tests fail while old ones pass.

When not to use

• The error comes from webpack, Vite, or tsc itself; fix the alias at the source instead.
• Relative imports fail too; that is a roots or testMatch problem, not a mapper problem.
• You use Vitest; it reads vite resolve.alias, so configure the alias there.

Tool compatibility

• Jest 29.x: moduleNameMapper keys are regex strings, values support $N captures.
• Jest 30.x: same behavior; --showConfig is still the fastest way to verify.
• Works with babel-jest and ts-jest; ts-jest does not read tsconfig paths automatically either.

Variant phrasings

jest cannot find module for @ alias

Same fix. The @ prefix is just a naming habit; the mapper entry is "^@/(.*)$" pointed at your source dir.

moduleNameMapper ignored

Almost always the wrong config file, or a second config (package.json vs jest.config.js) shadowing the first. --showConfig tells you which file won.

Why it happens

Jest resolves modules with its own resolver and never looks at tsconfig.json paths or bundler alias settings. A mapper key that is not anchored, or a generic pattern listed first, silently matches the wrong thing or nothing at all.

Edge cases

• Monorepo packages: the value path must be anchored per package; a repo-root [rootDir] in a package config points at the wrong dir.
• If the alias maps to a directory index file, add the trailing path explicitly; Jest does not guess index files through a mapper value.
• ESM projects: mapper values still work, but extensionless imports may also need extensionsToTreatAsEsm or a custom resolver.

Provenance

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

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

Thread query: jest moduleNameMapper not working for aliased imports

TL;DR: Put the most specific mapper entries first, write each key as a full regex, and point values at [rootDir]-anchored paths. Jest never reads tsconfig paths or bundler alias settings, so every alias needs its own mapper entry. Double-check you edited the config file Jest actually loads.

Not specified by the original author.

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

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

Thread query: 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.