agent resolved a yarn.lock conflict by picking ours for everything and silently downgraded three packages

Not specified by the original author.

TL;DR: Redo the merge properly: take the merged package.json and regenerate yarn.lock from it, then verify no versions went backwards. Resolving a lockfile conflict with "ours" keeps your file byte-identical but silently drops the other side's upgrades. Never resolve a lockfile with ours/theirs; always re-resolve.

agent resolved a yarn.lock conflict by picking "ours" for everything and silently downgraded three packages

1. Diff the current yarn.lock against the pre-merge state and list every version that went down. Expected: the silent downgrades are named explicitly, with before and after versions.

2. Redo the conflict: check out the merged package.json, then run a fresh install to regenerate the lockfile. Expected: the lockfile reflects both sides' intended versions, not just one side's.

3. Verify the regenerated lockfile: every package at or above its intended version, no unexplained downgrades. Expected: a clean diff showing only real, intended changes.

4. Add a CI check comparing lockfile versions before and after merge, failing on unexplained downgrades. Expected: the next bad resolution gets caught automatically instead of shipping silently.

Use this when

• A yarn.lock conflict was resolved by picking "ours" (or "theirs") for everything
• Lockfile versions moved backwards after a merge
• Upgrades from one side of a merge went missing with no trace
• "Silently downgraded" packages after a conflict resolution

Not for this skill when

• The downgrades were intentional and reviewed
• The conflict is in package.json rather than the lockfile
• The lockfile is package-lock.json or pnpm-lock.yaml (same principle, different regen command)

Variant phrasings

• yarn.lock resolved with ours, packages downgraded
• lockfile conflict resolved to the wrong side
• silent downgrade after a merge
• yarn install needed after a conflict

Why it happens

"Ours" feels safe because it keeps a known-good file, but a lockfile encodes the other branch's upgrade decisions too. Keeping yours discards theirs without a trace, and nothing in the merge output flags the downgrade. The merge succeeded; the dependency set quietly regressed.

Edge cases

• If the bad merge already shipped, cut a follow-up PR that re-applies the dropped upgrades rather than rewriting history.
• The regen for the merged manifest can resolve differently from both sides; review the full diff, not just the conflicted hunks.
• In a monorepo, make sure the regen covers all workspaces so a sibling package does not keep the stale resolution.

Provenance

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

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

Thread query: agent resolved a yarn.lock conflict by picking "ours" for everything and silently downgraded three packages

TL;DR:

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

Stop the agent from bumping packages one at a time. Solve the whole dependency graph in a single constraint pass, cap the agent at 3 resolve attempts, and treat a version flipping back to a value it already had as a loop to escalate, not a state to resolve again. Circular loops come from greedy sequential bumps; a joint solve fixes them in one shot.

The query

renovate agent got stuck in a loop: bumped lodash, which required bumping webpack, which required bumping lodash again

Use this when

• The agent's version history shows the same package bouncing between two versions
• An upgrade PR keeps getting force-pushed with "fix constraints" commits
• CI fails on a different package each iteration of the loop
• The agent has burned hours of compute re-running the resolver

Not for

• A peer-dependency conflict inside a single install
• Lockfile merge conflicts from rebasing
• Registry 429s or timeouts during verification
• A genuinely unresolvable dependency set (nothing satisfies all constraints)

Steps

1. Log every bump the agent made

List the package, the from-version, and the to-version for each attempt, in order. You need this to see the oscillation.

Expected output: a short list like lodash 4.17.20 -> 4.17.21 -> 4.17.20, showing the same version repeating.

2. Write down the full constraint set on paper

For each package the agent touched, write the constraint its dependents actually declare: webpack 5.x requires lodash 4.17.21 or later and plugin-x requires lodash below 4.17.21 or whatever the real declarations are. Read them from package.json files and lockfiles, not from the agent's summary.

Expected output: every constraint for the bumped packages listed with the package that declares it.

3. Solve all of it in one pass

Run the package manager's resolver once against the full set, e.g. npm install --package-lock-only after pinning the target versions, or hand the constraint set to the Renovate/Dependabot config and let it propose one PR. No sequential single-package bumps.

Expected output: one resolved lockfile, or one clear "no solution" error naming the conflicting constraints.

4. Cap attempts and detect oscillation

Give the agent a hard limit: 3 resolve attempts per upgrade task. Keep a set of versions already tried per package; if a bump targets a version already in the set, stop and escalate.

Expected output: the agent halts after 3 attempts with a summary instead of looping indefinitely.

5. Escalate with the conflict named

The escalation message must name the two constraints that cannot both be satisfied, e.g. "webpack needs lodash>=4.17.21, but plugin-x caps lodash<4.17.21. Human needed."

Expected output: a review request or issue naming the conflicting pair, not a 47th bump attempt.

Variant phrasings

renovate automerge flip-flopping two PRs

Same fix. The oscillation detector in step 4 works across PRs: record attempted version pairs per package pair, not just per package.

dependabot PR loop react 19 vs design system

Same fix, with an extra rule: never downgrade a package below a version another package in the same PR set requires. Check the constraint set first (step 2).

circular pip upgrade every resolve unpins a different package

Same fix. pip install with all targets in one command lets the resolver see the full picture instead of chasing one conflict at a time.

Why it happens

The agent bumps greedily: upgrade A, run the resolver, see B complain, upgrade B, see A complain. Each step is locally reasonable and globally a loop. Nothing in the agent's config tracks which versions it already tried, so it can revisit the same state forever. A joint solve breaks the pattern because the resolver sees every constraint at once.

Edge cases

• Genuinely unresolvable sets: if the joint solve says no solution exists, that is the answer. Do not let the agent "try one more combo."
• Calver packages: an agent that treats calver as semver will pick wrong targets and loop forever. Check the versioning scheme before bumping.
• Peer dependencies: npm's peer resolution can force oscillation even with a joint solve. Pin the peer pair explicitly in step 3.
• Time-boxed agents: if the agent has a wall-clock limit, the loop eats it silently. Add the attempt cap in step 4 regardless of time budget.

Provenance

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

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

Thread query: renovate agent got stuck in a loop: bumped lodash, which required bumping webpack, which required bumping lodash again

TL;DR: Stop the agent from bumping packages one at a time. Solve the whole dependency graph in a single constraint pass, cap the agent at 3 resolve attempts, and treat a version flipping back to a value it already had as a loop to escalate, not a state to resolve again. Circular loops come from greedy sequential bumps; a joint solve fixes them in one shot.