feat(eslint-plugin): [no-unnecessary-condition] flag unnecessary type predicates based on assignability #11735
Conversation
…rray.isArray` calls
|
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. |
|
| Command | Status | Duration | Result |
|---|---|---|---|
nx run-many -t lint |
❌ Failed | 3m 14s | View ↗ |
nx test eslint-plugin --coverage=false |
✅ Succeeded | 5m 11s | View ↗ |
nx run-many -t typecheck |
✅ Succeeded | 2m 5s | View ↗ |
nx run integration-tests:test |
✅ Succeeded | 3s | View ↗ |
nx test eslint-plugin-internal --coverage=false |
✅ Succeeded | 3s | View ↗ |
nx test typescript-estree --coverage=false |
✅ Succeeded | 1s | View ↗ |
nx run types:build |
✅ Succeeded | 5s | View ↗ |
nx run generate-configs |
✅ Succeeded | 7s | View ↗ |
Additional runs (29) |
✅ Succeeded | ... | View ↗ |
☁️ Nx Cloud last updated this comment at 2025-11-03 20:31:34 UTC
|
|
||
| { | ||
| code: ` | ||
| const items: number[] | null = [1, 2, 3]; |
There was a problem hiding this comment.
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.
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.
Done! Changed to use checker.isTypeAssignableTo() for Array.isArray
There was a problem hiding this comment.
@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.
Done! Changed to use isTypeAssignableTo() for all type predicates. Removed isArrayIsArrayCall() function and updated the tests accordingly.
…ableTo` API for `Array.isArray` checks
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 52415 52440 +25
Branches 8678 8686 +8
=======================================
+ Hits 47521 47548 +27
+ Misses 4880 4878 -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:
|
kirkwaiblinger
changed the title
Array.isArray calls
There was a problem hiding this comment.
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.
2 participants
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).