Feature request: peer dependency version bump metadata in front matter

Problem

Consider the following scenario:

You have a package A with a version 1.0.0.
Package B has a peer dependency on A with the range ^1.0.0.
You release a new version of package A, e.g., 1.1.0.

There is currently one option to control if the peer dependency version of package A in B should be updated.

onlyUpdatePeerDependentsWhenOutOfRange is true:
Package B will not be updated because its peer dependency range ^1.0.0 still includes 1.1.0.
onlyUpdatePeerDependentsWhenOutOfRange is false:
Package B will be updated to reflect the dependency on the latest version of A, even though 1.1.0 is within the specified range.

But the issue is whether the peer dependency should be bumped or not depends on the change so the config file is not the right place to have an option for this, and it should be per change.
E.g. if a new feature is added in A that's used in B, the minimum required version of A in B is now the new version of A. In another case, the new feature (or fix for that matter) in A might not be necessary in B, so the peer dependency version can remain the same.

Suggested solution

Allow for having such metadata in the changeset files. So instead of a flat mapping of package name to version, it would be possible to add such metadata about the changes within the front matter of the changeset files, considering some options semantically belong to the changes and not global configuration.

I haven't thought much about the possible ways to extend the front matter syntax, but some rough suggestions:

---
A: minor
B:
 update: minor
 peerUpdates:
   - A
---
...

the downside being in cases where A and B have separate changeset files, it should be possible to specify the relation based on some additional name property (which could be the name of the changeset file).

Another way could be something like this:

---
A: 
  update: minor
  affectedPeers:
    - B
---
...

These are just some examples to better communicate the idea, but I'm sure there can be more refined structures to represent that information there. The main point is the information belongs to changesets not a global configuration.

I'm not sure if #2090 closes this issue. Could you elaborate on how that change fixes this issue? Note that the point of this feature request is to be able to determine how peers should be updated per change.

i closed the issue despite it not being a perfect fix (along with the others) as i am going to open a new umbrella issue regarding configuring dependent bumps and how we should handle them.

you're right that this issue should probably not have been closed by #2090 directly, but it will be superseded by the new planning issue later where i will make sure to include this issue and its ideas 😊

Navigation Menu

Repository navigation

Feature request: peer dependency version bump metadata in front matter #1600

Problem

Suggested solution

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Feature request: peer dependency version bump metadata in front matter #1600

Description

Problem

Suggested solution

Activity

alirezamirian commented on Feb 26, 2025

alirezamirian commented on Jun 25, 2026

beeequeue commented on Jun 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions