What does npm:ELOCKVERIFY mean?

npm returned ELOCKVERIFY because the lockfile and installed dependency tree do not agree with what npm expected to verify.

Which npm versions are affected by npm:ELOCKVERIFY?

npm v5.0.0 and newer (lockfile verification).

How do I prevent npm:ELOCKVERIFY in CI?

Pin Node/npm versions in CI. Avoid manual lockfile edits. Use a stable proxy/cache registry to reduce metadata drift.

npm ERR! code ELOCKVERIFY

Q: How can I manually validate npm:ELOCKVERIFY?

Confirm lockfile exists and is not malformed: `node -e "JSON.parse(require(\"fs\").readFileSync(\"package-lock.json\",\"utf8\")); console.log(\"ok\")"`. Compare npm versions: `node -v` and `npm -v` (local vs CI).

Fix it fast

Most likely: package-lock.json does not match package.json, node_modules, or the npm version that is verifying it.

1. Confirm this is your error

npm ERR! code ELOCKVERIFY
npm ERR! Errors were found in your package-lock.json, run npm install to fix them.

2. Check the cause

node -v
npm -v
node -e "JSON.parse(require('fs').readFileSync('package-lock.json','utf8')); console.log('lockfile ok')"
npm ci

3. Apply the safe fix

# Regenerate the lockfile intentionally with the npm version your project supports.
npm install
git diff -- package-lock.json package.json

# After reviewing and committing the lockfile change, CI should use npm ci.
npm ci

4. Verify it works

npm ci
npm ls

Don't use unsafe shortcuts

Do not manually edit package-lock.json to make verification pass.
Do not delete the lockfile without reviewing the dependency changes that will be accepted.
Do not let local and CI use different npm majors if they keep rewriting the lockfile.

What Broke in the Dependency Graph

This is npm refusing to continue with a dependency graph that does not make sense. The important detail is which versions or peer requirements disagree, not just the final error code.

Repair the dependency graph

If you have a lockfile, regenerate it intentionally (delete node_modules, then run npm install).

Commit the lockfile changes and keep npm versions consistent across dev and CI.

If this happens only in CI, ensure CI uses the same Node/npm versions as local.

Why Resolution Broke

Usually this comes down to package-lock.json is out of sync with package.json (or was manually edited), different npm versions generated different lockfile formats and metadata, or a proxy registry served inconsistent metadata during lockfile generation.

Prove the Graph Is Clean Again

Run npm ci (only if package-lock.json exists) and confirm verification succeeds, and run npm ls and confirm the tree is consistent.

Manual checksum validation

Confirm lockfile exists and is not malformed with node -e "JSON.parse(require(\"fs\").readFileSync(\"package-lock.json\",\"utf8\")); console.log(\"ok\")", and compare npm versions with node -v and npm -v (local vs CI).

How npm verifies package integrity

npm uses the lockfile to produce a deterministic dependency tree in CI. When lockfile metadata is inconsistent or generated by different toolchains, verification can fail. Keeping Node/npm versions aligned reduces lockfile drift.

Keep the Dependency Graph Healthy

To prevent this, pin Node/npm versions in CI, avoid manual lockfile edits, and use a stable proxy/cache registry to reduce metadata drift.

Docs and source code

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

This is the lockfile verification path used by npm ci. Lockfile/package.json mismatches are detected here and can surface as ELOCKVERIFY in CLI output. - GitHub

    // verifies that the packages from the ideal tree will match
    // the same versions that are present in the virtual tree (lock file)
    // throws a validation error in case of mismatches
    const errors = validateLockfile(virtualInventory, arb.idealTree.inventory)
    if (errors.length) {
      throw this.usageError(
        '`npm ci` can only install packages when your package.json and ' +