feat(eslint-plugin): [no-unnecessary-condition] ignore basic array indexing false positives #1534
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Adds a special case to suppress "unnecessary condition" errors on code like:
```ts
function example(arr: number[]) {
// type is number, but could be undefined
if(arr[0]) {
//...
}
}
```
|
Thanks for the PR, @Retsam! 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. As a thank you, your profile/company logo will be added to our main README which receives thousands of unique visitors per day. |
Codecov Report
@@ Coverage Diff @@
## master #1534 +/- ##
=========================================
+ Coverage 95.19% 95.2% +0.01%
=========================================
Files 148 148
Lines 6971 6989 +18
Branches 2010 2017 +7
=========================================
+ Hits 6636 6654 +18
Misses 124 124
Partials 211 211
|
|
Addressed one more edge-case. Since tuple types are sound when indexing with literal numbers, there's no need to suppress potential errors. const tuple = [{}];
// Should raise an error here: this check is definitely unnecessary
if(tuple[0]) {}
declare const n: number;
// Should not raise an error here, this is equivalent to a normal array index.
if(tuple[n]) {} |
bradzacher
requested changes
Feb 19, 2020
packages/eslint-plugin/tests/rules/no-unnecessary-condition.test.ts
Outdated
Show resolved
Hide resolved
This was referenced Mar 26, 2020
Merged
Merged
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As discussed here, a current pain-point with no-unnecessary-condition is that array indexes are often a source of false positives because the types don't represent the possibility of an out-of-bounds error.
This adds a check to ignore code like:
This version only handles the "obvious" case where the index signature is directly inside the condition - it will still raise errors on code like:
I believe fixing this would be possible, but I'm not sure it's worth the complexity of implementation.
I considered making this configurable, but I just can't come up with any cases in which you'd actually want the previous behavior. Unlike the object case, I don't think anyone is realistically going to model their arrays as
Array<T | undefined>for the sake of safe index checks.This I don't think this is considered a breaking-change - all previously valid code is still valid - but if so, I'd rather point at 3.0 than put it behind a temporary option flag.
Fixes #1544