Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork2.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 ourterms of service andprivacy 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?
Uh oh!
There was an error while loading.Please reload this page.
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 onhttps://opencollective.com/typescript-eslint. |
netlifybot commentedNov 3, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
✅ Deploy Preview fortypescript-eslint ready!
To edit notification comments on pull requests, go to yourNetlify project configuration. |
nx-cloudbot commentedNov 3, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
View yourCI Pipeline Execution ↗ for commite1abd45
☁️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:
| constitems:number[]|null=[1,2,3]; | |
| declareconstitems: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
functionprocessArray(arr:readonlystring[]){if(Array.isArray(arr)){returnarr.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 ofreadonly arrays withArray.isArray() (which, FWIW, I think is basically a corollary ofmicrosoft/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 usechecker.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 useisTypeAssignableTo() for all type predicates. RemovedisArrayIsArrayCall() function and updated the tests accordingly.
codecovbot commentedNov 3, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
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 to5bb6d0aCompare…rray.isArray` calls
…ableTo` API for `Array.isArray` checks
7224f53 toc0cfba1Comparec0cfba1 toe1abd45Compareazat-io commentedNov 9, 2025
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).