Automatic Dependency Updates Within Monorepo

Problem

If I have @scope/package-a, @scope/package-b, @scope/package-c. Both @scope/package-b and , @scope/package-c rely on @scope/package-a. When I make a change to @scope/package-a, commit & create yarn changeset, select @scope/package-a and update it with a patch version, then yarn changeset version, @scope/package-a’s version changes, but both @scope/package-b AND @scope/package-c’s dependencies @scope/package-a does not get changed.

What’s the best way to ensure ALL dependents change to new latest version within its range? This happens with pre-releases for me as well as normal. I’ve tried changing package-a to minor AND major.

chanset --version
2.11.0

node --version
v13.13.0

yarn --version
1.22.4

config.json

{
  "$schema": "https://unpkg.com/@changesets/config@1.4.0/schema.json",
  "changelog": "@changesets/cli/changelog",
  "commit": false,
  "linked": [],
  "access": "restricted",
  "baseBranch": "master",
  "updateInternalDependencies": "patch",
  "ignore": []
}

[Andarist]

I believe you have made mistakes in that example output:

• pkg-a should have version: 2.0.0
• pkg-b should have version: 1.1.0

Nevertheless, I get your point. Why the dependency ranges have changed in here? Because the packages that are being published get dependency ranges updates according to updateInternalDependencies setting. This makes sense because when you change the code of a dependant package it might start to depend on some fresh code in a monorepo setup from a dependency package - so it’s safer to update the range. The idea was that if u change the code of a dependency then most likely a dependant package should not be affected by this but when you change the code of a dependant package it should always use the latest version of its monorepo dependencies - otherwise, it would be fairly easy to publish broken releases. This leads to some inconsistencies around when dependency ranges are updated - might be surprising at times.

As mentioned - we recognize this problem and we’d like to have it fixed, but I’m afraid that we don’t have much time to implement a solution for this ourselves currently. I’d be more than happy to assist anyone with guidance, code reviews etc if one would like to implement this.

[Andarist]

In such a case we don’t always update dependant packages - if their dependency ranges are satisfied by a new version of package-a then an update is skipped.

This is causing some problems/difficulties though - I was discussing this with @mitchellhamilton some time ago. From what I remember we’ve agreed on introducing an experimental flag that would change this behavior (to what you want, from what I understand) with a perspective of it becoming a default in the future.

Could you confirm that this is what you expect:

Input:

tree
---
pkg-a
  version: 1.0.0
pkg-b
  version: 1.0.0
  dependencies:
    pkg-a: ^1.0.0
pkg-c
  version: 1.0.0
  dependencies:
    pkg-a: ^1.0.0

changeset
---
pkg-a: patch

Output:

tree
---
pkg-a
  version: 1.0.1
pkg-b
  version: 1.0.1
  dependencies:
    pkg-a: ^1.0.1
pkg-c
  version: 1.0.1
  dependencies:
    pkg-a: ^1.0.1