changeset version not bumping dependent packages

[vitorolivg]

Hey 👋, we're currently using changeset in our private monorepo. We started seeing some miss behavior during the version step which is not bumping dependent projects.

e.g.:
pkg-a - 2.23.8
pkg-b - 2.34.0

• pkg-a - ^2.23.8

After updating the pkg-a + adding a changeset file (minor bump) the version step is not patching pkg-b.

Checking the assemble-release-plan package, I have spotted this condition that is affecting the addition of the pkg-b to the filtered packages (from determineDependents):

https://github.com/changesets/changesets/blob/main/packages/assemble-release-plan/src/determine-dependents.ts#L90

The semver.satisfies will return true for:

incrementVersion response: 2.24.0
versionRange: ^2.23.8

The problem seems to be the caret (^2.23.8) of the version range, is this expected?

Should we remove the caret from our packages or use the ___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH.updateInternalDependents = "always" to bypass this problem?

Some info on our config

"@changesets/cli": "^2.23.2"
"updateInternalDependencies": "patch",

Thanks in advance for your help 🙏

[Andarist]

Should we remove the caret from our packages or use the ___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH.updateInternalDependents = "always" to bypass this problem?

It kinda depends on your goals:

• removing the caret would "force" a new release of the dependent package but could potentially lead to more copies of the same package when installing your packages, it also wouldn't allow newer versions of that dependency to be installed to leverage fixes in it. OTOH with that the dependant would always get a new release in such a case so a consumer could always bump that
• updateInternalDependents: 'always' - this doesn't have mentioned drawbacks and it still creates releases for all dependants. I would personally reach out for this one if you are interested in this behavior

Note that, in theory, not bumping those dependants is "correct". If your dependant declares that it depends on ^2.23.8 then it should still be compatible with 2.24.0. If you start using some newer additions from pkg-a in pkg-b then often you should create a changeset for pkg-b too. I know that this is somewhat error-prone though and that's why we've implemented that updateInternalDependents: "always". I think that this might actually become the default in the future.

[vitorolivg]

Thanks, @Andarist for your response!

We will go for the updateInternalDependents: 'always' option. I just wanted to clarify if we would have a different approach for this scenario/ensure we don't go for a non-ideal configuration.

Appreciate the explanation,

Cheers!