chore: Fix type import specifier linting#175
Merged
Conversation
rekmarks
added a commit
to MetaMask/eslint-config
that referenced
this pull request
Feb 28, 2025
Ref: MetaMask/ocap-kernel#175 This replaces `@typescript-eslint/consistent-type-imports` with `import-x/consistent-type-specifier-style`, and an exhortation to enable `verbatimModuleSyntax` (requires TypeScript >=5) in the tsconfigs of our packages. Heretofore, we have enforced the existence of type import specifiers, but not that they are stylistically consistent. The options are: - "top-level", e.g. `import type { a } from 'x'}` - "inline", e.g. `import { type a } from 'x'}` The rule `@typescript-eslint/consistent-type-imports` has been responsible for this. This rule has an option named `fixTypes`, but that only applies when a type-only import is _not_ specified as a type-only import. In other words, it enforces the existence of type import specifiers, but not that they're stylistically consistent. Rather than using `@typescript-eslint/consistent-type-imports` and its confusingly named options, we are better off enabling `verbatimModuleSyntax` in our `tsconfig` files, and enabling `import-x/consistent-type-specifier-style`. In this way, the existence of type import specifiers is enforced by `tsc`, and the `import-x` ESLint plugins ensures that they are consistent. We use the "top-level" style because that results in `import type { a } from 'x';` being elided completely from the JS output as opposed to `import { type a } from 'x';` which would be emitted as `import {} from 'x';`. I don't know if that's actually harmful, but it seems surprising, and I don't like surprises. Supporting documentation: - `@typescript-eslint/consistent-type-imports` [rule documentation](https://typescript-eslint.io/rules/consistent-type-imports/#comparison-with-importsnotusedasvalues--verbatimmodulesyntax) - [The `verbatimModuleSyntax` docs](https://www.typescriptlang.org/tsconfig/#verbatimModuleSyntax) - This tseslint issue: typescript-eslint/typescript-eslint#9652
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR reconfigures our
tsconfigfiles and ESLint config to enforce consistent type import specifiers and better type elision behavior.Heretofore, we have enforced the existence of type import specifiers, but that they are stylistically consistent. The options are "top-level" (
import type { a } from 'x'}) and "inline" (import { type a } from 'x'}). This was enforced using the ESLint rule@typescript-eslint/consistent-type-imports. This rule has an option namedfixTypes, but that only applies when a type-only import is not specified as a type-only import. In other words, it enforces the existence of type import specifiers, but not that they're stylistically consistent.After consulting the rule documentation, the TypeScript docs, and typescript-eslint/typescript-eslint#9652, I determined that we are better off enabling
verbatimModuleSyntaxin ourtsconfigfiles, and replacing@typescript-eslint/consistent-type-importswithimport-x/consistent-type-specifier-style. In this way, the existence of type import specifiers is enforced bytsc, and theimport-xESLint plugins ensures that they are consistent. We use the "top-level" style because that results inimport type { a } from 'x';being elided completely from the JS output as opposed toimport { type a } from 'x';which would be emitted asimport {} from 'x';. I don't know if that's actually harmful, but it seems surprising, and I don't like surprises.