Skip to content
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

feat(eslint-plugin): [no-unneccessary-conditions] add option to check array predicate callbacks #1206

Merged
merged 6 commits into from Jan 7, 2020

Conversation

Retsam
Copy link
Contributor

@Retsam Retsam commented Nov 14, 2019

Implements #1038 for no-unnecessary-condition.

The flow is:

  • Find places where methods called filter, find, some, and every are being called, via syntax analysis
  • Do type checking on the target of those methods to see if it's an array.
  • Special cases if the function is inline: if it's using arrow function shorthand (x => something), or if the body of the function is a single return statement (x => { return something; }), reuse the existing checkNode on the returned value. (This way the linter can just underline something rather than the whole callback)
  • Otherwise check the return type of the callback and determine if it's possibly truthy and falsy.

The function is behind an option flag, default off. When the next major version rolls around, I think it could default to true (or maybe even just remove the flag).


Things to ideally resolve:

  • Better checking of whether the target is an array. Currently just looking for a lastIndexOf property.
  • There's an edge case with generic functions being passed as callbacks:
const isTruthy = <T>(t: T) => T;

// Should be able to error on this because `T` should be inferred as `number[]` which is always truthy.
[[0,1], [2, 3]].filter(isTruthy)

I think it's possible to fix the above, but it's getting deeper into the compiler API that I've been able to figure out.

@typescript-eslint
Copy link
Contributor

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.

@bradzacher bradzacher added the enhancement: plugin rule option New rule option for an existing eslint-plugin rule label Nov 14, 2019
@Retsam Retsam force-pushed the array-methods branch 2 times, most recently from dd3f010 to b27d7e3 Compare November 18, 2019 19:46
@Retsam
Copy link
Contributor Author

Retsam commented Nov 27, 2019

I improved the checking for whether the left-hand-side of (e.g.) .filter is an array type or not - I discovered that there's a built-in API for this, but it's marked as internal; but I used it as a basis to write my own.

Copy link
Member

@bradzacher bradzacher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code LGTM - RC on the comment and merge conflicts

@bradzacher bradzacher added the awaiting response Issues waiting for a reply from the OP or another party label Dec 19, 2019
@codecov
Copy link

codecov bot commented Jan 7, 2020

Codecov Report

Merging #1206 into master will increase coverage by <.01%.
The diff coverage is 95.65%.

@@            Coverage Diff             @@
##           master    #1206      +/-   ##
==========================================
+ Coverage   94.58%   94.58%   +<.01%     
==========================================
  Files         140      140              
  Lines        6034     6057      +23     
  Branches     1712     1723      +11     
==========================================
+ Hits         5707     5729      +22     
  Misses        181      181              
- Partials      146      147       +1
Impacted Files Coverage Δ
...slint-plugin/src/rules/no-unnecessary-condition.ts 99.01% <95.65%> (-0.99%) ⬇️

@Retsam Retsam requested a review from bradzacher January 7, 2020 16:03
@Retsam
Copy link
Contributor Author

Retsam commented Jan 7, 2020

For backwards compatibility purposes, this is behind an option that defaults to false. I think it'd be good to change that for v3, either to have the option default to true, or else to remove the option and just have this be non-configurable behavior.

Any thoughts on which would be better here? I think I'm leaning towards non-configurable: this seems pretty unopinionated and shouldn't impose too much runtime cost to check, but maybe letting it be an option is more in-line with eslint's configuration philosophy?

@bradzacher bradzacher removed the awaiting response Issues waiting for a reply from the OP or another party label Jan 7, 2020
Copy link
Member

@bradzacher bradzacher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - thanks for this

@bradzacher bradzacher merged commit f7ad716 into typescript-eslint:master Jan 7, 2020
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 20, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement: plugin rule option New rule option for an existing eslint-plugin rule
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants