-
-
Notifications
You must be signed in to change notification settings - Fork 267
Remove recent peer dependency bumps #4338
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -61,7 +61,7 @@ | |
| "typescript": "~4.9.5" | ||
| }, | ||
| "peerDependencies": { | ||
| "@metamask/network-controller": "^18.1.2" | ||
| "@metamask/network-controller": "^18.0.0" | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this one should be aligned with the |
||
| }, | ||
| "engines": { | ||
| "node": ">=16.0.0" | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -85,7 +85,7 @@ | |
| "@babel/runtime": "^7.23.9", | ||
| "@metamask/approval-controller": "^6.0.0", | ||
| "@metamask/gas-fee-controller": "^15.0.0", | ||
| "@metamask/network-controller": "^18.1.2" | ||
| "@metamask/network-controller": "^18.0.0" | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think for
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yes, due to (or the other way around, depending on how you want to see the causality) the switch from |
||
| }, | ||
| "engines": { | ||
| "node": ">=16.0.0" | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -73,7 +73,7 @@ | |
| "@metamask/approval-controller": "^6.0.0", | ||
| "@metamask/gas-fee-controller": "^15.0.0", | ||
| "@metamask/keyring-controller": "^16.0.0", | ||
| "@metamask/network-controller": "^18.1.2", | ||
| "@metamask/network-controller": "^18.0.0", | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think maybe this should still be |
||
| "@metamask/transaction-controller": "^30.0.0" | ||
| }, | ||
| "engines": { | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this one should be aligned with the
dependenciesfield? So if dropping here, then we'd also like to drop todependencies["@metamask/network-controller"] = "^18.1.0"?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just considering this case: Using
@metamask/gas-fee-controller, it will itself use@metamask/network-controller@^18.1.2due 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
dependenciesandpeerDependencies, 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?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Kind of separate, some of the messiness involved here goes away if properly utilizing worskpace cross-references, I think)
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Originally, we linked
dependenciesandpeerDependenciestogether. 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. usingyarn link). We replacedworkspace:^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 thanworkspace:^(and acts more likeworkspace:*).