Preserve bounds when updating dependency ranges - #2297

🦋 Changeset detected

Latest commit: 1256f95

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

✅ Deploy Preview for changesets ready!

Name	Link
🔨 Latest commit	1256f95
🔍 Latest deploy log	https://app.netlify.com/projects/changesets/deploys/6aa6cbc76cc42400088ef9e3
😎 Deploy Preview	https://deploy-preview-2297--changesets.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.77%. Comparing base (5e54cd9) to head (1256f95).
⚠️ Report is 3 commits behind head on main.

@@            Coverage Diff             @@
##             main    #2297      +/-   ##
==========================================
+ Coverage   84.57%   86.77%   +2.19%     
==========================================
  Files          80       78       -2     
  Lines        3177     2956     -221     
  Branches      896      841      -55     
==========================================
- Hits         2687     2565     -122     
+ Misses        433      347      -86     
+ Partials       57       44      -13     

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

while i do agree that we shouldn't break the ranges, i'm not sure updating them is the best solution...

i think that when somone defines a complex range like this it is for a specific reason, e.g. supporting all except the latest major versions, so it getting changed would probably not be desired

maybe we should just warn that we saw a complex version range and that they should review and update it themselves? if it would be too invisible in the version command we could show it somewhere in changeset add

I think it's OK to infer probable intent for simple ranges like this one here. But the general problem ofc stays unsolved by this PR - so I agree that further warnings etc for more complex scenarios would be good to add

The baseline is that we establish a dependency between a package and its dependent - so it's implied the current package should be in its range (lower bound should really accept it). The upper bound is usually just forward-looking in some sense. Because u can't really know what you are going to release in a few months. But we need to preserve the intention and not drop it. It gets iffy when we end up having to change that upper bound... but then we just infer a sensible behavior

Such ranges make way more sense for packages outside of the user's control - and especially for already published versions of packages (and not for versions that might get released in the future)

Such ranges make way more sense for packages outside of the user's control

that makes sense, this is internal packages only. 😄