change peer dependent bump type to patch - #2090

🦋 Changeset detected

Latest commit: b532e10

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Codecov Report

❌ Patch coverage is 93.33333% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 85.34%. Comparing base (813bbf3) to head (b532e10).

@@            Coverage Diff             @@
##             main    #2090      +/-   ##
==========================================
- Coverage   85.47%   85.34%   -0.13%     
==========================================
  Files          66       66              
  Lines        2547     2545       -2     
  Branches      704      697       -7     
==========================================
- Hits         2177     2172       -5     
- Misses        340      343       +3     
  Partials       30       30              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

we can also remove the onlyUpdatePeerDependentsWhenOutOfRange option

me trying to do that is part of why this took so long, we actually can't because it technically has a different effect than this.

it really is just a duplication (+inversion) of the updateInternalDependencies option, specifically for peer dependencies.
it's not really about how the peer dependents should be bumped alongside their dependency, but rather whether the version ranges should be updated to match the new versions.

so we need to keep it for now, and maybe hopefully merge it into updateInternalDependencies or some other new option

Nice to see this finally land! The always major behavior was easily the most-cited papercut.

Sharing some prior art in case it's useful for a future iteration: I've been building a changesets successor (bumpy) and this exact problem was the first thing I dug into. Landed somewhere a bit different and figured the reasoning might be worth a data point.

Two axes turned out to matter independently:

1. When to bump the peer dependent. bumpy only bumps it when the new version actually falls out of the dependent's declared range. A caret range absorbing an in-range minor bump produces no release at all -- which kills a lot of the churn people complain about, before you even get to "what level."

2. What level to bump it to. Instead of a fixed constant, the default matches the triggering bump (major→major, minor→minor, patch→patch) and only fires when the new version actually leaves the dependent's declared range. The thinking: the out-of-range case is precisely when the dependent's contract genuinely changed -- if core goes 1→2, a consumer can no longer pair the dependent with core 1.x, which is breaking for the dependent too. A flat patch there leans on the maintainer to remember to hand-write a major changeset; if they forget, you publish a patch that silently requires a new major peer.

That said patch-by-default is a totally reasonable call, and I don't think there's a single correct constant. match is still a heuristic and can over-bump (core can go major for reasons that never touch what the dependent re-exposes). Which is really the bigger point: rather than hardcode any constant, bumpy makes both the trigger threshold and the resulting level configurable per-package or globally:

{
  // proactive mode — opt-in; default is range-gated "match"
  "updateInternalDependencies": "patch",
  "dependencyBumpRules": {
    "peerDependencies": { "trigger": "patch", "bumpAs": "patch" }, // equivalent to this PR
  }
}

So a team that wants the old always-major, the new always-patch, or proportional can all get it, and override it for the one package that's special. That configurability is what a bunch of the closed issues here were actually asking for (#827, #1228), beyond just "stop defaulting to major."

Writeup with the full propagation algorithm is here if it's useful. Not trying to pitch, just figured the design space exploration might save you some cycles. Happy to go deeper on any of it.

thank you for the thoughtful comment!

you're right that this doesn't properly address some of the closed issues, but this change acts as temporary improvement for v3 as we don't want to delay its release any more than necessary.

we will discuss how to improve this further for v3.1 or v4 in a new issue, and will make sure to bring the feedback from the closed ones into it