[consistent-type-specifier-style] should support mixed style

[latin-1]

With "importsNotUsedAsValues": "error" in tsconfig.json, import { type T } is no longer a valid TypeScript code.

I hope there could be a code fix:

import { type A, type B } from "./mod";
// ↓
import type { A, B } from "./mod";

while still preserve this as-is:

import { A, type B } from "./mod";

Valid Code

import { A, B } from "./mod"; // for normal imports
import { type A, B } from "./mod"; // for mixed imports
import type { T } from "./mod"; // for type-only imports

TypeScript Compiler Behavior

"importsNotUsedAsValues": "remove"

import type { T } from "./mod";
// ↓
export {};

import { type T } from "./mod";
// ↓
export {};

"importsNotUsedAsValues": "error"

import type { T } from "./mod";
// ↓
export {};

// @ts-expect-error ts(1371)
import { type T } from "./mod";
// ↓
import "./mod";

[latin-1]

cc @bradzacher

[bradzacher]

Currently the entire point of the rule is to enforce that either you always use top-level type imports OR you always use inline imports.

If you want to mix-and-match and use both instead you can just use import/no-duplicates by itself which can enforce that you only have one import of a module, which will enforce the mixed style.

TS itself will fully prevent the one missing case of "single inline specifier", so I don't think an extra lint rule makes sense for that?

Also note that both babel and TS treat the single inline specifier case the same at compile time - they simply do not emit an import.

[latin-1]

@bradzacher

Also note that both babel and TS treat the single inline specifier case the same at compile time - they simply do not emit an import.

For Babel, there's a corresponding option to importsNotUsedAsValues: onlyRemoveTypeImports.
With importsNotUsedAsValues: "error" or onlyRemoveTypeImports: true, import { type T } will emit an import statement.

I believe there is a bug in Babel related to onlyRemoveTypeImports option. I will open an issue on Babel later.

[latin-1]

babel/babel#15348
I opened an issue on the Babel side. I believe it should not remove the entire import statement. tsc does not do it either.

[latin-1]

@bradzacher You can try it yourself.

// tsconfig.json
{
  "compilerOptions": {
    "module": "ESNext",
    "isolatedModules": true,
    "importsNotUsedAsValues": "error"
  }
}

// index.ts
import { type T } from "./mod";

// mod.ts
export type T = number;

Output

// index.js
import "./mod";

// mod.js
export {};

[ljharb]

I'm not sure why you wouldn't want it to remove those statements - while the import one might have side effects, tooling pretty universally assumes that if there's a binding, there's no side effects, and the export line is a noop.

[latin-1]

@ljharb

I'm not sure why you wouldn't want it to remove those statements

This decision is made by TypeScript team. I have no control over it.

and the export line is a noop

With isolatedModules, tsc compiles
transpiles one file at a time. It has no knowledge of other files.

[bradzacher]

Honestly - you shouldn't be using import rules (import/ or @typescript-eslint/) alongside this TS compiler option.

The TS compiler option is subject to change by the TS team at any time. Trying to design a set of lint rules that work in concert with logic that could change is really difficult - esp when any discrepancies between them can cause build errors or changes in runtime behaviour.

IMO use one or the other.
My personal preference would be to avoid the TS compiler option as the output it creates is (IMO) very bad because it causes type-only imports to runtime have side-effects.

[latin-1]

My personal preference would be to avoid the TS compiler option as the output it creates is (IMO) very bad because it causes type-only imports to runtime have side-effects.

microsoft/TypeScript#47118 (comment)

• import type operates at the ImportDeclaration level
• import { type ... } operates at the ImportSpecifier level
• importsNotUsedAsValues operates at the ImportDeclaration level (this is the one that’s easy to mix up)

FYI there's a new option named verbatimModuleSyntax basically does the same thing.

microsoft/TypeScript#51479

Please also take a look into the background sections in the link above. There are multiple real-world use cases for those options.

[latin-1]

Trying to design a set of lint rules that work in concert with logic that could change is really difficult - esp when any discrepancies between them can cause build errors or changes in runtime behaviour.

I agree with you. That's why I propose to add this feature into @typescript-eslint first.

IMO @typescript-eslint should follow the TypeScript compiler's behavior.

[latin-1]

Again, type specifiers are not something that only related to style. It solves many transpile problems like re-export a type, which cannot be done by static-analyzing on a single file (isolatedModules).

[latin-1]

For example:

export { A, B } from "./mod";

Which parts of code should be elided?

[latin-1]

My personal preference would be to avoid the TS compiler option as the output it creates is (IMO) very bad because it causes type-only imports to runtime have side-effects.

It's only about your personal preference. You can't represent so anyone.

[bradzacher]

We in @typescript-eslint don't want to try to follow TS behaviour with things like this because it means we have to maintain the branches as it changes over versions.

Its a huge amount of work to maintain. We've tried it before with decorator metadata and it's the first and last time we'll be attempting to match TS implementation for something.