Introduction

Cannot find module means Node tried to resolve a dependency and failed somewhere in its lookup rules. The fix is usually straightforward once you identify which kind of module you meant to load: a built-in module, a package from node_modules, or a local file referenced by path.

Start with the Resolution Rules

Node resolves imports differently depending on how you wrote them:

• 'require("fs") means a built-in module'
• 'require("express") means a package lookup in node_modules'
• 'require("./utils") means a local relative file or directory'

That distinction is the first thing to check, because many errors come from writing a package-style import when you meant a file path.

Example:

const helper = require("utils");   // looks for a package
const fixed = require("./utils");  // looks for a local file

If utils.js is a file in the current directory, the second line is the correct one.

Verify the Exact Target

A fast debugging trick is require.resolve(). It asks Node where it would load a module from and throws if resolution fails.

1try {
2  console.log(require.resolve("express"));
3  console.log(require.resolve("./utils"));
4} catch (error) {
5  console.error(error.message);
6}

That narrows the problem down quickly:

• wrong package name
• wrong relative path
• file missing
• installed in a different working directory than expected

Check Installation and Project Root

If the missing thing is a package, confirm that it is installed in the project where you are running Node:

1npm install express
2npm ls express
3pwd
4ls package.json node_modules

Many people install dependencies in one directory and run the script from another. Node will search upward from the current file location, not from whichever folder you mentally consider the project root.

If the dependency tree is broken, reinstalling can help:

rm -rf node_modules package-lock.json
npm install

CommonJS and ESM Differences

Modern Node projects may use either CommonJS or ECMAScript modules. That affects how imports behave.

For CommonJS:

const math = require("./math");

For ESM:

import { add } from "./math.js";

Two common mistakes happen here:

• using require() in a project configured for ESM
• omitting the file extension in ESM when Node expects it

So if your package.json contains "type": "module", revisit the import syntax before assuming the package itself is missing.

Pay Attention to Case and File Names

A path that works on macOS may fail on Linux if the capitalization does not match the real file name. This is common in CI or Docker builds:

require("./UserService"); // fails if the file is actually userService.js

Node treats those as different names when the filesystem is case-sensitive.

Local Files Are Not Packages

Another easy trap is expecting Node to infer the path you meant. It will not turn helper into ./helper for you. If the thing lives in your source tree, say so explicitly with ./ or ../.

That single character is responsible for a large share of Cannot find module errors.

Common Pitfalls

• Forgetting ./ or ../ when importing a local file.
• Installing a package in a different directory than the script is running from.
• Mixing CommonJS and ESM syntax without checking the package.json module type.
• Relying on capitalization that only works on a case-insensitive filesystem.
• Deleting the error stack too quickly instead of looking at the exact path Node tried to resolve.

Summary

• First decide whether the missing module is built-in, package-based, or a local file.
• Use require.resolve() to see exactly what Node can or cannot resolve.
• For local files, include ./ or ../ explicitly.
• For packages, verify installation in the correct project directory.
• Check ESM versus CommonJS rules and case-sensitive file names before assuming npm is broken.