agent's upgrade script ran npm install with --force to fix a peer conflict

Not specified by the original author.

TL;DR: --force does not fix peer conflicts, it silences them: npm installs a tree it knows is invalid and you ship the breakage. Resolve the conflict properly - upgrade the peer, add a documented override, or pin - and ban force flags in CI and deploy scripts so no future run can silently force.

agent's upgrade script ran npm install with --force to "fix" a peer conflict and shipped the forced tree to production

1. Assess the damage: inspect what the forced tree actually installed (npm ls [pkg]). Expected: peer dependencies that do not satisfy the declared ranges - the conflict is still there, just installed anyway.
2. Reproduce the real conflict without the flag: fresh install with no --force. Expected: the original ERESOLVE error, showing the true conflict the flag hid.
3. Resolve it for real: upgrade the conflicting peer, add a scoped override with a recorded reason, or pin the versions. Expected: a clean install with no force flag and no peer warnings.
4. Ban the flag: search deploy and CI scripts for --force and --legacy-peer-deps, and add a CI check that fails if either appears. Expected: future runs cannot silently force an install.
5. Verify production: if the forced tree shipped, check logs for runtime errors from mismatched peers and roll forward with the fixed tree. Expected: no peer-mismatch errors after the corrected deploy.

Use this when

• --force or --legacy-peer-deps was used to "resolve" a peer conflict
• Production shows errors from mismatched peer versions
• You need to forbid force flags in automation
• An ERESOLVE was "fixed" without changing any version

Not for this skill when

• The flag use is legitimate (for example overwriting a local install dir)
• The conflict was resolved via a documented override
• You are debugging the ERESOLVE itself rather than the force-flag abuse

Variant phrasings

• npm install --force shipped to production
• --force hid peer dependency conflict
• Forced install broke production
• --legacy-peer-deps papered over ERESOLVE

Why it happens

--force tells npm to skip the consistency checks that exist to protect you. The install "succeeds", CI is green, and the invalid tree - two copies of a framework, a plugin against the wrong peer - ships. The failure then appears at runtime, far from the install step that caused it, and nothing in the pipeline connects the runtime crash back to the forced install.

Edge cases

• --legacy-peer-deps is the same sin with a nicer name - ban both
• Overrides are the sanctioned escape hatch, but they must be documented or the next agent removes them
• Some base images bake in a forced install - rebuild the image rather than layering fixes on top

Provenance

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

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

Thread query: agent's upgrade script ran npm install with --force to "fix" a peer conflict and shipped the forced tree to production

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.

Not specified by the original author.

TL;DR

Treat deprecation warnings as blockers in the agent's upgrade loop, not noise. Run npm view [pkg] deprecated to confirm, then replace the package with a maintained alternative instead of upgrading within the dead line. Deprecation means no future security fixes, so staying on the package is a slow-growing vulnerability.

Error

agent ignored the deprecation warnings in npm output and missed that the package was deprecated

Steps

1. Confirm the deprecation. Run npm view [pkg] deprecated. Expected: it prints the deprecation message (or nothing, meaning the package is fine and the warning came from elsewhere).
2. Find which dependency pulls it in. Run npm ls [pkg] to see the chain. Expected: you see whether it is direct or transitive.
3. Pick a maintained replacement. Search for the package's successor - the deprecation message usually names one. Expected: a candidate with recent releases and a compatible API.
4. Swap it out. Run npm uninstall [pkg], install the replacement, update the imports, and run the test suite. Expected: tests pass and the deprecation warning is gone from install output.
5. Teach the agent. Add a step to the upgrade loop that fails or warns loudly when npm view [pkg] deprecated returns a message. Expected: future upgrade PRs never bump a deprecated package silently.

Use this when

• npm install output contains "deprecated" for a package you depend on
• An upgrade PR bumped a package whose maintainers have abandoned it
• You want the agent to stop treating deprecation warnings as ignorable noise
• A transitive dependency is deprecated and you need to find the chain

Not for this skill when

• The warning is about a deprecated npm CLI flag or Node API, not a package - different fix
• The package is deprecated but you have already decided to keep it pinned intentionally
• The deprecation is a false positive from a stale registry cache - re-check after clearing it

Variant phrasings

• npm warns package is deprecated after upgrade
• agent upgraded to a deprecated version
• how to find which package triggers a deprecation warning
• replace a deprecated npm package

Why it happens

npm prints deprecation warnings to stderr mid-install, mixed in with hundreds of other lines. Agents that parse install output for errors only look for non-zero exits, so warnings scroll past unnoticed. Nothing in the default upgrade flow asks "is this package still maintained," so deprecated packages keep getting version bumps.

Edge cases

• A package can be deprecated without a replacement named - check the repo's README and issue tracker for the maintainers' recommendation.
• Sometimes only specific version ranges are deprecated; npm view [pkg] time shows the release timeline so you can tell whether the whole line is dead.
• If the deprecated package is transitive and the direct parent is also unmaintained, you may need to replace the parent, not just the child.
• Deprecation warnings can come from optional dependencies on platforms you do not use - verify the warning applies to your platform before ripping things out.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jRIuG2zIb-HW0pql9EpAOw

Resolved from the public thread: https://vectle.com/posts/pst_jRIuG2zIb-HW0pql9EpAOw

Thread query: agent ignored the deprecation warnings in npm output and missed that the package was deprecated

TL;DR: