webpack "export 'X' was not found in" - Fix Bad Named Imports

By Kaveh Alemi·Latchkey

webpack resolved the module but the specific named export you imported does not exist on it. The path is fine; the binding is wrong - a typo, a default-vs-named mismatch, or an export removed by a version bump.

What this error means

The build fails (or warns then fails on strict CI) with export 'X' (imported as 'X') was not found in '<module>', often listing the names that *are* exported. It is deterministic.

ERROR in ./src/cart.js 2:0-30
export 'addItem' (imported as 'addItem') was not found in './store'
(possible exports: addToCart, removeFromCart)

Diagnose it: is it resolution, transform, or memory?

Bundler failures in CI fall into three families and the error text often points at the wrong one. A module that resolves on your machine and not on the runner is nearly always case sensitivity or a missing optional dependency; a transform error is a config or version mismatch; and an unexplained kill with no stack is the out-of-memory reaper, not a build error at all.

# 1. resolution: does the file exist with EXACTLY that case?
git ls-files | grep -i "the/imported/path"

# 2. transform: what versions is CI actually resolving?
npm ls webpack vite rollup esbuild typescript 2>/dev/null | head -20

# 3. memory: was it killed rather than failed?
#    exit 137 = SIGKILL (OOM). Nothing in the bundler log will explain it.
node --max-old-space-size=4096 node_modules/.bin/vite build

Common causes

Named import does not match the export

You imported { addItem } but the module exports addToCart. A typo or a renamed export breaks the named binding even though the file resolves.

Default vs named confusion

Importing { Thing } from a module that only has a default export (or vice versa) leaves the named binding undefined and webpack reports it missing.

Export removed or renamed by an upgrade

A dependency major version dropped or renamed an export; your import still references the old name.

How to fix it

Import the name the module actually exports

Match the import to the real export, fixing default vs named.

// wrong:
import { addItem } from './store'
// right (named export is addToCart):
import { addToCart } from './store'
// or a default export:
import store from './store'

Confirm the export after a dependency bump

1. Open the module (or its types) and read the actual export list webpack printed.
2. Update your import to the new name if an upgrade renamed it.
3. Run a type-check (tsc --noEmit) so missing exports surface before the bundle step.

Make the build reproducible before you debug it

• Pin the Node major in setup-node and in engines. A bundler that resolves native bindings will pick a different prebuilt binary across majors.
• Delete node_modules locally and reinstall from the lockfile before concluding the runner is at fault; most "works locally" reports are stale local state.
• Set CI=true locally to reproduce. Several toolchains change behaviour under it, including treating warnings as errors.
• Exit code 137 is an out-of-memory kill. Raise --max-old-space-size or move to a larger runner rather than searching the bundler config.

How to prevent it

• Let TypeScript or eslint-plugin-import catch missing named exports before build.
• Read changelogs for renamed/removed exports when bumping a dependency major.
• Prefer editor auto-import so export names are spelled correctly.

Frequently asked questions

Related guides

References

• Node.js documentation
• npm CLI documentation
• GitHub Actions documentation