🦋 Changeset detected

Latest commit: 10c5a06

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 01c10ae:

Thank you very much for your PR! I will review this thoroughly after the weekend.

"what to do with the peer-dependent version" and a different setting for what to do about the peer-dependent's dependency range.

I'm not clear if you were asking what to do when peers' bump exceeds the dependent's range.
If it is what you concern about, my thought to this question is still to follow the bump type of peer, despite if the dependent pinned the peer, or restricted the version of peers by tilde or caret, as long as we preserve the range type of peer dependencies after the bump.
For example, if pinned-peer has a major bump, the dependent shall have a major bump too, and update the specifier from pinned-peer@1.0.1 to pinned-peer@2.0.0.

My current thought about shape of config:

• updatePeerDependencies: "patch" | "minor": The minimum bump type to trigger automatic update of peer dependencies that are part of the same release. This is consisted with updateInternalDependencies.
• bumpStrategyForPeerUpdate: "major" | "follow": The strategy used to trigger automatic update of peer dependencies that are part of the same release, "follow" means if a peer dependency has a major/minor/patch bumps, this package will have a major/minor/patch bump at minimum, respectively.

When bumpStrategyForPeerUpdate set to follow, with different updatePeerDependencies and different peers bump type, the result of bump type for the dependent should be:

@Andarist What do you think about it?

@Andarist Is there anything an outsider can do to help this move past the finish line?

I have a pnpm patch, so I don't wanna rush, but I'm wondering if there's anything to do to support this. (e.g. write a PR updating docs? some tests?)

BTW #1126 seems related too.

updatePeerDependencies: "patch" | "minor": The minimum bump type to trigger automatic update of peer dependencies that are part of the same release. This is consisted with updateInternalDependencies.

Hm, quite frankly - I'm personally almost always confused by updateInternalDependencies and I need to constantly remind myself what does it actually do. So I'm worried if using it as a prior art for this setting here is the best thing that we can do.

In XState we currently always update ranges in peer dependents (with a custom script). It feels quite safe to do that, we didn't really encounter any problems with this approach. The main difference is that we do it despite a peer dependent not being released in any particular release. Potential downsides of this approach:

• the current state of package.json might not exactly reflect what's published on npm but that can already happen in so many situations that I don't care about this
• if we end up releasing the peer dependent in the future - we won't exactly have a good way of knowing that a range in its package.json was touched so there won't be an easy way to add this information to its CHANGELOG etc. This can probably be alleviated by always updating the range when the peer dependent is published. And perhaps we should do the same for updateInternalDependencies?

bumpStrategyForPeerUpdate: "major" | "follow": The strategy used to trigger automatic update of peer dependencies that are part of the same release, "follow" means if a peer dependency has a major/minor/patch bumps, this package will have a major/minor/patch bump at minimum, respectively.

I feel even stronger about this thing not relying on packages being part of the same release. This setting might even sometimes make a package to be included as part of the release.

I feel like the proposed options need to be extended with smth like out-of-range. This should allow people to use changeset version in projects like Babel or React. In those projects there is a strong desire to leave the peer dep range untouched, often "pinned" to a specific major version (like ^7.0.0) or to a version that contains some specific API (like ^16.8.0 if we think about React hooks).

I think that perhaps the names of those options could use some bike-shedding but that's also the least interesting part at this stage of this PR. We can always rename things just before landing this. What's needed right now is the implementation and the docs.

I feel like the proposed options need to be extended with smth like out-of-range.

Indeed. The version of peer dependent is still out of control.

The point people felt pain at most is that it requires major bump unexpectedly. People probably can tolerate it result in some patch bump, but ultimately we should give people more precisely control.

And during the time with the experience of my modified changeset, I felt bumpStrategyForPeerUpdate is not enough for this issue.

I felt people should have a way to specified the the result bump type for a peer dependent, and probably the most intuitive way to achieve this is specify both bump type of peer dependency and peer dependent in a same changeset.

That means, we should not bump the peer dependent automatically, when it was listed together with the peer dependency in the same changeset, as the developer already specified a desired bump type.

Suppose foo is a peer dependencies of bar, when making a new release:

• If there is a changeset affects both foo and bar, e.g. a major bump for foo and a patch bump for bar, the developer expected bar should have a patch bump as he/she has the knowledge that the change does not result in breaking change of bar. If there is some breaking change in bar, it's his/her responsibility to specify bar should have a major bump in the changset.

• If there is a changeset affects only foo, we should automatically bump bar, depite whether there is another changeset that affects bar or not. The result bump for bar could be none under some configuration if foo still fit into the version range specified by bar.

We need an option to enable the behavior described in the first situation, e.g. "autoBumpPeerDependentInSameChangeset": true | false(default to true for compatibility), and when set to "false", it just apply the kind of bump specified in the changeset.

An additional option "autoBumpPeerDependent": "always" | "out-of-range"(default to "always" for compatibility) may introduced for the second situation, and if it bumps automatically, consult autoBumpStrategy="major" | "follow"(default to "major" for compatibility) for what kind of bump it will be.

Probably we could introduce "never" to "autoBumpPeerDependent" too, to disable auto bump totally, but it seems to be dangerous unless we change the interactive cli to force the user to specify bump types for all affected peer dependents.

@Andarist If finally we reach an agreement, I could probably work on it this weekend, but it could takes some times longer than expected.

Any update on this PR? Currently I have pipelines disabled for auto version bump because of this. Would really be nice if a simple patch version of Package A didn't cause a major bump on Package B if Package A is peerDependency of Package B.

We need an option to enable the behavior described in the first situation, e.g. "autoBumpPeerDependentInSameChangeset": true | false(default to true for compatibility), and when set to "false", it just apply the kind of bump specified in the changeset.

An additional option "autoBumpPeerDependent": "always" | "out-of-range"(default to "always" for compatibility) may introduced for the second situation, and if it bumps automatically, consult autoBumpStrategy="major" | "follow"(default to "major" for compatibility) for what kind of bump it will be.

The proposed changes were implemented in the latest commit.
Three config were added:

• autoBumpPeerDependentsInSameChangeset: true|false, default to true for compatibility. When false, the auto bump behavior is completely disabled. And it's responsibility of end user to ensure that all affected peer dependents must be appear in the same changeset that bumps a peer dependency.
• autoBumpPeerDependentsCondition: "always" | "out-of-range", default value depends on ___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH.onlyUpdatePeerDependentsWhenOutOfRange which defaults to false, so it defaults to "always" if neither option was configured; but the old experimental configuration can be removed after this PR merged.
• autoBumpPeerDependentsStrategy: "major" | "follow": which was updatePeerDependencies that described before.

@Andarist Do we have a chance to get it reviewed and merged?

Anything we can do to help this one along? This would be extremely helpful for my org

@stevejcox one of our co-maintainers came up with a patch to hold us over for the time being

yarn1:

https://github.com/graphql/graphiql/blob/main/resources/patches/%40changesets%2Bassemble-release-plan%2B5.2.2.patch

pnpm (his original patch)

https://github.com/shuding/nextra/blob/main/patches/%40changesets__assemble-release-plan%405.2.4.patch

Any updates on this?

Is there anything we can do to help merge this PR?

Any updates on this?

Any updates on this as well?

Anything we can do? I’m ready to sacrifice a goat to get this PR merged
@Andarist

@Andarist We also really need this PR to be merged 👀

@Andarist +1 on this change being needed, any update on it getting merged?

any update?

our peer update with minor, and another package related to this peer has bump to major version

We can stay on a fork before the author merges this PR.

@Andarist please review, this feature is really needed!

Issue release a non wanted major in our company. please review it soon @Andarist

any update on this?

Hello? Any updates on this? @Andarist ?

Codecov Report

Attention: Patch coverage is 85.71429% with 8 lines in your changes missing coverage. Please review.

Project coverage is 81.15%. Comparing base (7323704) to head (10c5a06).
Report is 14 commits behind head on main.

@@            Coverage Diff             @@
##             main    #1132      +/-   ##
==========================================
+ Coverage   81.04%   81.15%   +0.10%     
==========================================
  Files          54       54              
  Lines        2221     2271      +50     
  Branches      657      699      +42     
==========================================
+ Hits         1800     1843      +43     
- Misses        417      424       +7     
  Partials        4        4              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Rebased upon the lastest HEAD. Wish for review. @Andarist

It doesn't seem like there has been any movement on this in a while... Worth asking again, does anyone have any updates or workarounds?

I've been working around it by removing packages from peerDependencies for now, but that's obviously not great. This one is very frustrating after spending time converting many of our repos to a monorepo and then running into this problem while publishing at the end.

Our team is also affected by this issue. In our case we use * ranges internally in a monorepo (npm workspaces), which then get updated to a caret range on publish (eg ^1.2.3 - whatever the latest version is).

In our case we'd prefer to have major versions generate major bumps of peer-dependent packages, and that's it. Since we are using caret ranges, minor and patch releases of the dependency should still be compatible.

It seems that this PR lost its wind either because of the design of the config parameters, or perhaps just because the maintainer no longer has the time. In case it was the former, I'd like to throw out an alternative option - allowing a .js configuration file that allows us to provide a function to configure the desired behavior. Here's an example draft of what I mean:

// .changeset/config.js

const config = {
  autoReleaseDependents: ({
    depType,
    nextRelease,
  }) => {
    // For peer-deps, create a major release if the dependency has a major release:
    if (depType === "peerDependencies" && nextRelease.type === "major") {
      return "major";
    }

    // For regular deps, create a patch release always so it's easy to get the updated version of the nested dependency:
    if (depType === "dependencies" && (nextRelease.type === "minor" || nextRelease.type === "major")) {
      return "patch";
    }
  }
};

export default config;

I'm sure there's some details to consider, but perhaps this would give us something more flexible than having 5+ different config values?

I'd like to throw out an alternative option - allowing a .js configuration file that allows us to provide a function to configure the desired behavior.

See the discussion at #1367.

Any updates on this?

This is also affecting us. Any idea when this can be merged ?

Any news? It's been two and a half years... it's too bad because changesets has been working really great for our design system project but the automatic major bumps are really undesirable and I can't stress this enough...