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.
Reactions are currently unavailable
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.
Package B will not be updated because its peer dependency range ^1.0.0 still includes 1.1.0.
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.