Enhancement: add experimentalDecorators option to typescript-estree

[sosukesuzuki]

Before You File a Proposal Please Confirm You Have Done The Following...

• I have searched for related issues and found none that match my proposal.
• I have searched the current rule list and found no rules that match my proposal.
• I have read the FAQ and my problem is not listed.

Relevant Package

typescript-estree

My proposal is suitable for this project

• I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Description

What:
Adds experimentalDecorators option to @typescript-eslint/typescript-estree.
It just corresponds to experimentalDecorators in TS compiler options.

Why:
Since TypeScript 5.0, ECMAScript decorators are implemented; we can switch between them using experimantalDecortors in the compiler options.

There is no way to switch it on in typescript-estree except by specifying tsconfig.json by project.

It would be helpful to have experimentalDecorators as a parsing option, like the already existing jsx option.

Fail

// N/A

Pass

// N/A

Additional Info

I think we can avoid breaking changes by setting the default value of this option to true. (And, we can change it to false at next major version)

[bradzacher]

Is there a syntax difference between the two of them, or just a semantic difference?
If it's just the latter - then there's no need for an option because the only time the difference would impact things is type-aware parsing, which needs a tsconfig.

If it's the former, then we can look into it.

[sosukesuzuki]

There is syntax difference between the two of them.

For example, the following decorator is valid as experimental decorators, but is invalid as ES decorators.

declare const special: any;

class Foo {
  bar(@special(true) { bar }: any) {}
}

Experimental decorators playground
ES decorators playground

[bradzacher]

Sorry - to clarify I meant semantic/syntactic in the TS sense, i.e. for a syntactic error the TS parser would hard-error, but for a semantic error the parser does not error (but TS itself will emit an error).

Looking at your example - the decorator positioning is (currently at least) a semantic error, not a syntactic one.
I don't think it's necessary for us to add a parser option to cause us to error on the old, invalid position. I don't think we gain anything from that because we still need to support it from an AST perspective, and rules still need to support linting them.

I think us just supporting everything and having TS semantically error on the user's code is the best course of action for now - over time TS will remove the experimental flag and we'll stop parsing it naturally.

[sosukesuzuki]

@bradzacher Ah I got it, thank you. So what do you think about #6570 (comment)? Should we default this option to trure? Or should it be false?

[sosukesuzuki]

#6570 (comment)