What does npm:ELSPROBLEMS mean?

npm ls reported ELSPROBLEMS because the installed dependency tree contains missing, invalid, or extraneous packages.

npm ERR! code ELSPROBLEMS

Q: How do I prevent npm:ELSPROBLEMS in CI?

Use `npm ci` in CI for clean deterministic installs. Avoid manually editing `node_modules`. Keep lockfiles committed.

Fix it fast

Most likely: node_modules does not match the package metadata or lockfile: a package is missing, invalid, extraneous, or installed from the wrong workspace level.

1. Confirm this is your error

npm ERR! code ELSPROBLEMS
t.equal(err.code, 'ELSPROBLEMS', 'should have ELSPROBLEMS error code')
t.equal(err.code, 'ELSPROBLEMS', 'should have error code')

2. Check the cause

npm ls
npm ls --workspaces
npm config get workspaces

3. Apply the safe fix

# From the project root, rebuild the installed tree from the lockfile.
npm ci

# If this project does not have a lockfile, reinstall and create/update one.
npm install

# In a workspace project, run install from the workspace root.
npm install --workspaces

4. Verify it works

npm ls
npm test

Don't use unsafe shortcuts

Do not manually edit files inside node_modules.
Do not run install from a child workspace if the root lockfile controls the dependency tree.
Do not ignore npm ls output in CI, it is telling you the installed tree is inconsistent.

What This Error Means

Read this as a precise clue about which part of the workflow broke first. Once you know the failing layer, the fix path gets much shorter.

How to Fix It

Delete node_modules and reinstall (npm install or npm ci if you have a lockfile).

Run npm ls again and inspect the first reported problem.

If using workspaces, run install from the workspace root.

Why It Happens

Usually this comes down to node_modules is in a partially installed state, a dependency was removed or changed without reinstalling, or workspaces or symlinks are pointing at unexpected locations.

Verify the Fix

Run npm ls and confirm it completes without ELSPROBLEMS, and run your build/test command to confirm runtime behavior.

Manual debugging checklist

Repeat the failure from the same environment with verbose or debug logging so you can confirm the first actionable error, not just the final summary line.

Validate the local configuration and the remote target separately. That usually narrows the problem much faster than retrying the full workflow.

Compare the failing environment with one that works, paying attention to credentials, runtime versions, proxy settings, and filesystem paths.

How npm executes the command

This is the part worth understanding if the quick fix did not hold. It explains what npm is trying to do at the moment the error appears.

npm ls walks the installed dependency tree and compares it to expected metadata.

When it finds inconsistencies, it reports them as problems.

Prevent It From Coming Back

To prevent this, use npm ci in CI for clean deterministic installs, avoid manually editing node_modules, and keep lockfiles committed.

Docs and source code

github.com/npm/cli/blob/417daa72b09c5129e7390cd12743ef31bf3ddb83/lib/commands/ls.js

Open-source npm CLI code reference tied to this error code. - GitHub

    if (shouldThrow) {
      throw Object.assign(
        new Error([...problems].join('\n')),
        { code: 'ELSPROBLEMS' }
      )
    }
  }