-
Notifications
You must be signed in to change notification settings - Fork 214
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
refactor(orchestration,time,zoe): Avoid name convention conflict #10751
Conversation
3d997f4
to
6baee47
Compare
Deploying agoric-sdk with Cloudflare Pages
|
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.
No objection to the change but I request that before merging we solve the underlying problem. (If this is worth fixing it's worth preventing the need to fix it.)
Please update lint config to use https://typescript-eslint.io/rules/naming-convention/ so TS interfaces never end in I
.
module.exports = {
parser: '@typescript-eslint/parser',
plugins: ['@typescript-eslint'],
rules: {
'@typescript-eslint/naming-convention': [
'error',
{
selector: 'interface',
format: ['PascalCase'],
custom: {
regex: '.*I$',
match: false
}
}
]
}
};
You might also/instead want to make a rule to ensure that anything that ends in I
is a typeguard.
I added the lint rule you requested. I manually verified that it applied to current master produces the following lint errors:
whereas as part of endojs/endo#2666 it does not. However, IIUC, this lint rule won't be operational for agoric-sdk until the next release-and-update cycle. Are you ok with the delay? |
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.
LGTM, thanks for making the improvement durable
closes: #XXXX Agoric/agoric-sdk#10751 ## Description We generally use names of the form `^([A-Z]\w*)I$`, i.e., identifiers beginning with a capital letter and ending with a lone capital "I", for interface guards. However there were some uses of the same form of name for typescript interfaces. Because interfaces and interface guards are adjacent concepts, this could be confusing. This PR fixes this for endo. The companion Agoric/agoric-sdk#10751 fixes it for agoric-sdk. Because the endo names in question were not exported, there is clearly no dependency between these two PRs. ### Security Considerations Consistent naming conventions makes code more reviewable, which is good for security. ### Scaling Considerations none ### Documentation Considerations Consistent naming conventions helps documentation and its readers. ### Testing Considerations none ### Compatibility Considerations Because these names are not exported, and are only type names erased prior to execution, none. ### Upgrade Considerations Because these are only type names that are erased prior to execution, none.
closes: #XXXX
refs: endojs/endo#2666
Description
We generally use names of the form
^([A-Z]\w*)I$
, i.e., identifiers beginning with a capital letter and ending with a lone capital "I", for interface guards. However there were some uses of the same form of name for typescript interfaces. Because interfaces and interface guards are adjacent concepts, this could be confusing. This PR fixes this for agoric-sdk. The companion endojs/endo#2666 fixes it for endo. Because the endo names in question were not exported, there is clearly no dependency between these two PRs.Security Considerations
Consistent naming conventions makes code more reviewable, which is good for security.
Scaling Considerations
none
Documentation Considerations
Consistent naming conventions helps documentation and its readers.
Testing Considerations
none
Compatibility Considerations
Unlike endojs/endo#2666, the type names in question here are exported by their respective modules (and likely packages), so in theory it is possible to break code outside agoric-sdk that depends on these type names. Because these are only type names that are erased prior to execution, this mismatch could only cause static problems, not runtime problems.
Further, the names in question seem only intended as helper types for defining other types. Likely, and dependence outside agoric-sdk will only be to those outer types, not to these helper types, in which case an actual compat problem is unlikely. But possible.
Upgrade Considerations
Because these are only type names that are erased prior to execution, none.