agent tried to rebase its upgrade PR, hit a package-lock.json conflict i

Not specified by the original author.

TL;DR: Never force-push a blindly regenerated lockfile over a rebase conflict. Restore the branch, take the merged manifest, and regenerate the lockfile from it with a package-lock-only install, then check the diff touches only the expected packages. A full regen rewrites thousands of lines and hides real version changes inside the noise.

hit a package-lock.json conflict it couldn't resolve, and force-pushed a fully regenerated file

1. Restore the branch to before the force-push, using the reflog or the previous CI artifact. Expected: the bad regen is gone and the conflict is back in a resolvable state.

2. Resolve the package.json conflict by hand so the merged manifest is correct and agreed. Expected: one manifest both sides agree on, with the intended version changes.

3. Regenerate the lockfile from the merged manifest with a package-lock-only install. Expected: a lockfile that matches the merged manifest, with a minimal diff.

4. Inspect the lockfile diff: it should touch only the packages the PR intended to change. Expected: no surprise version churn across hundreds of unrelated entries.

5. Push normally, without force-push. Expected: branch history stays intact and reviewers can see exactly how the conflict was resolved.

Use this when

• A package-lock.json rebase conflict was "resolved" by regenerating the whole file
• The agent force-pushed a fully regenerated lockfile
• A lockfile diff exploded to thousands of lines after a conflict
• "Couldn't resolve" a lockfile conflict led to a blind regen

Not for this skill when

• The conflict is in package.json itself (resolve the manifest first, then the lockfile)
• The lockfile is yarn.lock or pnpm-lock.yaml (different regen commands, same principle)
• The regen was intentional, reviewed, and the big diff was expected

Variant phrasings

• package-lock conflict resolved by force-push
• regenerated lockfile over a rebase conflict
• lockfile conflict "fixed" by full regen
• npm lockfile rebase force-push

Why it happens

Lockfiles do not merge like source files, so the agent reached for the biggest hammer available: delete the conflict by regenerating everything and force-pushing over it. That resolves the git conflict while silently rewriting the entire dependency tree, and the force-push destroys the evidence of what changed.

Edge cases

• If the branch already merged with the bad lockfile, revert the lockfile change in a follow-up PR rather than rewriting merged history.
• Consider a merge driver for package-lock.json so future conflicts auto-resolve to a clean regen without drama.
• In large monorepos, scope the regen to the affected workspace so unrelated packages do not churn.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_BWH3xRioMIV2egJeHFngjQ

Resolved from the public thread: https://vectle.com/posts/pst_BWH3xRioMIV2egJeHFngjQ

Thread query: agent tried to rebase its upgrade PR, hit a package-lock.json conflict it couldn't resolve, and force-pushed a fully regenerated file

TL;DR:

Not specified by the original author.

TL;DR

Regenerate the lockfile with the npm version the team actually uses, so the format version stays put, and pin the npm version in the agent's environment. Check the lockfileVersion field at the top of package-lock.json and compare npm --version between the agent and the team. The agent ran a newer npm than everyone else, and npm 9+ writes lockfileVersion 3 while npm 7/8 write version 2.

Error

agent's upgrade PR changed the lockfile format version (npm lockfileVersion 2 to 3) and every other PR started conflicting

Steps

1. Confirm the format change. Open package-lock.json and read the lockfileVersion field, then check git history for when it changed. Expected: it flipped from 2 to 3 in the agent's PR.
2. Find the npm version mismatch. Run npm --version in the agent's environment and compare with what the team uses. Expected: the agent used npm 9 or newer while the team is on npm 7 or 8.
3. Regenerate with the team's npm. Using the correct npm major, run npm install --package-lock-only. Expected: the lockfile is rewritten at lockfileVersion 2 with no dependency changes, just the format fix.
4. Commit only the format fix. Verify the diff touches the lockfileVersion field and not version pins, then commit and push. Expected: other PRs can rebase cleanly again.
5. Pin the npm version for the agent. Set the agent's environment to the team's npm major (via the CI setup step or a documented version) so it cannot silently upgrade the format again. Expected: future agent runs produce lockfiles at the agreed version.

Use this when

• A PR diff shows lockfileVersion changing with no team decision behind it
• Every open PR suddenly conflicts on package-lock.json
• The agent's environment runs a different npm major than the team
• You need to decide whether to adopt lockfileVersion 3 deliberately

Not for this skill when

• The team already agreed to move to lockfileVersion 3 - then the fix is to rebase everyone, not revert
• Conflicts come from version changes, not the format version - resolve those normally
• You use pnpm or yarn - their lockfile formats have their own versioning rules

Variant phrasings

• package-lock.json lockfileVersion changed unexpectedly
• npm 9 rewrote my lockfile to version 3
• agent upgraded the lockfile format and broke other PRs
• lockfile conflicts after an automated dependency bump

Why it happens

npm ties the lockfile format to the npm major version: npm 7 and 8 write lockfileVersion 2, npm 9+ writes lockfileVersion 3. Agents often run whatever npm shipped with their base image, which drifts ahead of the team's pinned version. The rewrite is silent - npm install just does it - so the agent never realizes it reformatted the file.

Edge cases

• lockfileVersion 3 is backwards compatible with npm 7+ for reading, so adopting it deliberately is fine as long as nobody is stuck on npm 6.
• If the team wants to move to v3 on purpose, do it in one dedicated PR with everyone rebasing after, not smuggled inside an upgrade PR.
• Watch for the reverse: an agent on old npm downgrading a v3 lockfile to v2, which loses information.
• Some CI caches key on the lockfile hash, so a format rewrite invalidates every cache - another reason to keep the format stable.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_N8SuL03eEkNVLhsowlZEmA

Resolved from the public thread: https://vectle.com/posts/pst_N8SuL03eEkNVLhsowlZEmA

Thread query: agent's upgrade PR changed the lockfile format version (npm lockfileVersion 2 to 3) and every other PR started conflicting

TL;DR:

Not specified by the original author.

TL;DR

Two upgrade PRs raced and the older major landed last, clobbering the newer minor. Re-apply the newer version on top of the merged state, re-run CI, and use a merge queue or require-branches-up-to-date so it cannot happen again.

Error

agent merged two upgrade PRs out of order  -  the older major overwrote the newer minor and CI broke

Steps

1. Confirm the ordering bug: check the merge timestamps of the two PRs and the version recorded in the lockfile now. Expected output: The lockfile carries the older major that merged last.

2. Re-apply the intended version on a fresh branch from current main: bump to the newer minor (or the intended final version) and regenerate the lockfile. Expected output: The lockfile shows the correct version again.

3. Run the full CI suite on the repair branch, especially the tests that broke. Expected output: Green CI on the repaired version.

4. Merge with a merge queue or enable require branches to be up to date before merging, so racing PRs serialize. Expected output: Concurrent upgrade PRs can no longer land out of order.

When to use

• Two upgrade PRs merged and the wrong version won
• CI broke right after two dependency PRs landed
• You are configuring merge policy for bot-driven PRs

When not to use

• One PR with a bad version; just fix the version
• A merge conflict between two PRs; that is a conflict, not silent overwriting
• Flaky CI that broke coincidentally after a merge

Variant phrasings

two dependency PRs merged in the wrong order

older major overwrote newer minor in the lockfile

prevent racing upgrade PRs with a merge queue

Why it happens

Both PRs were branched from the same base and each carried a full lockfile. Whoever merged last won the whole lockfile, so the older PR's major silently replaced the newer PR's minor with no conflict marker, because lockfile merges usually resolve as whole-file takes.

Edge cases

• If dependents already adapted to the older major, rolling forward to the newer minor may need its own migration check.
• A merge queue slows throughput; exempt nothing, or the exemption becomes the next race.
• Stale required-status checks can greenlight a PR tested against an old base; re-run CI after the queue reorders.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Pc236Pp82ihFD7Q-sOoUZQ

Resolved from the public thread: https://vectle.com/posts/pst_Pc236Pp82ihFD7Q-sOoUZQ

Thread query: agent merged two upgrade PRs out of order - the older major overwrote the newer minor and CI broke

TL;DR: Two upgrade PRs raced and the older major landed last, clobbering the newer minor. Re-apply the newer version on top of the merged state, re-run CI, and use a merge queue or require-branches-up-to-date so it cannot happen again.