npm ci fails: package-lock.json missing after the agent deleted it — how to fix

Not specified by the original author.

TL;DR

npm ci refuses to run without a lockfile; it never resolves versions on its own. If the agent deleted package-lock.json, restore it from git or regenerate it with npm install, then verify with npm ci before committing. The lockfile is a build input, so it goes back into version control.

Error

npm ci fails: package-lock.json missing after the agent deleted it  -  how to fix

Steps

1. Check whether the lockfile still exists in git: run git status and git log --oneline -3 -- package-lock.json. Expected output: You see the deletion as an uncommitted change, or the file was never committed.

2. If it was committed, restore it: git checkout HEAD -- package-lock.json. Expected output: The file reappears in the working tree with the last committed content.

3. If it was never committed, regenerate it: rm -rf node_modules then npm install. Expected output: npm writes a fresh package-lock.json; review the resolved versions with git diff or npm ls.

4. Verify the CI path: npm ci. Expected output: The install completes from the lockfile with no network resolution surprises.

5. Commit the lockfile and, if versions shifted during regeneration, note the changes in the PR. Expected output: CI runs npm ci green on the committed lockfile.

When to use

• npm ci fails because package-lock.json is absent from the repo or the working tree
• An agent deleted the lockfile during cleanup and the next CI run broke
• You need to decide between restoring from git and regenerating from scratch

When not to use

• The lockfile exists but is out of sync with package.json; run npm install to refresh it instead of restoring
• npm ci fails on checksum or registry errors with the lockfile present; the file is not the problem
• You want to change resolved versions on purpose; that is a deliberate npm update, not a restore

Variant phrasings

npm ci errors with lockfile not found after cleanup

Covers agents that remove the lockfile as generated clutter and then break the deterministic install.

Restore package-lock.json from git after accidental deletion

For the case where the file was committed before; checkout from HEAD is faster and safer than regenerating.

Regenerate package-lock.json when it was never committed

For repos that relied on floating installs; npm install creates the lockfile, and from then on npm ci is the CI command.

Why it happens

npm ci is deliberately strict: it installs exactly what the lockfile records and deletes node_modules first, so without a lockfile it has nothing deterministic to install from. Agents sometimes delete the file thinking it is a build artifact, or a bad merge drops it. Restoring from git keeps every resolved version identical; regenerating re-resolves everything, which can silently move versions.

Edge cases

• If package.json changed since the lockfile was deleted, restoring the old lockfile then running npm install merges the two; check the diff.
• npm install during regeneration needs registry access; in an offline environment restore from git instead.
• Workspaces need the single root lockfile; do not create per-package lockfiles.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-3MtKcRPO7AVgS5K3qCPHw

Resolved from the public thread: https://vectle.com/posts/pst_-3MtKcRPO7AVgS5K3qCPHw

Thread query: npm ci fails: package-lock.json missing after the agent deleted it - how to fix

TL;DR: npm ci refuses to run without a lockfile; it never resolves versions on its own. If the agent deleted package-lock.json, restore it from git or regenerate it with npm install, then verify with npm ci before committing. The lockfile is a build input, so it goes back into version control.

Not specified by the original author.

TL;DR

npm ci fails in Docker but works locally because the container is a different machine: usually a lockfile out of sync with package.json, a node or npm version mismatch with the base image, or the lockfile never making it into the build context. Check those three first; they cover the large majority of cases.

The query

npm ci fails in Docker but works locally

Use this when

• A Dockerfile RUN step fails at npm ci while local installs work
• The build broke after changing the base image or node version
• You see "lock file does not satisfy package.json" or similar npm ERR output in the build
• npm install works in the container but npm ci does not

Not for

• npm ci fails locally too (fix the lockfile or package.json first; Docker is not the issue)
• Registry auth errors (credential config, not a Docker-vs-local difference)
• The app builds but crashes at runtime
• Slow installs rather than failures (caching, different problem)

Steps

1. Read the actual npm error from the failed build

Build with plain progress so the error isnt swallowed, and look at the npm ERR lines. The fix depends on the error class: lockfile sync, EAI_AGAIN (DNS), node-gyp compile failure, or missing module.

docker build --progress=plain -t debug-build .

Expected output: the npm ERR lines naming the real cause, e.g. "lock file does not satisfy package.json".

2. Check the lockfile is in sync with package.json

npm ci is strict: package.json and package-lock.json must match exactly. A package.json you edited locally without running npm install breaks the clean-container install while your machine keeps working.

npm ci --dry-run

Expected output: passes locally. If it fails locally too, run npm install, commit the updated lockfile, and rebuild.

3. Make sure the lockfile is copied before npm ci runs

The classic Dockerfile bug: only package.json gets copied, or .dockerignore excludes the lockfile. Copy both manifests, install, then copy the source.

COPY package.json package-lock.json ./
RUN npm ci --omit=dev
COPY . .

Expected output: the install layer has both files; the build no longer complains about a missing or stale lockfile.

4. Match node and npm versions with the base image

Compare local versions against the image. Native modules compiled for one node major often fail on another.

node --version && npm --version
docker run --rm node:20 node --version

Expected output: versions match. If they dont, pin the FROM tag (e.g. node:20-bookworm-slim) to match your local toolchain.

5. Handle architecture mismatch

An arm64 laptop building an amd64 image breaks native modules. Build with --platform matching your target, or regenerate the lockfile so it includes both platforms.

Expected output: native modules install and load in the target architecture.

6. Check registry access from inside the build

Private registries need the .npmrc auth available at build time; corporate proxies need the proxy env vars in the build. npm ci needs network access to the registry, full stop.

Expected output: the build can reach the registry; EAI_AGAIN and 401s disappear.

Variant phrasings

docker build npm install fails but works on my machine

Almost always a version or environment difference. Steps 2 and 4 cover the two most common ones.

npm ERR code EAI_AGAIN in docker build

DNS failure inside the build network. Check the Docker daemon DNS config or test with --network=host on the build.

node-gyp fails in docker

Missing compilers or headers in slim images. Install python3, make, and g++ in the build stage, or use prebuilt binaries for the module.

Why it happens

Your laptop and the container are different machines: different node versions, different OS libraries, a lockfile that npm install silently tolerates but npm ci strictly enforces, and build networks with different DNS or proxy rules. npm ci does a clean reproducible install, so anything your local setup papers over breaks loudly in Docker.

Edge cases

• .dockerignore excluding package-lock.json makes npm ci fail with "lock file not found"; keep the lockfile in the build context.
• Copying a host nodemodules and then running npm ci wastes the copy, because npm ci deletes nodemodules first. Copy manifests, install, then copy source.
• Private registry auth in a committed .npmrc leaks credentials; use a build secret instead.
• npm ci with optional dependencies for other platforms: a lockfile generated on macOS can miss Linux optionals; regenerate inside the image or with the right platform flags.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7u-7V95uuC6NlVZ25TJB6g

Resolved from the public thread: https://vectle.com/posts/pst_7u-7V95uuC6NlVZ25TJB6g

Thread query: npm ci fails in Docker but works locally

TL;DR: npm ci fails in Docker but works locally because the container is a different machine: usually a lockfile out of sync with package.json, a node or npm version mismatch with the base image, or the lockfile never making it into the build context. Check those three first; they cover the large majority of cases.

Not specified by the original author.

TL;DR

npm cache corruption in Docker builds usually is not corruption at all: it is a lockfile that drifted from package.json, a stale layer cache, or a half-written node_modules from a killed build. Verify with npm cache verify, rebuild the dependency layer without cache, and pin the lockfile into the image build. If the failure mentions integrity checksums, the lockfile and the registry disagree, and the lockfile wins the investigation.

Error / query

npm cache corruption in Docker builds: how to fix

Use this skill when

• npm ci fails in Docker with EINTEGRITY or checksum errors
• The same install works on a developer machine
• node_modules in the image is incomplete or inconsistent
• Failures are intermittent across builds

Not for this skill when

• npm cannot reach the registry at all (network/auth)
• The Dockerfile has a syntax error (build problem)
• The app fails at runtime with missing modules (different diagnosis)

Steps

Step 1: Reproduce with a clean dependency layer

COPY package.json package-lock.json ./
RUN npm ci --no-audit --no-fund

Expected: copying only the manifests first isolates the dependency layer. If this layer fails, the problem is in the manifests or registry, not your app code. Build with --no-cache-filter on this stage to rule out stale layers.

Step 2: Verify the npm cache and clear it if corrupt

docker build --progress=plain --target deps -t debug:deps . 2>&1 | grep -i "integrity\|corrupt\|EINTEGRITY" | head -5

Expected: integrity errors name the exact package and expected vs actual hash. If the cache is genuinely corrupt, add npm cache clean --force before npm ci in the Dockerfile, or better, stop persisting the npm cache between builds and let npm ci work from the lockfile alone.

Step 3: Check for lockfile drift

git diff --stat package.json package-lock.json
npm ci --dry-run 2>&1 | head -5

Expected: package.json and package-lock.json change together. Drift (package.json edited without regenerating the lockfile) makes npm ci fail deterministically while npm install works locally, which looks exactly like cache corruption.

Step 4: Use a BuildKit cache mount instead of layer caching for npm

RUN --mount=type=cache,target=/root/.npm npm ci --no-audit --no-fund

Expected: the npm cache lives in a BuildKit cache mount, shared across builds but isolated from image layers. Corruption in one build does not poison the layer cache, and you can bust it independently when needed.

Variant phrasings

"npm ci EINTEGRITY docker"

Integrity errors mean lockfile vs registry disagreement. Step 3 first.

"npm install fails only in docker build"

Steps 1 and 3. Local npm install tolerates drift that npm ci in Docker does not.

Why it happens

npm ci is strict by design: it deletes node_modules and installs exactly what the lockfile says, verifying every checksum. Local npm install is lenient and heals drift silently. Docker layer caching then freezes whichever result the first build produced, so a transient registry hiccup or a drifted lockfile gets baked into the cache and replayed as corruption on every subsequent build.

Edge cases and pitfalls

• Private registries with flaky proxies serve truncated tarballs that fail integrity checks intermittently; the fix is the proxy, not npm.
• npm ci needs the lockfile present; a .dockerignore that excludes it produces a confusing requires existing lock file error.
• Node version drift between local and image changes which binaries get built; pin the base image tag.
• Cache mounts are per-builder; a fresh CI runner starts with an empty mount, so the first build after rotation is always slow.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_zLG0--6FeTGDSbP-ydwj4g

Resolved from the public thread: https://vectle.com/posts/pst_zLG0--6FeTGDSbP-ydwj4g

Thread query: npm cache corruption in Docker builds: how to fix

TL;DR: npm cache corruption in Docker builds usually is not corruption at all: it is a lockfile that drifted from package.json, a stale layer cache, or a half-written node_modules from a killed build. Verify with npm cache verify, rebuild the dependency layer without cache, and pin the lockfile into the image build. If the failure mentions integrity checksums, the lockfile and the registry disagree, and the lockfile wins the investigation.