When Your AI Coding Tool Hallucinates Packages and Breaks the Build: Detect and Fix It

AI coding tools (Cursor, Copilot, bolt.new, Lovable, and similar) sometimes invent npm package names, imports, or APIs that do not exist. Installs fail with Cannot find module, or worse — a similarly named malicious package could be waiting for a typo. That supply-chain risk is often called slopsquatting.

How to spot a hallucinated dependency

The AI suggests npm install some-plausible-name you have never used
npm install fails or the package has zero real downloads / no GitHub repo
Build error: Cannot find module '…' for an import the model just added
The API shape in the snippet does not match the library’s real docs

Fix 1: Verify before you install

Search the exact package name on npmjs.com.
Check download counts, last publish date, and linked repository.
Open the real docs and confirm the import path and API.
Only then install — prefer a known package you already trust in the ecosystem.

Never run an AI-suggested install blindly, especially on a machine with npm credentials or production access.

Fix 2: Pin versions and commit the lockfile

After a verified install:

Commit package-lock.json / pnpm-lock.yaml / yarn.lock
Avoid floating ranges for critical packages when you need reproducibility
Review lockfile diffs in PRs so a hallucinated name cannot sneak in unnoticed

Fix 3: Feed the build error back to the AI

When the build fails, start a tight prompt with the exact error and a hard constraint, for example:

Build failed with:
Cannot find module 'example-package'

Do not invent packages. Use only dependencies already in package.json,
or propose a well-known package that exists on npm and explain why.
Show the npm package name to verify before any install command.

Replace the module name with your real error. Instruct the model to stick to verified dependencies.

Security note on slopsquatting

Attackers can publish lookalike packages that match common AI typos. Treat unknown install suggestions as untrusted until you confirm the package is legitimate. Prefer packages with clear maintainers, a public repo, and real usage — and never use illustrative fake package names from blog posts as install targets.

Quick checklist

Verify every new package on npm before npm install
Commit and review lockfiles
Paste exact build errors; ban invented dependencies in the prompt
Treat hallucinated names as a security check, not only a bug fix