npm ELOCKVERIFY / "Errors were found in your package-lock.json" - Fix in CI

By Daniel Zoghalchali·Latchkey

A lockfile-verification failure means npm found package-lock.json internally inconsistent - missing entries, mismatched integrity, or merge damage - so it cannot trust the lock to install from.

What this error means

npm ci (or install) reports that errors were found in package-lock.json and asks you to run npm install to fix them. The lockfile is structurally broken, usually after a bad merge or a hand edit.

npm error `npm ci` can only install with an intact lock file.
npm error Errors were found in your package-lock.json, run npm install to fix them.
npm error     Invalid: lock file's lodash@4.17.20 does not satisfy lodash@4.17.21

Diagnose it: reproduce the CI install locally

Install failures are usually environment drift rather than a broken lockfile: a different package-manager major, a different Node version, or a cache that is being restored from a run with different inputs. Reproduce the CI conditions before changing the lockfile, because regenerating it hides the real cause.

# match the runner exactly, then install from a clean slate
node --version && npm --version
rm -rf node_modules
npm ci --foreground-scripts

# if that succeeds locally but fails in CI, the difference is the cache
# or the package-manager version, not your lockfile

Common causes

A merge-mangled or hand-edited lockfile

Resolving a package-lock.json conflict by hand, or editing it manually, easily produces an inconsistent tree npm cannot verify.

A truncated or partially written lockfile

A lockfile committed mid-write, or corrupted by a tool, fails verification because entries or integrity hashes are missing.

How to fix it

Regenerate the lockfile cleanly

Let npm rebuild a consistent lockfile, then commit it.

rm -f package-lock.json
npm install            # regenerates a clean, verifiable lock
git add package-lock.json && git commit -m "chore: regenerate lockfile"

Keep CI on npm ci

1. Resolve lockfile conflicts by regenerating, not editing.
2. Commit the freshly generated lock so CI verifies the same tree.
3. Add a drift check (npm install --package-lock-only + git diff --exit-code).

Verify the fix survives a cold cache

A green run immediately after a fix often proves nothing, because it restored a cache written before the change. Force a cold install once to confirm the fix is real.

# temporarily bust the cache key to prove the fix on a cold runner
- uses: actions/setup-node@v4
  with:
    node-version: 22
    cache: npm
    cache-dependency-path: package-lock.json
# then bump this suffix once, run, and remove it
#   key: ${{ runner.os }}-node-${{ hashFiles('package-lock.json') }}-v2

How to prevent it

• Always regenerate the lockfile instead of hand-merging.
• Commit a clean lock that passes npm ci.
• Guard against lockfile drift in PRs.

Frequently asked questions

Related guides

References

• Node.js documentation
• npm CLI documentation
• GitHub Actions documentation