[no-extra-parens] incorrect behaviour with angle bracket assertions

[waitingsong]

Repro

{
  "rules": {
    "no-extra-parens": 0, 
    "@typescript-eslint/no-extra-parens": 2
  }
}

// type of requestInit is native RequestInit from lib.dom.d.ts
let cookies = (<Headers> requestInit.headers).get('Cookie')

Expected Result
No error

Actual Result
Got error Unnecessary parentheses around expression.eslint(@typescript-eslint/no-extra-parens)
and be changed to below if run eslint --fix

let cookies = <Headers> requestInit.headers.get('Cookie')

Additional Info

Versions

package	version
@typescript-eslint/eslint-plugin	1.13.0
@typescript-eslint/parser	1.13.0
TypeScript	3.5.3
ESLint	6.1.0
node	10.16.0
npm	6.9.0

[waitingsong]

It seems like this #12 .

[bradzacher]

in a way, it's the same bug.
Handling for angle brackets wasn't added because they're old, deprecated syntax and I forgot they existed when I fixed it for as assertions.

[waitingsong]

err.. what time it became deprecated . I have not seen the flag at spec and docs

[bradzacher]

There's a reason that <foo>value is no longer used anywhere else in the docs, and why most codebases don't use it.
It's not truly deprecated, and they won't remove it because the amount of churn that would cause amongst users is huge, and not worth it.

angle bracket assertions conflict with JSX syntax, which is very widely used. It causes people confusion in codebases that don't use JSX because it looks the same as it.

angle bracket assertions also causes confusion with generics, because they use the same tokens to delimit the start/end.
For example in the following case. The first example is very confusing, and looks like malformed XML instead of a valid type assertion. Similarly the second example is confusing and it's hard to tell what is a type assertion and what is a generic usage. Complex examples just get worse.

declare const x: <T>() => T;

const foo = <number>x<string>();
const bar = <() => void>(<T>(arg: T) => {});

Where as the same examples using as assertions is clear, and does not suffer from the same confusion as complexity grows.

declare const x: <T>() => T;

const foo = x<string>() as number;
const bar = (<T>(arg: T) => {}) as () => void;

[waitingsong]

@bradzacher thanks for your reply.

[lonyele]

@bradzacher Hi, I'm not sure if this should be fixed in parser level? bradzacher/eslint-plugin-typescript#130 (comment)

If I just put this code and run debugger, I get A fatal parsing error occurred: Parsing error: JSX element 'Headers' has no corresponding closing tag

let cookies = (<Headers> requestInit.headers).get('Cookie')

[bradzacher]

It's not a parser error. You just have to make sure you don't turn on JSX mode if you're going to be using angle bracket parsing (i.e. don't name files as .tsx, and don't set parserOptions.jsx: true)