What does "Module not found: Can't resolve" mean?

What it actually is

Import and export are the two keywords that let one file use code from another: a function, a variable, a whole React component. A file exports what it wants other files to use; another file imports it by name. Without this, every file would redefine everything itself.

Think of a file like a shop counter. export puts an item on the counter with a label, so people outside can take it. import walks up to a specific counter and asks for that label. Ask for a label that doesn’t exist, or walk up to the wrong counter, and you leave empty handed. That’s the error your bundler reports.

Exports come in two shapes. A default export is the one main thing a file hands out (export default function Header() {}), imported under any name you like, no curly braces needed. A named export is one item among possibly several (export function Header() {}), imported with curly braces and the exact name (import { Header } from './Header'), since you’re pulling one specific labeled item out of everything the file offers. Mix the two up and you get undefined or a message saying the module doesn’t provide that export, not a missing-file error.

Node.js runs two module systems side by side: the import/export syntax above (ESM, the current standard) and an older require('./Header') / module.exports = Header style called CommonJS. Which one a file uses depends on its extension (.mjs is always ESM, .cjs always CommonJS) or the "type" field in the nearest package.json. Your agent’s frontend code is usually ESM; older packages and Node backend code often stay CommonJS.

Why your AI just did this

Your agent breaks imports in predictable ways. It renames or moves a file (Header.jsx becomes components/nav/Header.jsx) and misses another file still importing the old path. It writes an import from memory instead of checking what a file actually exports, so a default import ends up aimed at a named export or the reverse. It reaches for a package, say import { v4 } from 'uuid', that it never installed, so nothing in node_modules matches that name. Large scaffolding passes in Lovable, Cursor, or Claude Code are especially prone to this: the agent writes a dozen files at once and loses track of where one landed.

When you’ll run into it

On a bundler-based dev server (Next.js, Vite, Create React App, whatever Lovable or Bolt hands you), a broken relative import shows up as:

Module not found: Can't resolve './components/Header'

That phrasing (sometimes with the searched folder tacked on after “in”) is webpack’s, and webpack sits under Next.js and Create React App. Vite phrases the same miss as Failed to resolve import "./components/Header" from "src/App.jsx". Does the file exist?

Outside a bundler, a plain Node.js script or server run with node server.js reports it as:

Error: Cannot find module './components/Header'

with a MODULE_NOT_FOUND code, Node’s own require() resolver flagging the same kind of miss.

A quieter failure looks nothing like a missing file: the path is right, but you get undefined where you expected a function, or a message saying the module has no export by that name. That’s a default-versus-named mismatch. Open the file and match how it exports the thing to how you’re importing it.

What to check

• Copy the path from the error message and confirm a file sits at exactly that location, matching folder names and casing (Header.jsx and header.jsx are different files on a Linux server, even if your Mac or Windows machine treats them as the same)
• Open the file being imported and check whether it uses export default or a named export. Match the import: no curly braces for default, exact name in braces for named
• For a bare name with no ./ or ../ in front, like 'uuid', confirm it’s listed in package.json’s dependencies and installed, not just typed into an import line
• Remember the rule your bundler follows: anything starting with ./ or ../ is a file on disk, anything else is a package name looked up in node_modules
• If it worked locally but fails after deploying, suspect casing first. Local filesystems are often forgiving about it; production servers usually aren’t
• Ask your agent to run the actual build, not just the dev server, before calling a feature done. Some broken imports only surface at build time

Say it like a dev

Instead of: “the header disappeared, nothing renders” Say: “I’m getting Module not found: Can't resolve './components/Header' in the console. Check whether that file exists and fix the import path.”

Instead of: “it just says undefined, I don’t get it” Say: “Header.jsx uses a named export, not a default export. Fix the import in whichever file is pulling it in wrong.”

Instead of: “add the missing package however you need to” Say: “I’m importing from ‘uuid’ but it’s not in package.json. Install it properly as a dependency instead of working around the missing import.”