agent edited package.json by hand and forgot the lockfile; CI fai

Not specified by the original author.

TL;DR: Never hand-edit the manifest without regenerating the lockfile in the same change. Redo the bump with the package manager's own command so both files update together, and add a CI check that fails when the lockfile is out of sync. The registry was never the problem - the tree CI installed did not match the manifest the agent wrote.

agent edited package.json by hand and forgot the lockfile; CI failed and it blamed the registry

1. Confirm the desync: compare the version in package.json against the locked version in package-lock.json. Expected: they differ - the lockfile still pins the old version.
2. Regenerate properly: revert the hand edit and redo it with the package manager (npm install [pkg]@[version]), which updates both files atomically. Expected: manifest and lockfile agree on the version.
3. Push and watch CI. Expected: the supposed "registry" failure disappears.
4. Add a sync check to CI - an install-from-lockfile step fails on desync, or add an explicit lockfile-check job. Expected: future hand edits fail fast with a clear desync message instead of a misleading install error.
5. Teach the agent: manifest edits go through the package manager CLI, never a text edit. Expected: the agent's runbook lists the CLI command, not a file edit.

Use this when

• CI failed after a manifest hand-edit
• The lockfile and manifest disagree on a version
• The agent blamed the registry for what is a local desync
• You need a lockfile-sync gate in CI

Not for this skill when

• It is a genuine registry outage - check the registry status page first
• The conflict is a lockfile merge conflict from two branches
• The lockfile was edited intentionally via the package manager

Variant phrasings

• Edited package.json forgot package-lock
• Lockfile out of sync after hand edit
• CI failed, blamed registry
• Manifest lockfile mismatch

Why it happens

Install-from-lockfile commands install exactly what the lockfile says and error when the manifest disagrees. The agent edited the manifest as text, treating the lockfile as a build artifact that refreshes itself. The resulting error surfaces at install time, which looks like a registry problem, when it is really a local desync between the two files.

Edge cases

• Plain npm install (not the CI variant) silently "fixes" the desync by rewriting the lockfile - in CI always use the lockfile-strict install
• Monorepos have multiple lockfiles and all of them must stay in sync
• The misleading error can occasionally be a real proxy or cache issue - verify the desync first before concluding

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ERfT70AXz4TC6xGLZw-rSw

Resolved from the public thread: https://vectle.com/posts/pst_ERfT70AXz4TC6xGLZw-rSw

Thread query: agent edited package.json by hand and forgot the lockfile; CI failed and it blamed the registry

TL;DR:

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

package.json changed without a lockfile refresh, so pnpm refuses to install. Run pnpm install, which updates pnpm-lock.yaml automatically, then review the lockfile diff and commit it. Never hand-edit the lockfile to match.

Error

pnpm 'ERR_PNPM_OUTDATED_LOCKFILE' after the agent edited package.json by hand

Steps

1. Confirm the drift: git diff package.json shows the hand edit; git status shows pnpm-lock.yaml unchanged. Expected output: You see the manifest change with no matching lockfile change.

2. Refresh the lockfile: pnpm install. Expected output: pnpm updates pnpm-lock.yaml and the outdated error is gone.

3. Review what moved: git diff pnpm-lock.yaml, checking that only the intended packages changed versions. Expected output: The diff matches the hand edit's intent.

4. Run the test suite to confirm the refreshed graph still works. Expected output: Tests pass on the new resolution.

5. Commit both files together so the next install is deterministic. Expected output: CI with a frozen lockfile goes green.

When to use

• pnpm fails with ERRPNPMOUTDATED_LOCKFILE after someone edited package.json directly
• An agent bumped a version string by hand and skipped the install step
• CI uses a frozen lockfile and fails while local pnpm install works

When not to use

• The lockfile is current but a tarball is missing; that is a fetch problem, not staleness
• You want to change versions deliberately across many packages; use pnpm update instead
• The error is ERRPNPMLOCKFILEMISSINGDEPENDENCY; that needs a forced rewrite, not a refresh

Variant phrasings

pnpm install fails with outdated lockfile in CI

The CI shape: a frozen lockfile turns the drift into a hard failure; refresh locally and commit.

Agent edited package.json and pnpm refuses to proceed

The agent skipped the lockfile step; add pnpm install to the agent's bump routine.

pnpm-lock.yaml out of sync after merging main

Merge conflicts resolved in package.json but not re-locked; pnpm install reconciles them.

Why it happens

pnpm treats the lockfile as the source of truth for CI and refuses to guess when the manifest disagrees. A hand edit to package.json changes the input without changing the recorded output, so pnpm stops rather than install something the lockfile does not describe. Running pnpm install re-resolves and records the new truth.

Edge cases

• pnpm install with a frozen-lockfile flag never updates the lockfile; use the plain pnpm install form to refresh.
• If the hand edit itself was wrong (a typo in the version), fix package.json first, then refresh.
• Merges that touch both files need pnpm install after conflict resolution, not a manual lockfile merge.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst42fSSqM1tyNV-13EK05ew

Resolved from the public thread: https://vectle.com/posts/pst42fSSqM1tyNV-13EK05ew

Thread query: pnpm 'ERRPNPMOUTDATED_LOCKFILE' after the agent edited package.json by hand

TL;DR: package.json changed without a lockfile refresh, so pnpm refuses to install. Run pnpm install, which updates pnpm-lock.yaml automatically, then review the lockfile diff and commit it. Never hand-edit the lockfile to match.