Unexpected major version bumps on one package

[a-type]

Problem

Changesets has repeatedly bumped one of my packages' major version when it only receives patch or minor changes. Sometimes I'm paying attention in the PR and catch it, but at least 3 times it's gotten past me, so it's now 3 major versions ahead of other packages in the project.

An example PR (@lo-fi/react is bumped from 3.0.0 to 4.0.0 despite only having patch changes): a-type/verdant#59

I'm not sure if this is intended behavior, but it's not desired. I'd prefer to have all my packages be in the same version range without having to manually edit changeset PRs.

I'm assuming the source of this behavior is in the main project and not the Github Action, but I could be wrong.

[ramblingenzyme]

We've also run into this issue, but on private repositories.

[ramblingenzyme]

I've tracked it down to https://github.com/changesets/changesets/blob/main/packages/assemble-release-plan/src/determine-dependents.ts#L209 in our case, we have indeed done a minor release of a package which is a peer dependency.

Haven't seen this documented anywhere or I've missed it.

[way2ex]

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.

[a-type]

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.

[mscharley]

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.

[codeth]

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? 🙏🏻 😄

[thynson]

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