cc @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.

@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.

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.

@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 {};

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.

@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.

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.

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.

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.

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).

For example:

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

Which parts of code should be elided?

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.

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.

Sorry - you misunderstand me.

I don't mean "don't use type specifiers", I mean don't use the TS compiler option. Instead just use the lint rules.

The import/ lint rules will enforce your code style, and the rules @typescript-eslint/consistent-type-imports and @typescript-eslint/consistent-type-exports will do what you need to ensure your code can correctly be transpiled in an "isolated" fashion.

Using rules instead means you can use the default TS/babel behaviour to remove an entire import if it only has inline type specifiers (which is what people expect to happen instead of leaving anonymous imports behind).

For example:

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

Which parts of code should be elided?

@typescript-eslint/consistent-type-exports should handle this case as it is type-aware.

IMO given the possibility of accidental side effectful type imports while using prefer-inline, a mixed option that prefers inline for imports that contain values (not having a type specifier, to prevent the need for type awareness) and prefers top level for ones that only utilise types (again, all having a type specifier) would be ideal.

I'd made a ticket on the TS ESLint plugin to add a rule like this with some motivations listed, but it was closed as not fitting with that rule. Adding it as an option to this rule does seem to make much more sense. With the way TypeScript elides type imports, using inline for type-only imports becomes potentially problematic, but from a code style perspective it's often wanted to keep inline type imports around when there are also value imports in use. Enforcing the mixed style as listed in this issue IMO makes a lot of sense to have as a lint rule.

Given that for whatever reason the TS team decided that (a choice I strongly disagree with, but I digress)

import {type T} from 'Foo';

should transpile to

import 'Foo';

under the new flags releasing in TS5.0 - there's probably going to be more of the community that will want this "prefer inline except if there's only type-only-specifiers" style, so it probably makes sense to add a new option.

oof, what?? That seems very bad. Is there an issue discussing it?

Are you saying, then, that in this case the rule should enforce import type { T } from 'Foo';, so the entire statement is elided by TS?

I support the usage of --verbatimModuleSyntax. Under this mode, you can predictably know the JS emit of import/export statement without looking at the rest of the file or cross-file knowledge (tsc will type check it).

But as soon as they were available, and consistently since then, we have seen enthusiasm for adopting type-only imports everywhere possible as an explicit marker of what imports will survive compilation to JS.

(microsoft/TypeScript#51479)

It's necessary to support this issue, after TS 5.0, --verbatimModuleSyntax will be widely adopted by the today's users of --importsNotUsedAsValues

microsoft/TypeScript#51479 is the issue and from the looks of it, it's entirely intentional and will not change.

I personally disagree with it, but that's neither here nor there. The behaviour is behind a flag which isn't required for people to use, so it is optional behaviour for people to opt into.

So yeah there probably needs to be an option which does the following:

// valid
import 'mod';
import * as mod from 'mod';
import type * as mod from 'mod';
import Foo from 'mod';
import type Foo from 'mod';
import {Bar} from 'mod';
import type {Bar} from 'mod';
import Foo, {Bar} from 'mod';
import Foo, {type Bar} from 'mod';
import {Bar, Baz} from 'mod';
import {type Bar, Baz} from 'mod';

// invalid
import {type Bar} from 'mod';

Though TBH I don't actually see this a good option to the rule. It doesn't really enforce anything any more - it simply ensures that you don't use inline type specifiers if they're the only specifier. To me that makes it feel like it should be a new rule entirely because it's no longer about being consistent and using the same style.

I think that the correct course of action is as follows:

1. add a new lint rule which bans imports that have no value specifiers, and only type specifiers
2. anyone who wishes to use inline type specifiers by default and NOT use the TS flag, use import/consistent-type-specifier-style together with import/no-duplicates with the {"prefer-inline": true} config.
3. anyone who wishes to use inline type specifiers by default AND use the TS flag, just use import/no-duplicates with the {"prefer-inline": true} config in conjunction with the new rule from (1)
4. anyone who wishes to use top-level type specifiers by default (with or without the TS flag), use import/consistent-type-specifier-style together with import/no-duplicates with the {"prefer-inline": false} config.

Note - I'd be happy for the new rule from (1) to live in @typescript-eslint, given that it is solely focused on TS behaviour AND it exists due to the way that a TS compiler flag works.

I think your plan is correct, and I think the rule should indeed live in ts-eslint.

Filed typescript-eslint/typescript-eslint#6382

We can close this.