🌐 AI搜索 & 代理 主页
Skip to content

Commit d3cdf95

Browse files
bradzacheryeonjuan
bradzacher
authored and
yeonjuan
committed
feat(eslint-plugin): [consistent-type-imports] ignore files with decorators, experimentalDecorators, and emitDecoratorMetadata (typescript-eslint#8335)
1 parent 2af2fb7 commit d3cdf95

36 files changed

+2578
-5283
lines changed

‎docs/packages/Parser.mdx‎

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -40,6 +40,7 @@ interface ParserOptions {
4040
};
4141
ecmaVersion?: number | 'latest';
4242
emitDecoratorMetadata?: boolean;
43+
experimentalDecorators?: boolean;
4344
extraFileExtensions?: string[];
4445
jsDocParsingMode?: 'all' | 'none' | 'type-info';
4546
jsxFragmentName?: string | null;
@@ -128,6 +129,12 @@ Specifies the version of ECMAScript syntax you want to use. This is used by the
128129
129130
This option allow you to tell parser to act as if `emitDecoratorMetadata: true` is set in `tsconfig.json`, but without [type-aware linting](../getting-started/Typed_Linting.mdx). In other words, you don't have to specify `parserOptions.project` in this case, making the linting process faster.
130131

132+
### `experimentalDecorators`
133+
134+
> Default `undefined`.
135+
136+
This option allow you to tell parser to act as if `experimentalDecorators: true` is set in `tsconfig.json`, but without [type-aware linting](../getting-started/Typed_Linting.mdx). In other words, you don't have to specify `parserOptions.project` in this case, making the linting process faster.
137+
131138
### `extraFileExtensions`
132139

133140
> Default `undefined`.

‎packages/eslint-plugin/docs/rules/consistent-type-imports.mdx‎

Lines changed: 26 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -93,11 +93,34 @@ type T = import('Foo').Foo;
9393
const x: import('Bar') = 1;
9494
```
9595

96-
## Usage with `emitDecoratorMetadata`
96+
## Caveat: `@decorators` + `experimentalDecorators: true` + `emitDecoratorMetadata: true`
9797

98-
The `emitDecoratorMetadata` compiler option changes the code the TypeScript emits. In short - it causes TypeScript to create references to value imports when they are used in a type-only location. If you are using `emitDecoratorMetadata` then our tooling will require additional information in order for the rule to work correctly.
98+
:::note
99+
If you are using `experimentalDecorators: false` (eg [TypeScript v5.0's stable decorators](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-0.html#decorators)) then the rule will always report errors as expected.
100+
This caveat **only** applies to `experimentalDecorators: true`
101+
:::
99102

100-
If you are using [type-aware linting](/getting-started/typed-linting), then you just need to ensure that the `tsconfig.json` you've configured for `parserOptions.project` has `emitDecoratorMetadata` turned on. Otherwise you can explicitly tell our tooling to analyze your code as if the compiler option was turned on [by setting `parserOptions.emitDecoratorMetadata` to `true`](https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/parser/README.md#parseroptionsemitdecoratormetadata).
103+
The rule will **_not_** report any errors in files _that contain decorators_ when **both** `experimentalDecorators` and `emitDecoratorMetadata` are turned on.
104+
105+
> See [Blog > Changes to consistent-type-imports when used with legacy decorators and decorator metadata](/blog/changes-to-consistent-type-imports-with-decorators) for more details.
106+
107+
If you are using [type-aware linting](https://typescript-eslint.io/linting/typed-linting) then we will automatically infer your setup from your tsconfig and you should not need to configure anything.
108+
Otherwise you can explicitly tell our tooling to analyze your code as if the compiler option was turned on by setting both [`parserOptions.emitDecoratorMetadata = true`](https://typescript-eslint.io/packages/parser/#emitdecoratormetadata) and [`parserOptions.experimentalDecorators = true`](https://typescript-eslint.io/packages/parser/#experimentaldecorators).
109+
110+
## Comparison with `importsNotUsedAsValues` / `verbatimModuleSyntax`
111+
112+
[`verbatimModuleSyntax`](https://www.typescriptlang.org/tsconfig#verbatimModuleSyntax) was introduced in TypeScript v5.0 (as a replacement for `importsNotUsedAsValues`).
113+
This rule and `verbatimModuleSyntax` _mostly_ behave in the same way.
114+
There are a few behavior differences:
115+
| Situation | `consistent-type-imports` (ESLint) | `verbatimModuleSyntax` (TypeScript) |
116+
| -------------------------------------------------------------- | --------------------------------------------------------- | ----------------------------------------------------------- |
117+
| Unused imports | Ignored (consider using [`@typescript-eslint/no-unused-vars`](/rules/no-unused-vars)) | Type error |
118+
| Usage with `emitDecoratorMetadata` & `experimentalDecorations` | Ignores files that contain decorators | Reports on files that contain decorators |
119+
| Failures detected | Does not fail `tsc` build; can be auto-fixed with `--fix` | Fails `tsc` build; cannot be auto-fixed on the command-line |
120+
| `import { type T } from 'T';` | TypeScript will emit nothing (it "elides" the import) | TypeScript emits `import {} from 'T'` |
121+
122+
Because there are some differences, using both this rule and `verbatimModuleSyntax` at the same time can lead to conflicting errors.
123+
As such we recommend that you only ever use one _or_ the other -- never both.
101124

102125
## When Not To Use It
103126

0 commit comments

Comments
 (0)