Skip to content

UpgradeDependencyVersion: warn on install failure instead of throwing#7479

Merged
Jenson3210 merged 1 commit intomainfrom
Jenson3210/upgrade-dependency-soft-fail
Apr 27, 2026
Merged

UpgradeDependencyVersion: warn on install failure instead of throwing#7479
Jenson3210 merged 1 commit intomainfrom
Jenson3210/upgrade-dependency-soft-fail

Conversation

@Jenson3210
Copy link
Copy Markdown
Contributor

Summary

When the package-manager install run by UpgradeDependencyVersion fails (typically an ERESOLVE peer-dep conflict), the recipe currently throws, aborting the entire recipe chain. That prevents later recipes — which might be the very ones that resolve the conflict, e.g. by bumping a peer-pinning library — from running at all.

The sibling AddDependency recipe already handles install failure by returning markupWarn(doc, ...) and letting the chain continue. This PR aligns the two so partial failures degrade gracefully.

Motivation

Real-world trigger: an Angular 17 project with @ng-bootstrap/ng-bootstrap@^16.0.0 (strict peer @angular/core@^17.0.0) being upgraded via a chain of UpgradeDependencyVersion calls (one for @angular/*, one for @ng-bootstrap/ng-bootstrap). Today the first failing install kills the run, and the dep graph stays in its initial inconsistent state forever. With this change, the chain continues, the marker records the failure, and a subsequent recipe can converge the graph (or a second pass of the same chain reaches fixed-point).

Diff

- import {replaceMarkerByKind} from "../../markers";
+ import {markupWarn, replaceMarkerByKind} from "../../markers";
…
  if (failureMessage) {
      const names = updateInfo.matchedDependencies.map(d => d.packageName).join(', ');
-     throw new Error(`Failed to upgrade ${names} to ${recipe.newVersion}: ${failureMessage}`);
+     return markupWarn(doc, `Failed to upgrade ${names} to ${recipe.newVersion}`, failureMessage);
  }

Tests

The two existing tests that asserted on the throw — throws when install fails for non-existent version and throws when install fails due to engine version mismatch — are reworked to assert on the MarkupWarn marker, mirroring the pattern in add-dependency.test.ts::adds warning marker when package does not exist. Renamed to adds warning marker when install fails … to match the new behaviour.

All 25 tests in upgrade-dependency-version.test.ts pass locally.

Test plan

  • npm run typecheck clean
  • npx vitest run test/javascript/recipes/upgrade-dependency-version.test.ts — 25/25 pass
  • Run full suite in CI
  • Verify the unblocked-recipe-chain behaviour against a known-failing project (Angular 17 + ng-bootstrap@16 → 18 + ng-bootstrap@17)

When the package-manager install run by `UpgradeDependencyVersion` fails
(typically an `ERESOLVE` peer-dep conflict), the recipe currently throws,
which aborts the entire recipe chain. That prevents later recipes — which
might be the very ones that resolve the conflict, e.g. by bumping a
peer-pinning library — from running at all.

The sibling `AddDependency` recipe already handles install failure by
returning `markupWarn(doc, ...)` and letting the chain continue. Align
the two so partial failures degrade gracefully and downstream recipes
have a chance to converge the dependency graph.

Real-world trigger: an Angular 17 project with `ng-bootstrap@16` (peer
`@angular/core@^17`) bumped via a chain of `UpgradeDependencyVersion`
calls. Today the first failed install kills the run; with this change,
the chain continues, the marker records the failure, and a later
`UpgradeDependencyVersion` for the conflicting peer can succeed.

Tests: the two existing tests that asserted on the throw are reworked
to assert on the `MarkupWarn` marker instead, mirroring the pattern in
`add-dependency.test.ts::adds warning marker when package does not exist`.
@Jenson3210 Jenson3210 merged commit 00226af into main Apr 27, 2026
2 checks passed
@Jenson3210 Jenson3210 deleted the Jenson3210/upgrade-dependency-soft-fail branch April 27, 2026 17:14
@github-project-automation github-project-automation Bot moved this from Ready to Review to Done in OpenRewrite Apr 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

2 participants