changesets: Unexpected major version bumps on one package

I think we need a config options to control this behavior, just leave the decision to the end user.

This is also important to us because we wanted to use peer dependencies between monorepo packages but everything gets major bumped all the time

Hey everyone, just sponsored the changeset organization with $400 for the great work they’re doing! … And also with the hope of allocating some resources to get this annoying issue resolved. 😊 cc @emmatown @Andarist

Seems like it’s more the package manager’s job to warn you if a peer dependency has moved out of range. I use pnpm and it’s very aggressive about this already.

For context I have a core package, @lo-fi/web, and an associated React hooks package, @lo-fi/react, which lists @lo-fi/web as peer dependency - because it requires web to function, but isn’t very opinionated about exact versions and I don’t want it to have a separate copy of the library, it absolutely has to be the same one used directly the code. I could be mistaken, but I believe that’s the point of peerDependencies.

What’s annoying is that now if I update certain things in certain ways, my React package is major bumped, so its version is now wildly out of step with the rest of the package ecosystem it’s a part of.

Might be a good behavior to make optional.

We’ve also run into this issue after implementing changesets (which we love!) but this behaviour seems counter-intuitive and is a point of frustration. Exactly the same situation as @a-type described. We have a design system monorepo with linked dependencies. The core package is a peer dep on the React package, and a minor bump to the core package is causing changesets to apply a major bump to both.

Bumping to a major version feels like it is sending the wrong message and not honouring semver. We haven’t hit v1 yet so don’t want to major bump a feature addition, we want to do a minor bump but currently will have to stick to patch or rework our setup to use fixed versions instead of linked, which would be a shame.

It’s not at all obvious that this would happen just because of peerDependencies, and seems a bit buried in the docs. I’d be massively in favour of this behaviour being made optional via the changesets config. Please? 🙏🏻 😄

Hi, is there any update on this? My packages now even have a higher version than Angular 🥹

Can I opt out from this behavior? I’ve just setup changesets in my project, but this is a deal breaker. If I can’t opt out, I’ll have to rollback 😦

It can be opt out if #1132 got merged.

Regular old npm has also become much stricter about this over the last year or so, following a lot of the leads that pnpm started. I would definitely also like to see this behaviour at least be optional as it’s breaking things for us too. We effectively can’t do minor releases to our monorepo using fixed to keep all the versions in sync because any minor update cause a peer dependency to change, which triggers a major update and then the whole monorepo gets dragged up to a major version bump as well.

someone did solve it? Fome me I’m going to edit .changest/random-file changeing major with what i want each time

Hi any plans to release this soon?

I have also run int this issue and i found that it occurs only when one of peerDependencies has a minor version change. When I delete the dependency from peerDependencies, it’s ok.

I have found the docs here.

Currently, if you list a package as a peerDependency of another package, this causes the package with the peerDependency to be released as a major change. This is because peerDependency changes will not be caught by a package installation. This decision is open for discussion.