-
-
Notifications
You must be signed in to change notification settings - Fork 208
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
Use static versions for interdependencies #1623
Merged
Merged
Changes from 1 commit
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
8dc7199
Use static versions for interdependencies
mcmire c8f94e6
Merge branch 'main' into make-yarn-link-work-again
mcmire 69ed88f
Merge branch 'main' into make-yarn-link-work-again
mcmire 811e5ea
Rewrite section on testing changes to include local
mcmire cf79ca4
Merge branch 'main' into make-yarn-link-work-again
mcmire File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Has it been considered to use unpublished placeholder versions here? Like
^3.2.0-next
. The published versions would of course have theirpackage.json
aligned with published versions. This would remove the risk of accidentally resolving from registry while keeping the ease of override in this PR, I think?It's a pattern I recall seeing from time to time.
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 so I understand, you're saying that if we use static versions there is a risk that a dependency on an internal package could point to a published version instead of the internal version, but if we use an unpublished version then we never have that risk?
If so, that's a good point. One immediate thought I have is that this shouldn't be an issue, because you need to use Yarn whenever installing dependencies in this repo, and Yarn seems to be smart about understanding that if package A depends on package B and package B is a workspace package, and the version range of the dependency matches the version of package B in its manifest, it won't attempt to download the published version of package B. This can be observed via the lockfile: https://github.com/MetaMask/core/blob/make-yarn-link-work-again/yarn.lock#L1330
Another thing to think about is that if we added a suffix, we'd have to make sure to strip it when we release. This isn't hard to do in the context of this repo — we can do it in a
prepack
step — but we'd also need to do it in our GitHub Actions and increate-release-branch
, where there are various places that we read the current version of a package by looking directly at itspackage.json
. This would add some complexity to these pieces that could be tricky to maintain, so I'd want to make sure we'd need them.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.
Yup. And there's some history for this happening. Especially since this is a monorepo which includes external dependencies in the same namespace as the monorepo itself (
@metamask/
), it's an easy enough mistake to make in larger changes, even for those who actually do read scan through each lockfile change manually. I've seen it happen multiple times in other monorepos using this scheme and I suspect it's one reason behind theworkspace:^
scheme in the first place.And yes, it would require some updates to release/publish scripts. But there is already an implicit requirement to bump version precisely once per successful publish.
What is the benefit of having checked-in versions always match the last published version, as opposed to unpublished versions? It seems that you never actually want them to match, and they will start to drift at the first commit after each release despite version numbers matching. It seems to me that this will mean that version-bumping should also change to be done at the time of commit of changes (e.g. bump package to a major at the point of merging a breaking change) as opposed to like now, at point of release.
I may be missing the reasoning behind why these versions specifically are desired, though.
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.
Maye @haltman-at / @eggplantzzz have a useful perspective to share given that Truffle seems to already be using the same scheme proposed here.
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.
The constraints mitigate this risk pretty well I'd think. They automatically keep the ranges synchronized with the current versions of each package. Contributors should never have to remember to update them at all.
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.
We developed the release process for the monorepo this way not so much because there was a clear benefit to doing so, but because it evolved from the standard release process that we (and the JavaScript community at large) follow for polyrepos.
I hear what you're saying. I think this might just be a different perspective, however. The checked-in version of a package doesn't mean "the last published version"; rather, it means "the next version to publish". On top of this, our release automation assumes that a package should be published if its version has changed, and that it shouldn't otherwise. This is the reason why we don't bump the version of a package until we want to create a new release. (We are talking about changing this so that contributors can queue version bumps along with changes that necessitate them, but even in that case, I don't think we would actually bump the version of the package in the manifest until release time.)
Returning to your first paragraph, I don't want to dismiss this and I definitely appreciate your perspective. That said, do you think that Yarn constraints would adequately protect against what you've seen?
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.
Appreciate the explanation. I did miss the yarn constraints initially, which I agree should address the much of the potential practicalities, yes.
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.
Merging since we've got 2 'yes' votes on this and we want to unblock another team we're closely working with, but I don't want to stop the conversation here.