eslint: arrow-parens crashes when parsing typescript function with generics

Tell us about your environment

Node version: v10.15.3
npm version: v6.12.0
Local ESLint version: v6.6.0 (Currently used)

What parser (default, Babel-ESLint, etc.) are you using? @typescript-eslint/parser Please show your full configuration:

Configuration

What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.

const useABTests = <T extends ABTests, TName extends Extract<keyof T, string | number>>() => {
 ...
}

What did you expect to happen?

What actually happened? Please include the actual, raw output from ESLint. the arrow-parens rule for above code detects firstTokenOfParam as < and that is incorrect. As result of this, later on, when asserting the rule, it does:

!astUtils.isOpeningParenToken(firstTokenOfParam)
 // return token.value === "(" && token.type === "Punctuator";

and it marks the typescript code as breaking the rule settings, so it tries to log the error message, but it will fail, since getLocation helper always grabs starting location from params array that in this case is undefined, resulting in crash

TypeError: Cannot read property 'loc' of undefined

Are you willing to submit a pull request to fix this bug? Yeah, I’ve been looking at the code and with small guidance I could maybe do the fix

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 1
  • Comments: 20 (9 by maintainers)

Commits related to this issue

Most upvoted comments

I’ll work on this.

That’s great! You can find an example here. Please feel free to ask questions here or to stop by our Gitter chat.

I think that some similar refactorings to indirectly avoid problems with typescript code were being accepted before?

Yes.

Do you by any chance have example PR of such refactor I could refer to? I’d like to contribute and seems like its a good starting issue

Maybe we could change the rule to:

  • Check the number of params before anything else. If it isn’t exactly 1 then the parens are mandatory and must be already there in the code, so there is no need to continue and do anything?
  • To find out is that 1 param wrapped in parens, check the first token on the param node’s left side. It should be an opening paren within the range of the arrow function.

I think that some similar refactorings to indirectly avoid problems with typescript code were being accepted before?