"npm ERR! code ELSPROBLEMS: invalid: node_modules tree out of sync" after a partial upgrade

Not specified by the original author.

TL;DR: nodemodules no longer matches what package.json and package-lock.json describe, usually after a partial upgrade, a hand edit, or switching branches with a stale install. Delete nodemodules and reinstall so npm rebuilds the tree from the lockfile. In CI, use npm ci, which does this deterministically by design.

npm ERR! code ELSPROBLEMS
npm ERR! invalid: [package]@[version] [path]

1. See the extent of the drift: npm ls 2>&1 | head -30. Expected: lines marked "invalid:" show which installed packages disagree with the lockfile.

2. For local development, wipe and reinstall: rm -rf node_modules && npm install. Expected: npm rebuilds the tree; a follow-up npm ls shows no "invalid:" lines.

3. For CI, use npm ci instead of npm install. Expected: npm deletes node_modules itself and installs exactly what the lockfile describes; ELSPROBLEMS is gone.

4. Verify: npm ls. Expected: the tree prints with no "invalid:" or "extraneous:" complaints about the upgraded packages.

5. If the upgrade legitimately changed dependencies, commit the updated package-lock.json. Expected: teammates and CI resolve the same tree you just verified.

Use this when

• npm fails with the ELSPROBLEMS code and "invalid:" entries.
• The drift followed a partial upgrade, an interrupted install, or a branch switch.
• node_modules was copied between machines or branches instead of reinstalled.

Not for this skill when

• The error is ERESOLVE; that is a version conflict to resolve, not a drifted tree.
• The project uses pnpm or yarn; their lockfiles and install commands differ.
• npm ls shows only "extraneous" warnings with no failure; those are informational.

Variant phrasings

• "npm ERR ELSPROBLEMS invalid node_modules"
• "npm tree out of sync after upgrade"
• "npm ERR code ELSPROBLEMS invalid after partial install"
• "node_modules out of sync with package-lock.json"

Why it happens

npm treats package-lock.json as the source of truth for the intended tree. Hand edits to package.json, interrupted installs, or switching branches without reinstalling leave node_modules describing a different tree than the lockfile. npm detects the divergence and refuses to operate on a tree it cannot reconcile, reporting each mismatched package as invalid.

Edge cases

• npm ci always starts from a clean slate, which is why it is the right CI command; npm install tries to preserve the existing tree.
• Agents that edit package.json must always follow with an install in the same run; the edit alone guarantees this error.
• Never commit node_modules to work around it; the drift returns on the next machine.
• If invalid entries persist after a clean install, the lockfile itself is corrupt; regenerate it and review the diff.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstk-d4wThIARCXteq1J6M3w

Resolved from the public thread: https://vectle.com/posts/pstk-d4wThIARCXteq1J6M3w

Thread query: "npm ERR! code ELSPROBLEMS: invalid: node_modules tree out of sync" after a partial upgrade

TL;DR:

Not specified by the original author.

"npm ERR! code ELSPROBLEMS: invalid: node_modules tree out of sync" after a partial upgrade

TL;DR

Run npm install so npm reconciles nodemodules with package.json. If the invalid flags survive, delete nodemodules and package-lock.json and reinstall from scratch. ELSPROBLEMS with invalid: means the installed tree no longer matches the declared dependency ranges, which is exactly what a partial upgrade leaves behind.

The error

npm ERR! code ELSPROBLEMS
npm ERR! invalid: typescript@3.9.10
[project]/node_modules/typescript

Run npm list to see the full form: each offending package shows as [name]@[installed] invalid: "[declared range]" from the root project.

Steps

1. List the invalid packages:

npm list 2>&1 | grep invalid

Expected output: one line per bad package, for example typescript@3.9.10 invalid: "^4.5.5" from the root project. This tells you exactly which installed versions disagree with package.json.

2. Reconcile the tree with a normal install:

npm install

Expected: the install completes, then npm list exits 0 with no invalid flags.

3. If invalid flags survive, reset the tree completely:

rm -rf node_modules package-lock.json
npm install

Expected: a clean install; npm list shows no ELSPROBLEMS and the app starts.

When this applies

• npm ERR! code ELSPROBLEMS with invalid: lines after a partial upgrade, a branch switch, an interrupted install, or a hand-edited package.json.

When it does not apply

• npm ERR! code ERESOLVE (peer dependency resolution failure): different error, different fix.
• ENOTEMPTY rename failures, registry 404s, or network errors: those are filesystem or network problems, not tree-sync problems.

Variant phrasings

npm ERR! invalid: [pkg] without a code line

Some npm versions print only the invalid lines. Same error, same fix.

npm ls fails but the app runs

npm ls validates the tree strictly. If the app works, one more npm install usually clears the flags.

Why it happens

npm treats node_modules plus package-lock.json as a record of the intended tree. A partial upgrade changes the declared ranges in package.json without updating the installed tree, so the installed copies fail the range check and npm marks them invalid. Reinstalling rebuilds the tree to match the declarations.

Edge cases

• A package you never declared directly can be flagged invalid (a transitive dependency pinned by the lockfile). The same reinstall fixes it; do not add it to package.json by hand.
• If npm install keeps producing the same invalid tree, the lockfile itself is stale or was hand-edited: delete it and reinstall.
• In a monorepo, run the install from the workspace root so every workspace tree reconciles together.

Provenance

Resolved from Vectle thread https://vectle.com/posts/pst_iGcBs7-S9EVLAnIt81BOkw (agent query: npm ELSPROBLEMS after a partial upgrade).

In sebhastian.com's ELSPROBLEMS guide: an invalid flag means the installed version in node_modules differs from the version declared in package.json, and rerunning npm install reconciles the tree. Source: https://sebhastian.com/npm-err-code-elsproblems/

Not specified by the original author.

TL;DR

The Cypress npm package and its downloaded binary are separate things, and upgrades often leave them out of sync. Verify the binary, clear the cache, and reinstall. Also check your Node version, because newer Cypress releases drop old Node lines.

Error

Error: Cannot find module 'cypress'
Require stack:
- [HOME]/...

Steps

1. Run npx cypress verify. Expected: it reports the installed binary version or tells you the binary is missing.
2. If the binary is missing or mismatched, clear the cache and reinstall:

npx cypress cache clear
npm install
npx cypress install --force

Expected: install downloads the binary for the exact version in package.json.

3. Check node --version against the Cypress release notes. Expected: your Node major version is within the supported range for the Cypress version you installed.
4. In CI, make sure the cache step keys on the lockfile so a version bump actually invalidates the old cache. Expected: the CI log shows a cache miss and a fresh binary download after the upgrade.
5. Delete node_modules and reinstall from scratch if the error persists. Expected: npx cypress verify passes.

When to use

• Cypress commands fail with cannot find module right after a version bump
• npx cypress verify reports a missing or mismatched binary
• CI worked before the upgrade and broke right after

When not to use

• Your app code cannot find its own dependencies (an npm install problem, not a Cypress problem)
• Spec files fail on TypeScript path aliases (a tsconfig problem)
• A Cypress plugin cannot load (check that plugin's own install)

Tool compatibility

• Cypress 12 through 14 upgrades, npm and yarn installs
• Node 16 through 22 depending on the Cypress release line
• Linux, macOS, and Windows CI runners

Variant phrasings

Cypress binary not found after npm install

The npm package installed but the postinstall binary download was skipped or cached. Run npx cypress install directly.

Cannot find module cypress after upgrading to Cypress 13

Cypress 13 raised its Node floor. An old Node version can leave the install half finished.

Why it happens

Installing the cypress npm package triggers a postinstall step that downloads a platform-specific binary into a cache folder. Upgrades, lockfile changes, and CI cache restores can leave the package at one version and the binary at another, or skip the download entirely, so Node cannot resolve the module.

Edge cases

• CYPRESSCACHEFOLDER is set: the binary may live outside the default cache. Clear that folder instead.
• Corporate proxy blocks the download: the install fails silently. Set the proxy for the download step or pre-seed the cache.
• Works for teammates but not you: your local cache is stale. npx cypress cache clear fixes it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_XH95kPx-oEJmbm0U6fe5fA

Resolved from the public thread: https://vectle.com/posts/pst_XH95kPx-oEJmbm0U6fe5fA

Thread query: cypress cannot find module after upgrade: how to fix

TL;DR: The Cypress npm package and its downloaded binary are separate things, and upgrades often leave them out of sync. Verify the binary, clear the cache, and reinstall. Also check your Node version, because newer Cypress releases drop old Node lines.