Remove recent peer dependency bumps

[mcmire]

Explanation

In a previous release, some packages received new versions, and corresponding entries in dependencies, devDependencies, and peerDependencies were bumped to match. However, for packages that only received minor or patch bumps, it was not necessary to bump the peer dependencies. (These bumps may have been required by a rule that either the release tool or the core repo enforces.) Reverting these changes avoids having to create major releases for the packages in which these peer dependencies were bumped.

References

Changelog

(Updated in PR)

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

[legobeat]

I think this one should be aligned with the dependencies field? So if dropping here, then we'd also like to drop to dependencies["@metamask/network-controller"] = "^18.1.0" ?

[mcmire]

Hmm, are you saying that if a version of a package within the monorepo is bumped we should no longer sync all dependencies on that package?

[legobeat]

Hmm, are you saying that if a version of a package within the monorepo is bumped we should no longer sync all dependencies on that package?

Just considering this case: Using @metamask/gas-fee-controller, it will itself use @metamask/network-controller@^18.1.2 due to its dependency. It will accept any @metamask/network-controller@^18.0.0.
I have trouble coming up with why we want to enforce the direct dependency to be latest but still allow supplying a different, older versions as constructor parameters or what it may be. I think the developer assumption is generally that when using e.g. a controller instance as a construction parameter, it's easy to assume to be working with a single version of the package and not multiple at the same time depending on where instantiation was made.

For the general case for packages that have the same package in both dependencies and peerDependencies, I'm thinking it's a case-by-case-basis: Either both fields are bumped, or neither. I can see both situations and can't really give you a general heuristic.

Conversely, why do you think we want to have these disjoint?

[legobeat]

(Kind of separate, some of the messiness involved here goes away if properly utilizing worskpace cross-references, I think)

[mcmire]

Originally, we linked dependencies and peerDependencies together. So if a developer updated the dependency of a package and it was also a peer dependency, then the versions needed to match. However, since bumping a peer dependency requires a major version bump, this resulted in many major version bumps. We decided to unlink them here to reduce the number of major versions: #3881.

I do see your point about allowing older versions of constructor parameters but not allowing older versions of "messages" between controllers. It seems highly likely for a change in API to affect direct usage (instantiating or calling methods on the controller) as much as indirect usage (using the controller through the messenger) and in the same way. Perhaps the change I mentioned above needs to be readdressed?

As for why we don't use workspace:^, this prevents developers from being able to test changes to core packages in extension and mobile locally (e.g. using yarn link). We replaced workspace:^ references with static versions and added a Yarn constraint which ensured that if one workspace package has a dependency on another, the version of the dependency matches the current version of the package: #1623. Admittedly, this goes further than workspace:^ (and acts more like workspace:*).

[legobeat]

I think this one should be aligned with the dependencies field? So if dropping here, then we'd also like to drop to dependencies["@metamask/network-controller"] = "^18.1.0" ?

[legobeat]

I think for transaction-controller, we do want to ensure we use the same version of @metamask/eth-block-tracker? So I think for this specific package, we do want the bump in peerDependencies entry.

[mcmire]

Hmm. The way we've been using the peer dependency is that it dictates which version of this package the project needs to use in order to be able to use this controller in all situations without breaking.

So are you saying that in order to use transaction-controller without breaking, a project needs to effectively rely on the version of network-controller that uses @metamask/eth-block-tracker?

[legobeat]

So are you saying that in order to use transaction-controller without breaking, a project needs to effectively rely on the version of network-controller that uses @metamask/eth-block-tracker?

Yes, due to (or the other way around, depending on how you want to see the causality) the switch from nonce-tracker to @metamask/nonce-tracker and its associated switch from eth-block-tracker to @metamask/eth-block-tracker.

[legobeat]

I think maybe this should still be ^18.1.2 do to the dependency+peerDependency on transactions-controller? Or if we can drop to peerDependencies["@metamask/transaction-controller"] = "^29.1.0 | ^30.0.0.

[mcmire]

I opted to keep all of these peer dependency bumps in #4342, so this PR is now moot.