-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
feat(eslint-plugin): [no-unnecessary-condition] flag unnecessary type predicates based on assignability #11735
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
base: main
Are you sure you want to change the base?
feat(eslint-plugin): [no-unnecessary-condition] flag unnecessary type predicates based on assignability #11735
Conversation
|
Thanks for the PR, @azat-io! typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community. The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately. Thanks again! 🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint. |
✅ Deploy Preview for typescript-eslint ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
View your CI Pipeline Execution ↗ for commit e1abd45
☁️ Nx Cloud last updated this comment at |
|
|
||
| { | ||
| code: ` | ||
| const items: number[] | null = [1, 2, 3]; |
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.
You'll want to do it like this, I think, here and elsewhere:
| const items: number[] | null = [1, 2, 3]; | |
| declare const items: number[] | null; |
TS ignores the | null because it can see that it's not null (playgroun)
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.
Done ✅
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.
If I replace this entire diff with
- if (typeOfArgument === typeGuardAssertedArgument.type) {
+ if (
+ checker.isTypeAssignableTo(
+ typeOfArgument,
+ typeGuardAssertedArgument.type,
+ )
+ ) {(which is what was intended in #11716 (comment)), the only test case that doesn't pass (apart from spurious reasons) is
function processArray(arr: readonly string[]) {
if (Array.isArray(arr)) {
return arr.length;
}
}So, I'm still thinking that changing to the assignability API makes sense, at least as a first step. In other words, let's take on the assignability API change before worrying about the edge case of readonly arrays with Array.isArray() (which, FWIW, I think is basically a corollary of microsoft/TypeScript#17002). What do you think?
Also cc @ronami
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.
Done! Changed to use checker.isTypeAssignableTo() for Array.isArray
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.
@azat-io almost! I really mean the entire diff, though, not just the Array.isArray case. The thought is to change all unnecessary type predicate detection to be based on assignability.
Note that this change would require accompanying report message changes and additional testing
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.
Done! Changed to use isTypeAssignableTo() for all type predicates. Removed isArrayIsArrayCall() function and updated the tests accordingly.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #11735 +/- ##
=======================================
Coverage 90.66% 90.67%
=======================================
Files 518 518
Lines 52444 52478 +34
Branches 8690 8701 +11
=======================================
+ Hits 47548 47584 +36
+ Misses 4882 4880 -2
Partials 14 14
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
Array.isArray calls
kirkwaiblinger
left a comment
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 time to do a fully detailed review right now, but jotting down the notes that I'll want to come back to. Feel free to look into these in the meantime:
- We'll probably need to update the text of the typeGuardAlreadyIsType message.
- The
getConstrainedTypeAtLocationmay actually be wrong/unnecessary now. Needs tests with generics to prove one way or another. - Like with no-unsafe-type-assertion, we should double-check and add testing around object literals and excess property checking.
- Needs further tests around subtype cases.
a9234f9 to
5bb6d0a
Compare
…rray.isArray` calls
…ableTo` API for `Array.isArray` checks
7224f53 to
c0cfba1
Compare
c0cfba1 to
e1abd45
Compare
|
Dialed the change back to focus solely on |

PR Checklist
Overview
Adds detection of redundant Array.isArray() calls when checkTypePredicates is enabled.
Reports error when the argument is already typed as an array (including readonly arrays).