{{ message }}
Repository navigation
Unexpected peerdependent bump to 1.0.0 in pre mode #960
Description
Problem
I have a branch in pre mode, and I don't understand why Changesets is planning on bumping this peerdependent to 1.0.0, even if the dependency's new version perfectly satisfies the specified range (0.11 is >= 0.9, right?)
I would have expected the specified peer dependency range to remain intact, and the dependent's version not to be bumped to 1.0.0.
To clarify, bumping the peer dependency range would be acceptable (even if I did not expect it), but the bump to 1.0.0 is not.
My config.json:
{
"$schema": "https://unpkg.com/@changesets/config@2.0.0/schema.json",
"changelog": "@changesets/cli/changelog",
"commit": false,
"fixed": [],
"linked": [],
"access": "public",
"baseBranch": "main",
"updateInternalDependencies": "minor",
"ignore": [],
"___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH": {
"onlyUpdatePeerDependentsWhenOutOfRange": true
}
}Version of changesets in use is 2.24.4.
Link to PR and repository: https://github.com/hmans/miniplex/pull/126/files
Thanks!
Activity
hmans commentedon Sep 24, 2022
Addendum: setting
"updateInternalDependencies": "patch"didn't make a difference.Andarist commentedon Oct 2, 2022
Thanks for the repro case - I will try to analyze this case soon
Andarist commentedon Oct 6, 2022
It seems that the CLI did the right thing here (well, perhaps the bump could be to the next minor version and not the next major version but that's a separate issue).
Your next version of the
miniplexwas computed as0.11.0-next.0and the existing range for this dependency inminiplex-reactwas>=0.9.0. Prereleases are somewhat weird and special and they often work with semver ranges in somewhat unexpected ways. Despite the>=modifier - such a prerelease version doesn't satisfy this range:hmans commentedon Oct 6, 2022
Thanks for taking a closer look!
A minor bump would have been acceptable, yes.
Is this because it being a prerelease, or because of some sort of lexical sorting issue triggered by the
-next?Andarist commentedon Oct 6, 2022
Note that this minor bump would only be possible because your
miniplex-reactis still in 0.x.Maybe I could consider changing the rules somehow to use the minimal version bumping during the prerelease stage and only bump the dependent version to a higher bump when exiting the prerelease mode? But this gets really fuzzy to me and I would have to consider what would be the implications - also what that would actually allow us to avoid here.
There is a chance that this could avoid such "redundant" bumps for the
>=ranges.It's because the version is a prerelease version:
Those ranges are used when you install packages and their dependencies. Usually, the higher available (and compatible) version is chosen by the package manager. You certainly wouldn't like to get installed a prerelease version of a transitive dependency if your dependency declared a range like this :P That would be disastrous.
For the same reason - we need to adjust the dependency version range. Otherwise, you wouldn't be able to install your transitive dependencies with that prerelease version. The package manager would refuse to install the prerelease dependency and you would end up with:
hmans commentedon Oct 6, 2022
Thanks for taking the time to explain it in so much detail, it is highly appreciated.
FWIW, the entire thing reminded me that it was time to publish the 1.0.0 of those packages. ;-)
Andarist commentedon Oct 6, 2022
One additional idea is that perhaps for the
>=range we could "upgrade" it to smth like ">=0.9.0 || >=0.11.0-0.next.0":Then we could even "bring back" the original range when exiting the premode.
hmans commentedon Oct 7, 2022
If that is a feasible thing to do, it'd be perfect!
alvarosabu commentedon Nov 14, 2022
I'm having the same issue, pkgB has pkgA as peerDependency.
PkgB is bumped to 1.0.0 instead of next minor version.
PkgA is bumped to next minor correctly.
alvarosabu commentedon Nov 18, 2022
Is there a work around? I'm basically doing the version bumping and then putting the correct minor version by hand
dohooo commentedon Dec 1, 2022
Same here. Are there any updates?
Add a new bump strategy for peers bump, resolve changesets#1011, chan…
Add a new bump strategy for peers bump, resolve changesets#1011, chan…
Add a new bump strategy for peers bump, resolve changesets#1011, chan…
Add a new bump strategy for peers bump, resolve changesets#1011, chan…
Add a new bump strategy for peers bump, resolve changesets#1011, chan…
Add a new bump strategy for peers bump, resolve changesets#1011, chan…
fix: patch changesets to fix pre-release peer dep major escalation
feat: prerelease channels (branch-based, no committed prerelease vers…
bluwy commentedon Jun 26, 2026
@beeequeue is this also indirectly resolved by #2090?
beeequeue commentedon Jun 26, 2026
i belive this was indeed caused by the peer dependent major bump, so it should be fixed now.