Unexpected major version bumps on one package

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.

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

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.

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.

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.

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.

@a-type

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

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

Add a new bump strategy for peers bump, resolve changesets#1011, chan…

build: fix peerDependencies versioning oddity from changesets

chore(changeset): revert an unwanted major version that has been forc…

ci(changesets): version packages (#1427)

fix(publish-npm): resolve workspace:^ protocol before npm publish

@jdeniau

@jdeniau just to share, that flag doesn't solve the issue for me.

The direct patch is needed.

This issue is a meme at this point.

Yep, 3 years so far and such a crucial issue is still unresolved. Makes me lose trust in this project. Its core purpose is to version packages in monorepos, and so far it can't be trusted to do it correctly.

Any reason a PR has not been made and merged for said issue? If a patch exists, surely there can't be much more to complete this?

Manually fix package versions to avoid major version bump

docs(releasekit): adopt release-please model (#4575)

Fixed this locally with a bun patch - example commit here in case its helpful -- dmno-dev/varlock@6098aa6

Avoid changesets/changesets#1011

fix changeset release to avoid bump package to 1.x when peer dependen…

chore(release): align all @comvi/* packages to v0.2.0 (#14)

feat(demo): WONIK Fab Monitor 데모 + 1차 polish 사이클 (#16)

chore(storybook): Ladle 카탈로그를 Storybook 10으로 교체 (#17)

docs(releasekit): adopt release-please model (#4575)

Navigation Menu

Repository navigation

Unexpected major version bumps on one package #1011

Problem

49 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Unexpected major version bumps on one package #1011

Description

Problem

Activity

ramblingenzyme commented on Jan 3, 2023

ramblingenzyme commented on Jan 3, 2023

way2ex commented on Jan 20, 2023

a-type commented on Jan 20, 2023

mscharley commented on Mar 22, 2023

codeth commented on Mar 28, 2023

thynson commented on Apr 7, 2023

49 remaining items

unional commented on Dec 3, 2025

wottpal commented on Dec 3, 2025

sebastian-nowak commented on Dec 12, 2025

JohnValanidas commented on Dec 18, 2025

theoephraim commented on Feb 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions