Parse error on arrow function with type parameters

[mightyiam]

What version of TypeScript are you using?

2.5.3

What version of typescript-eslint-parser are you using?

8.0.0

What code were you trying to parse?

<T>() => {
  return null
}

What did you expect to happen?

Happy happy parse parse. I notice we have this fixture but... error.

What happened?

/home/shahar/src/pick-path/src/parsing-error.ts
  2:2  error  Parsing error: Expression expected

✖ 1 problem (1 error, 0 warnings)

[JamesHenry]

Hmm interesting. It seems like this was a genuine parse error in TypeScript 2.4.x (i.e. nothing to do with this parser)

http://astexplorer.net/#/gist/69f89d5c7455a7713684a53d49bdf7b1/51082ff9da1db4f52d729a17d1cf8b70b52e9ae7

...but the TypeScript playground, which is using 2.5.x, does not complain.

It is odd slightly code in isolation I must say 😄 Do you have a more complete example of the context in which this was used?

[JamesHenry]

I also cannot seem to reproduce this error on master of this project, using TypeScript 2.5.3. When I set up a spec containing the source code you have provided, it seems to be able to produce an AST and does not throw.

Please can you see if you can reproduce?

[mightyiam]

Here is my actual use:
https://github.com/mightyiam/pick-path/pull/16.

[JamesHenry]

Ah, I see, using it as the value of a declaration makes sense 😄 I figured you couldn't have been using it in isolation like that.

Thanks for following up, I will investigate this further

[JamesHenry]

This must be something to do with your full setup, because your source code does not produce a parse error in the latest version of this parser using TypeScript 2.5.3.

As you pointed out, we do already have a fixture which covers this as well. I will see if I can see anything obvious in your setup as a whole.

[JamesHenry]

It seems like this will need to be investigated in your project https://github.com/mightyiam/eslint-config-standard-with-typescript? Have you tried narrowing down the issue in there and tweaking the config to get the minimal possible repro?

It might well be one of the custom rules from eslint-plugin-typescript is the root cause of this...

[mightyiam]

I'll do a minimal reproduction PR in this project.

[mightyiam]

The following code is all that it takes to trigger the error:

<T>(): T => {}

The error in this case is:

file: 'file:///home/shahar/src/pick-path/src/index.ts'
severity: 'Error'
message: 'Parsing error: JSX element 'T' has no corresponding closing tag.'
at: '1,1'
source: 'eslint'

When I remove from .eslintrc.json the property:

  "extends": "eslint-config-standard-with-typescript"

There is no error. Also, extending from eslint:recommended, also gives no error. Any clues here?

[mightyiam]

A JSX parser... Where? How?

[mightyiam]

This seems to avoid the error:

  "parserOptions": {
    "ecmaFeatures": {
      "jsx": false
    }
  }

[j-f1]

It appears to be interpreting the code like this:

<T> // JSX opening element
(): T => // raw JSX text
{} // an empty JSX expression container
// [!] missing </T> closing element

Given that this error is thrown by the TypeScript parser, it appears to be an issue with TypeScript itself, not just this plugin.

[JamesHenry]

JSX support in TypeScript is the underlying point here.

I can see that the underlying eslint-config-standard you are inheriting from is setting jsx: true. In this parser we have to use that flag to determine whether or not to configure the actual TypeScript compiler to parse the source as JSX.

When the TypeScript compiler parses the <Value> syntax in "JSX mode" it is ambiguous and could be a JSXElement as far as it's concerned.

This is the same reason you cannot use the <> syntax for type assertions in TSX files, you have to use the as syntax.

So yeah, if you want to inherit from that config, you have to accept that you are always in "JSX mode" in TypeScript, working in the same way as if all of your source files were .tsx, and so you cannot use any ambiguous constructs.

In your original code, even in "JSX mode", the TypeScript compiler is clearly able to determine that the <> syntax is unambiguously being used for type parameters and it does not have a problem with it:

function pickPath<Value> (
  path: string,
  routes: Routes<Value>,
  parentPattern = ''
): Match<Value> {

It's possible that the TypeScript team may be able to add in handling for your use-case here, but you would need to report it to them on the main TypeScript repo. It might not be possible.

I am going to close this issue as this project is not causing your error. You can either solve it by using unambiguous code (as far as TypeScript in "JSX mode" is concered), or by overriding the parserOptions as you have noted.

[mightyiam]

Great job explaining, @JamesHenry. Thank you.

[JamesHenry]

No worries 😄 Thanks for supporting this project!