feat(linter): add parserOptions.emitDecoratorMetadata and parserOptions.experimentalDecorators for config file

[mysteryven]

These two options are needed in consistent-type-import.

At first, I think parserOptions is not useful for us, and want to hard-code experimentalDecorators and emitDecoratorMetadata to false directly. But I changed the thought after reading:

1. https://typescript-eslint.io/blog/changes-to-consistent-type-imports-with-decorators
2. feat(eslint-plugin): [consistent-type-imports] ignore files with decorators, experimentalDecorators, and emitDecoratorMetadata typescript-eslint/typescript-eslint#8335

We don't have type-aware linting for now, and require these two options to decide how we perform: if we have both experimentalDecorators: true and emitDecoratorMetadata: true, then it will not report any errors within any files that contain decorators.

https://github.com/typescript-eslint/typescript-eslint/blob/e408b93e48e5199d83a8d99d1e27126d2dd8bc8f/packages/eslint-plugin/src/rules/consistent-type-imports.ts#L303-L336

[mysteryven]

• feat(linter): add parserOptions.emitDecoratorMetadata and parserOptions.experimentalDecorators for config file #3645 👈
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @mysteryven and the rest of your teammates on Graphite

[graphite-app]

Your org has enabled the Graphite merge queue for merging into main

Add the label “merge” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge. Or use the label “hotfix” to add to the merge queue as a hot fix.

You must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link.

[codspeed-hq]

CodSpeed Performance Report

Merging #3645 will not alter performance

_{Comparing 06-11-feat_linter_add_parserOptions.emitDecoratorMetadata_and_parserOptions.experimentalDecorators_for_config_file (fd30f6f) with main (95e0571)}

Summary

✅ 22 untouched benchmarks

[DonIsaac]

@mysteryven it looks like we've gotten consistent-type-imports shipped, do we still need this PR?

[mysteryven]

it looks like we've gotten consistent-type-imports shipped, do we still need this PR?

Unfortunately, this issue still exists: https://typescript-eslint.io/blog/changes-to-consistent-type-imports-with-decorators/#consistent-type-imports-caused-runtime-breakage, there are some cases are commented out temporarily.

Add parserOptions.* only for this case is not really worthy IMO, it's looks strange. It's OK for me to close this.

Maybe the FrameworkFlags and read something in tsconfig.json is better and more ergonomic?

[mysteryven]

Need a better way.