Compel users to release packages with breaking changes alongside their dependents

[mcmire]

Let's say we have the following package tree:

graph BT
 assets-controller -- dependency --> network-controller
 gas-fee-controller -- peer dependency --> network-controller

Loading

Let's say that network-controller has a breaking change, but it is released without either assets-controllers or gas-fee-controller being released. What would happen? This would break things in the clients when network-controller was updated to use the new version, because assets-controllers and gas-fee-controller would assume that it was interfacing with the older version of network-controller when this was not the case.

To address this, we can make two interrelated changes to this tool:

Given the project is a monorepo
And the user has indicated a breaking change in the release spec for a package, A, by specifying major for the version
And another package, B, relies on A either via peerDependencies or dependencies
When the tool applies the release spec
Then add an entry to the changelog for B that mentions the version bump so as to ensure that B is included in the release

Given the project is a monorepo
And the user has indicated a breaking change in the release spec for a package, A, by specifying major for the version
And another package, B, relies on A either via peerDependencies or dependencies
And the user has not included B in the release spec
When the tool applies the release spec
Then warn the user so that they are compelled to include in the same way that the tool warns the user about excluding packages with changes today: that is, explain the consequences of not including the package and force the user to re-edit the release spec and indicate intentionally-skip for B's version if they truly want to bypass the warning.

[xinnanyemm]

Hey team! Please add your planning poker estimate with Zenhub @Gudahtt @mikesposito @cryptodev-2s