Add an option to avoid major bump when peerDeep has changed

Problem

We have a monorepo https://github.com/wundergraph/wundergraph. We developed a package for our SDK @wundergraph/nextjs. The package has the SDK as peerDependency. After patching the SDK, the package is major bumped. We don't want this. This change was not communicated through a changeset. I think this defeats the purpose of a changeset.

Docs: https://github.com/changesets/changesets/blob/c68536edf4c04e7fdf5594ec9c69471cd86fd0ce/docs/decisions.md#the-versioning-of-peer-dependencies

Proposed solution

Provide an option to disable this behavior and make this part of the changeset.

Is this what you are looking for? https://github.com/statelyai/xstate/blob/c967791c82756b8c743c70a4a0b66b2e9e1d7d41/.changeset/config.json#L10

@Andarist

Hi @Andarist, good timing, I am trying right now 😄

We have a similar issue in our repo. In our case we do want to do a release of all dependant packages but not a major. We tried setting this in the config:

  "___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH": {
    "onlyUpdatePeerDependentsWhenOutOfRange": true,
    "updateInternalDependents": "always"
  }

And with this config it creates a patch release for all dependant packages but the changelog is empty:

# @cmpsr/nextjs-contentful-renderer

## 4.0.1
                         <--- Missing changelog
## 4.0.0

### Minor Changes

- c657ab3: feat: expose @cmpsr/blocks to MdxRenderer

I think it would be nice to be able to configure the release type for dependant packages. I can work on it if this is something you are interested on.

Could you list everything that is involved in a release, like package names, their current versions, dependency ranges, their types etc and the same for the expected result? It would be easier for me to reason about it this way.

@tkanzakic

Hi, @tkanzakic could you open a different issue? I see it as two separate issues. My concern is that every change is listed in the changeset and we should have a flag to disable the peerDep behavior entirely.

@StarpTech

@StarpTech let me know if onlyUpdatePeerDependentsWhenOutOfRange satisfies your requirements or if you are still looking for something subtly different.

@Andarist

@Andarist it works but it is error-prone because we can't see the change upfront in the changeset.

Could you elaborate? What is your expected result?

Expected

Add changeset pnpm changeset
A changelog entry for the package with the peer dependency was added.
Commit all changes

Actual

Add changeset pnpm changeset
No changelog entry was added that communicates that the package with the peer dep is bumped to major

@tkanzakic

Hi, @tkanzakic could you open a different issue? I see it as two separate issues. My concern is that every change is listed in the changeset and we should have a flag to disable the peerDep behavior entirely.

@StarpTech from the title of the issue I understand that your issue was avoiding doing a major bump in the peers, which is what we are trying to do, sorry for the misunderstanding. I will open a new issue.

You're right but you claim about an empty changelog, right?

For what it's worth, I had a similar issue and onlyUpdatePeerDependentsWhenOutOfRange fixed my problem.

We have two packages, let's call them "x" and "x-integration-tests". We use fixed to publish them at identical version numbers. x-integration-tests has a peer dep on x.

It looks like if we add a minor bump to x, it ends up getting translated into a major bump on both packages.

onlyUpdatePeerDependentsWhenOutOfRange only sort of helps: it keeps the packages at minor bumps, but it doesn't actually update the peer dependency between the packages, and we really do want the package versions to match so that people are using the matching version of the tests in their test suites.

See apollographql/apollo-server@950fd1b for a real example.

updateInternalDependents appears to not make a difference here.

Note that even with:

  "___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH": {
    "onlyUpdatePeerDependentsWhenOutOfRange": true,
    "updateInternalDependents": "always"
  }

When I add a minor change, it still did a major bump (@changesets/[email protected]).

I recall there is a comment about that somewhere, but can't find it. So add it here again for record.

Full config:

{
  "$schema": "https://unpkg.com/@changesets/[email protected]/schema.json",
  "___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH": {
    "onlyUpdatePeerDependentsWhenOutOfRange": true,
    "updateInternalDependents": "always"
  },
  "access": "public",
  "baseBranch": "main",
  "changelog": "@changesets/cli/changelog",
  "commit": false,
  "fixed": [
    [
      "@just-web/app",
      "@just-web/browser-keyboard",
      "@just-web/browser-preferences",
      "@just-web/browser",
      "@just-web/commands",
      "@just-web/events",
      "@just-web/keyboard",
      "@just-web/log",
      "@just-web/os",
      "@just-web/preferences",
      "@just-web/routes",
      "@just-web/states",
      "@just-web/types"
    ]
  ],
  "ignore": [],
  "linked": [],
  "title": "chore: version packages",
  "updateInternalDependencies": "patch"
}

https://github.com/justland/just-web/blob/main/.changeset/config.json

Within the docs one can read:

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.

At least for npm 7+ this no longer the default behaviour and will throw an exception during the installation of a package whose peerDependencies are no longer matched.

Additionally, from what I can see, the onlyUpdatePeerDependentsWhenOutOfRange experimental flag is potentially prejudicial. Maintainers may be coupled to some recent addition in a monorepo dev dependency but by not mimicking the same range bump in a peer dependency consumers may incorrectly be using an incompatible version.

WDYT about exposing some flag that bumps peerDependencies and dependencies the same way?

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

fix major/patch version bumping

[Changesets] Versioned release (#279)

fix: block major version bumps in changeset version pipeline

This issue (and many more) caused me to recently build https://bumpy.varlock.dev - give it a try 🐸

we will also look into this for v4, we're focusing on finishing the clean up efforts in v3 first though!

This issue (and many more) caused me to recently build https://bumpy.varlock.dev - give it a try 🐸

looks super cool and dope name 🔥 thanks for sharing!

I think this is a good v3 candidate too, it’s a small change to make - but a breaking one. So we can push this quickly

it is the most requested change for the project, so it would close a lot of issues :^)

fix: widen @real-router/core peer range to workspace:>=0.1.0 (changes…

chore(config): delete cap-major-bumps.mjs, changesets 3 removed its c…

Navigation Menu

Repository navigation

Add an option to avoid major bump when peerDeep has changed #822

Problem

Proposed solution

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add an option to avoid major bump when peerDeep has changed #822

Description

Problem

Proposed solution

Activity

Andarist commented on May 30, 2022

StarpTech commented on May 30, 2022

tkanzakic commented on Jun 1, 2022

Andarist commented on Jun 1, 2022

StarpTech commented on Jun 1, 2022

Andarist commented on Jun 1, 2022

StarpTech commented on Jun 1, 2022

Andarist commented on Jun 1, 2022

StarpTech commented on Jun 1, 2022

tkanzakic commented on Jun 1, 2022

StarpTech commented on Jun 1, 2022

calebdwilliams commented on Sep 7, 2022

glasser commented on Oct 31, 2022

unional commented on Nov 20, 2022

miguel-silva commented on Dec 7, 2022

3 remaining items

theoephraim commented on May 6, 2026

beeequeue commented on May 6, 2026

wottpal commented on May 6, 2026

Andarist commented on May 6, 2026

beeequeue commented on May 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions