-
Notifications
You must be signed in to change notification settings - Fork 41
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
fix: no longer removing Map or Set type when they are needed #1520
fix: no longer removing Map or Set type when they are needed #1520
Conversation
6a6c5ae
to
0d3d550
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1520 +/- ##
==========================================
+ Coverage 78.62% 78.68% +0.05%
==========================================
Files 175 175
Lines 10957 10968 +11
Branches 1021 1026 +5
==========================================
+ Hits 8615 8630 +15
+ Misses 2338 2334 -4
Partials 4 4
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
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 is a good start but there are some tricky edge cases that I worry might make this a lot more complex than it seems. Good luck! ✨
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.
[Testing] A few more cases come to mind...
let stringMapTyped: Map<string, string | number> = new Map<string, number>();
: should keep the type annotation, I think?ReadonlyMap
- Custom generic classes like
class MyMap<K, V> { ... }
type
aliases
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.
Nice! thanks. And I agree this is more complex, I just touched surface. 😅
Co-authored-by: Josh Goldberg ✨ <[email protected]>
Comparing ts.Types of code like this If you look this tool https://ts-ast-viewer.com/#code/MYewdgzgLgBNBOBLMBzAygUygLhpqAPAsigHwwC8MYGA7nlgBQCUA3EA and then compare the inferred type of For Map this is different. Same comparisation in that tool tells us that the types are |
case "RegExp": | ||
return initializer.kind === ts.SyntaxKind.RegularExpressionLiteral; | ||
} | ||
if (ts.isRegularExpressionLiteral(declaration)) { |
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.
This is not related to the issue, but I think it's easier to read and understand this way.
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 preference on my end 😄
return false; | ||
} | ||
|
||
for (let i = 0; i < declarationTypeArguments.length; i += 1) { |
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 should be only one type argument in Set, but I copied this code from above.
|
||
export const declaredInitializedTypeNodeIsRedundant = ( | ||
request: FileMutationsRequest, | ||
declaration: ts.TypeNode, | ||
initializer: ts.Node, | ||
) => { | ||
): boolean | undefined => { |
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 wonder should this method always return boolean? From the usage, it's always used in if check, so it does not really matter that it also returns undefined. But on the other hand, it could return false in those cases.
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 don't have a hard preference either way 😄
>(); | ||
const stringMapTyped = new Map<string, number>(); | ||
const anyMap = new Map(); | ||
const anySet: Set<any> = new Set(); |
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.
This could lose it's type declaration. But I think it would need it's own custom logic for this special case.
I added |
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.
Looks great to me, thanks!
I've context switched away from TypeStat for a bit to focus on ESLint stuff. Sorry that reviewing is taking a while. But I'm still very excited you're looking at all this! 🙌
PR Checklist
status: accepting prs
Overview
I'm not sure that this is correct place to place this code. It's also maybe too heavy handed. But on the other hand, I think it's better to prevent cases where we introduce implicit anys when there was some type earlier. Keeping types that could have been removed, is less bad in that case.
I have tried to find what would be right place to do this check but I did not have any luck.