-
Notifications
You must be signed in to change notification settings - Fork 62
Modify all branded types such that they will match with any structurally similar type from any package version, going forward #473
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
Conversation
🦋 Changeset detectedLatest commit: 9270a01 The changes in this PR will be included in the next version bump. This PR includes changesets to release 40 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
This stack of pull requests is managed by Graphite. Learn more about stacking. |
BundleMonUnchanged files (127)
No change in files bundle size Final result: ✅ View report in BundleMon website ➡️ |
57d3857
to
d9419ea
Compare
d9419ea
to
92ca667
Compare
Documentation Preview: https://kit-docs-9inxs4t3b-anza-tech.vercel.app |
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.
Beautiful! There are other unique symbols
we should consider cleaning such as transaction type flags (e.g. FullySignedTransaction
). Refer to my previous comment for this.
92ca667
to
2f4b511
Compare
9376ffa
to
509f7f6
Compare
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.
❤️
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'm dumb. This isn't a major version bump. Opaque/branded types between patch versions of v2 are already incompatible, so improving this is not a breaking change.
2f4b511
to
dfb0faf
Compare
509f7f6
to
45bed58
Compare
dfb0faf
to
1dc5153
Compare
45bed58
to
79fde4c
Compare
1dc5153
to
7ec918b
Compare
79fde4c
to
3a7178b
Compare
7ec918b
to
12e89b4
Compare
3a7178b
to
064e825
Compare
12e89b4
to
445cc6c
Compare
064e825
to
f0cceaf
Compare
Merge activity
|
…lly similar type from any package version, going forward
445cc6c
to
9270a01
Compare
Because there has been no activity on this PR for 14 days since it was merged, it has been automatically locked. Please open a new issue if it requires a follow up. |
Problem
Two versions of any given package may introduce two distinct instances of our branded types into a project. That is to say you might get the
Address
type from v2.0.0 and v2.1.0 in the same project.Summary of Changes
Here we use the type utilities in the previous stacked PR to reimagine these types as structurally identical, rather than having an identity that's tied to one particular instance of a module.
This will make it so that
Address
and other branded types like it are compatible from version v2.1.1 and onward.Fixes #459