-
Notifications
You must be signed in to change notification settings - Fork 212
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
chore(types): correct ManifestBundleRef #7957
Conversation
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.
FWIW: re chore
: I often use docs
for types.
* @typedef BundleHandle | ||
* @property {string} [bundleName] | ||
* @typedef {{ bundleName: string } | { bundleID: string} } ManifestBundleRef |
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.
a thought on product interface boundaries...
One consumer (metamask) pointed out that even though the types have no runtime impact, they can represent breaking changes in the sense that ci jobs fail and effort is needed to address them. This type is exported, so renaming it is a breaking change, from that angle. (I suppose changing its definition could be too)
I don't think that should hold up this PR, but I hope we decide soon on a pretty clear set of product interfaces.
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.
Good to raise. I queued it for our discussion about breaking changes.
chore(types): correct ManifestBundleRef
chore(types): correct ManifestBundleRef
chore(types): correct ManifestBundleRef
chore(types): correct ManifestBundleRef
Description
Document some type info found while debugging with @Chris-Hibbert
Security Considerations
Scaling Considerations
Documentation Considerations
Testing Considerations