Relax peer dependency constraints #3881

mcmire · 2024-01-31T19:12:31Z

Explanation

When we release a new version of a controller, our Yarn constraints enforce that we must also bump any peer dependencies that rely on that controller to match the new version. And one of our policies is that if we bump a peer dependency in a package, we must release a new major version of that package. As a result, because we make changes to controllers all the time, we also end up making major releases all the time too. This is unnecessary if most of those changes aren't actually breaking.

To reduce the number of major releases, this commit relaxes constraints on peer dependencies in two ways:

Peer dependencies for the same package across the monorepo are no longer required to use the same exact version.
A peer dependency on a controller is only required to match the major version of its corresponding non-peer dependency (which is itself required to match the current version of that dependency).

For instance, if the current version of @metamask/keyring-controller is 12.2.0, a controller would be allowed to declare a peer dependency on ^12.0.0. In addition, two controllers would be allowed to use slightly different versions, as long as they were major-compatible with the package (for instance, one controller could use ^12.0.0 and another could use ^12.1.0).

References

Fixes #3880.

Testing

As there are changes to a few constraints in this PR, here's how you can test it:

Open packages/accounts-controller/package.json.
Update the peer dependency on @metamask/keyring-controller to ^12.0.0.
Run yarn constraints. It should show no output (meaning that all constraints passed).
- This happens this version range is major-compatible with the current version of @metamask/keyring-controller (12.2.0).
Update the peer dependency on @metamask/keyring-controller to ^12.1.2.
Run yarn constraints. It should show no output (meaning that all constraints passed).
- This happens this version range is major-compatible with the current version of @metamask/keyring-controller (12.2.0).
Update the peer dependency on @metamask/keyring-controller to ^12.1.0.
Run yarn constraints. It should show no output (meaning that all constraints passed).
- This happens this version range is major-compatible with the current version of @metamask/keyring-controller (12.2.0).
Update the peer dependency on @metamask/keyring-controller to ^12.3.0.
Run yarn constraints. It should show the following error:
```
➤ YN0024: @metamask/accounts-controller must depend on @metamask/keyring-controller via ^12.2.0, but uses ^12.3.0 instead (in peerDependencies)
```
- This happens because the version of @metamask/keyring-controller is greater than the current version of @metamask/keyring-controller (12.2.0), and so the recommendation is to use this version.
Update the peer dependency on @metamask/keyring-controller to ^13.0.0.
Run yarn constraints. It should show the following error:
```
➤ YN0024: @metamask/accounts-controller must depend on @metamask/keyring-controller via ^12.2.0, but uses ^13.0.0 instead (in peerDependencies)
```
- This happens because the version of @metamask/keyring-controller is greater than the current version of @metamask/keyring-controller (12.2.0), and so the recommendation is to use this version.
Update the peer dependency on @metamask/keyring-controller to ^11.0.0.
Run yarn constraints. It should show the following error:
```
➤ YN0024: @metamask/accounts-controller must depend on @metamask/keyring-controller via ^12.2.0, but uses ^11.0.0 instead (in peerDependencies)
```
- This happens because the version of @metamask/keyring-controller is not major-compatible with the current version of @metamask/keyring-controller (12.2.0), and so the recommendation is to use this version.
Remove the peer dependency on @metamask/keyring-controller.
Run yarn constraints. It should show no output (meaning that all constraints passed).
- This happens because @metamask/keyring-controller is a dev dependency in this case, and so there is no requirement that it also be a peer dependency.
Move the dev dependency on @metamask/keyring-controller to dependencies, and keep the peer dependency missing.
Run yarn constraints. It should show the following error:
```
➤ YN0023: @metamask/accounts-controller must depend on @metamask/keyring-controller (via ^12.0.0), but doesn't (in peerDependencies)
```
- This happens because @metamask/keyring-controller is required to be a peer dependency if it is a dependency.

Changelog

(N/A)

Checklist

I've updated the test suite for new or updated code as appropriate
I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
I've highlighted breaking changes using the "BREAKING" category above as appropriate

When we release a new version of a controller, our Yarn constraints enforce that we must also bump any peer dependencies that rely on that controller to match the new version. And one of our policies is that if we bump a peer dependency in a package, we must release a new major version of that package. As a result, because we make changes to controllers all the time, we also end up making major releases all the time too. This is unnecessary if most of those changes aren't actually breaking. To reduce the number of major releases, this commit relaxes constraints such that a peer dependency on a controller is only required to match the major version of its corresponding non-peer dependency (which is itself required to match the current version of the controller). For instance, if the current version of `@metamask/keyring-controller` is 12.2.0, this commit would allow a peer dependency on that controller to merely be `^12.0.0`.

mikesposito · 2024-02-01T10:45:37Z

I tried to checkout on this branch and followed these two steps:

Open packages/accounts-controller/package.json.
Update the peer dependency on @metamask/keyring-controller to ^12.0.0.

But when running yarn constraints what I get the following errors:

➤ YN0024: @metamask/preferences-controller must depend on @metamask/keyring-controller via ^12.0.0, but uses ^12.2.0 instead (in devDependencies)
➤ YN0024: @metamask/preferences-controller must depend on @metamask/keyring-controller via ^12.0.0, but uses ^12.2.0 instead (in peerDependencies)
➤ YN0024: @metamask/signature-controller must depend on @metamask/keyring-controller via ^12.0.0, but uses ^12.2.0 instead (in dependencies)
➤ YN0024: @metamask/signature-controller must depend on @metamask/keyring-controller via ^12.0.0, but uses ^12.2.0 instead (in peerDependencies)
➤ YN0024: @metamask/user-operation-controller must depend on @metamask/keyring-controller via ^12.0.0, but uses ^12.2.0 instead (in dependencies)
➤ YN0024: @metamask/user-operation-controller must depend on @metamask/keyring-controller via ^12.0.0, but uses ^12.2.0 instead (in peerDependencies)

Did I miss some steps?

mcmire · 2024-02-01T21:42:44Z

@mikesposito Ah, I should have been more clear.

If you update @metamask/keyring-controller in @metamask/accounts-controller to ^12.0.0, there should be no errors listed under @metamask/accounts-controller. There will be errors listed under other packages, but that is because of a different constraint which verifies that all references to a workspace package use the same version range. So in that case, it's saying that there are other packages which also have @metamask/keyring-controller as a dependency but are using later versions and need to also be changed to ^12.0.0. Those errors are expected, and if you then run yarn constraints --fix, then it will correct them and you should have no other errors.

If you update @metamask/keyring-controller in @metamask/accounts-controller to a version that is < 12.0.0 (the major of the current version of @metamask/keyring-controller + '.0.0') or greater than 12.2.0 (the current version of @metamask/keyring-controller), you should see an error listed under @metamask/accounts-controller which indicates that this version is incorrect and should be corrected to at least ^12.0.0.

mcmire · 2024-02-01T23:17:20Z

After testing the constraints a bit more, I found some bugs. I also noticed that I left some existing constraints commented out 🤦🏻

I've fixed the constraints and ensured that none were commented out. I've also updated the Testing section in the PR description to account for all the cases.

legobeat · 2024-02-02T12:46:13Z

General direction seems good, but wouldn't it make sense to allow divergence within the major for some situations? With the same example, imagine if @metamask/accounts-controller would be depending on newer features only available from @metamask/[email protected] (so it would need a bump in peerDeps) but the other packages unchanged (so can/should stay on ^12.2.0, for the same reason as in the PR description)

mcmire · 2024-02-02T22:19:58Z

@legobeat If I understand you correctly, you're saying that the constraint that all peer dependencies for the same package be the same version range should be removed? If so, I've also made that change in this PR, so two packages can have a peer dependency on e.g. @metamask/keyring-controller but one is allowed to use ^12.3.0 while the other is allowed to use ^12.2.0. It's just that whatever version is used for a peer dependency must be major-compatible with the current version of that dependency. Does that address your concern?

mikesposito

Looks good!

cryptodev-2s

LGTM!

mcmire requested a review from a team as a code owner January 31, 2024 19:12

mcmire added the team-wallet-framework label Jan 31, 2024

Simplify constraint, and relax peer deps for all other packages

b953b6c

mcmire requested a review from a team as a code owner February 1, 2024 22:19

mcmire added 5 commits February 1, 2024 15:22

No need for this second check

eb7c2cf

Relax constraint further, and revert changes to packages

340ceae

Revert name change

12d68e8

Restore commented out constraints

b90dd10

Merge branch 'main' into relax-peer-dependency-constraints

7a3d018

Fix version comparison logic

ff19a10

Merge branch 'main' into relax-peer-dependency-constraints

b3c38e4

mikesposito approved these changes Feb 6, 2024

View reviewed changes

cryptodev-2s approved these changes Feb 6, 2024

View reviewed changes

mcmire merged commit d3861d0 into main Feb 6, 2024
136 checks passed

mcmire deleted the relax-peer-dependency-constraints branch February 6, 2024 16:14

MajorLift mentioned this pull request Mar 1, 2024

Release 123.0.0 #4007

Merged

mcmire mentioned this pull request May 30, 2024

Remove recent peer dependency bumps #4338

Closed

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Relax peer dependency constraints #3881

Relax peer dependency constraints #3881

mcmire commented Jan 31, 2024 •

edited

Loading

mikesposito commented Feb 1, 2024

mcmire commented Feb 1, 2024 •

edited

Loading

mcmire commented Feb 1, 2024

legobeat commented Feb 2, 2024 •

edited

Loading

mcmire commented Feb 2, 2024 •

edited

Loading

mikesposito left a comment

cryptodev-2s left a comment

Relax peer dependency constraints #3881

Relax peer dependency constraints #3881

Conversation

mcmire commented Jan 31, 2024 • edited Loading

Explanation

References

Testing

Changelog

Checklist

mikesposito commented Feb 1, 2024

mcmire commented Feb 1, 2024 • edited Loading

mcmire commented Feb 1, 2024

legobeat commented Feb 2, 2024 • edited Loading

mcmire commented Feb 2, 2024 • edited Loading

mikesposito left a comment

Choose a reason for hiding this comment

cryptodev-2s left a comment

Choose a reason for hiding this comment

mcmire commented Jan 31, 2024 •

edited

Loading

mcmire commented Feb 1, 2024 •

edited

Loading

legobeat commented Feb 2, 2024 •

edited

Loading

mcmire commented Feb 2, 2024 •

edited

Loading