Version Bump not as expected

Affected Packages

https://github.com/willin/svelte-turbo/pull/6/files#diff-aeb150d43a6f0eb9d74a267d7e064ab7ec0e40a93adbbdf8c9020814cf011917

Problem

---
'@svelte-dev/session': minor
'@svelte-dev/auth': minor
'@svelte-dev/auth-oauth2': patch
---

feat: :tada: add auth handler

but in the pr: willin/svelte-turbo#6

it comes to major

Proposed solution

no idea... just want version bump to expected value

I think I'm having the issue you described. However, when I went to the PR I didn't see any major

I am experiencing the same thing.. a package went from 0.4 to 2.0 to 7.0 with minor bump 😅

I did some debugging.

there exists a function, shouldBumpMajor. this is causing my minor release to be promoted to a major against expectation
it happens due to some sort of peerDependency check logic, which candidly, doesn't seem correct to me at all, especially that my peer is using workspace: syntax and all deps are linked. will report more.

Looks like the logic that put this in place is ~4 years old. #412

The issue that we are experiencing also seem to be caused by peer dependencies. Our current fix is to add to our config:

{
  "___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH": {
    "onlyUpdatePeerDependentsWhenOutOfRange": true
  }
}

Which seems to work, but not ideal.

The issue that we are experiencing also seem to be caused by peer dependencies. Our current fix is to add to our config:
{
  "___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH": {
    "onlyUpdatePeerDependentsWhenOutOfRange": true
  }
}
Which seems to work, but not ideal.

This has helped me, thanks for the tip!

For anyone else that stumbles on this: I had, however, to replace the semver range of my peer dep for this to work. I had it like workspace:^ (using yarn@v4), which failed the semverSatisfies check from here. Changing it to workspace:^1 (adding the major range) made it work.

We've had it the hard way, two major versions are published because of this.

We have always enabled onlyUpdatePeerDependentsWhenOutOfRange but the PR still did major pumps.

changesets/action#381

fix: revert incorrect major pumps changesets/changesets#1279

I have the same issue: patching a dependency in a monorepo causes other packages that depend on the updated package to be major bumped.

It's a huge issue and it amazes me that a PR that adressess this is still in review for over a year 👎

I just ran into it too. Updated dependency added a Patch level change in the changelog, but the package version got a major bump. Whaaaat 🤯

I have the same issue. @changesets/cli version 2.27.9

Navigation Menu

Repository navigation

Version Bump not as expected #1279

Affected Packages

Problem

Proposed solution

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Version Bump not as expected #1279

Description

Affected Packages

Problem

Proposed solution

Activity

benmvp commented on Jan 18, 2024

patricklafrance commented on Jan 30, 2024

cdaringe commented on Feb 7, 2024

cdaringe commented on Feb 7, 2024

patricklafrance commented on Feb 8, 2024

kaisermann commented on Feb 29, 2024

vicary commented on Jul 19, 2024

DenisFrezzato commented on Aug 21, 2024

sebastian-nowak commented on Nov 24, 2024

sebastian-nowak commented on Jun 3, 2025

pepsikat commented on Jun 24, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions