Relax peer dependency constraints

[mcmire]

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:

1. Peer dependencies for the same package across the monorepo are no longer required to use the same exact version.
2. 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

[mikesposito]

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]

@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]

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]

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/keyring-controller@12.3.0 (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]

@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!