Use exact or ~ deps version in stable releases package.json

[CPatchane]

🤓 Question

As I can read here, we use to put the exact versions of react-spring dependencies in package.json for beta/canary versions but not for stable releases. Is there a particular reason?
The thing is that not fixing the versions in stable releases make them unusable in the future, if a user doesn't want to use the very last stable release and also breaks lockfile maintenance pushed by some dependencies maintaining bots automatically.

My example

I use the v9.0.0 version and the lockfile maintenance is breaking because it installs the v9.1.0 dependencies in my lockfile even if I fixed the v9.0.0 version of react-spring in my package.json (which is normal since this is about sub-dependencies here).

Proposal

Since you pushed a potential breaking change in 9.1.0 (it seems to break on my side), it shouldn't be pushed automatically to users. But you may want to push patch automatically for security fixes? I would suggest you to use ~ instead of ^ (see npm docs).
In that case it would push automatically versions like 9.0.1 or 9.0.5 because there are just patches but wouldn't for 9.1.0 since there is a minor risk of breaking changes.

What do you think? I can help to do a PR if needed (is it only related to prepare.js file?)

Current workaround

The workaround to fix this on the user side, which is clearly not ideal, is to pin the versions in the package.json resolutions like:

 "resolutions": {
    "@react-spring/animated": "9.0.0",
    "@react-spring/core": "9.0.0",
    "@react-spring/konva": "9.0.0",
    "@react-spring/native": "9.0.0",
    "@react-spring/shared": "9.0.0",
    "@react-spring/three": "9.0.0",
    "@react-spring/web": "9.0.0",
    "@react-spring/zdog": "9.0.0"
}

[joshuaellis]

As I can read here, we use to put the exact versions of react-spring dependencies in package.json for beta/canary versions but not for stable releases. Is there a particular reason?

I have no idea why, I didn't create the prepare script and the maintainer who did no longer works on the project.

Oh I see, so when we're building the bundle it replaces link with ^VERSION. So in the case of installing 9.0.0 of @react-spring/web it'll try to download 9.1.0 for the modules it's dependant on? Am I understanding this correctly?

[CPatchane]

Oh I see, so when we're building the bundle it replaces link with ^VERSION. So in the case of installing 9.0.0 of @react-spring/web it'll try to download 9.1.0 for the modules it's dependant on? Am I understanding this correctly?

Yes, this is when you install react-spring itself. You install react-spring v9.0.0, it will install its dependencies like @react-spring/web with ^9.0.0 which telling it to install 9.0.0 or any minor version above or any patch above. So it will install 9.1.0 of @react-spring/web here.
If you use a ~ like ~9.0.0, it will have the same logic but only for patches above the provided version, which seems more appropriate here imho. (in our case here, it will stick to 9.0.0).

[joshuaellis]

I agree @CPatchane that this is definitely more approriate, whilst we're trying to avoid breaking changes the library does need some love and situations like 9.1.0 where i've documented potential breaking change can happen again.

I also 100% appreciate how annoying that can be! If you can submit a PR to amend prepare that'd be very helpful and would get the issue resolved faster.

[CPatchane]

Done here #1416

[joshuaellis]

I've release v9.0.1 the only change from v9 is that we've included your PR to stop unwanted upgrades. There's a changelog for it too.

[CPatchane]

Thanks!

[sesam]

I get that this might be the simplest way to hide a breaking change without bumping the major version. But maybe retracting the breaking change (releasing a new version where it's reverted) and then releasing a new major version with the breaking change might still be the Right Way to do this.