"Interesting" major bumps on peer deps

[gossi]

In our private monorepo where we are using release-plan, we started using it, when every package had the same version number. release-plan made it so each package "ages" differently. While the majority of them is v5.* I notied two packages are at v8 already - and nothing major happened to them.

Looking at the explanations, these two packages have a peer dep to another package of the monorepo and that package is minor/patch-bumped when its dependencies receive a change. But each these bumps causes the beforementioned packages to major bump.

To my knowledge, that shouldn't cause a major bump, but a minor/patch respectively? Then this is a bug - or - my knowledge is wrong, then this is a question on what is the reason behind this =)

[MarianBeuther]

We solved this issue for now by switch from

"peerDependencies": {
    "some-dependency": "workspace:*"
  },

to

"peerDependencies": {
   "some-dependency": "workspace:^"
 },

but would've expected release-plan to instead check the peerDependency version change and bump based on the peerDependency
-> peerDependency has a minor bump -> minor
-> peerDependency has a major bump -> major
etc

[gossi]

@MarianBeuther showed the "fix" we did - I wanna dive into our reverse engineering of what we think was the thinking behind the decision making of release-plan.

Here is our "explanation" why we assume, this turns into a major version - and that has to do with automated updates. So, whenever a peer dep is bumped, that means automated tools such as renovate/dependabot wouldn't be able to automatically increase the version as it would also require them to also update the peer dep. That's why we think release-plan drops a major, which those tools have configuration options to check for. In that case a manual work is required in order to bump these versions and their peer dep versions.

To precisely describe what we were after is actually: "some-dependency": "workspace:^major" - however that sort of workspace protocol doesn't exist and also there are other versioning mechanics next to semver (such as calver).

So release-plan - according to how we understood the code - doesn't check what version bump the peer dep has gone through (major, minor, patch) and adds a constraint for major bump.

We were left with the expectations Marian already posted.

• Are we correct with our assumptions for this constraint?
• Would it make sense to go into detail to check on the peer dep change (to match our expectations) or is there more, that we don't see?

Thanks

[simonihmig]

FWIW, I was running into a similar issue recently with changesets: changesets/changesets#1011 :)