-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Closed
Description
In both flow and TS you can mark an import as a type (or typeof for flow) via a specifier.
Both languages support two forms:
top-level, which marks all names in the import as type-only:
import type Foo from 'Foo';
import type {Bar} from 'Bar';
// ts only
import type * as Bam from 'Bam';
// flow only
import typeof Baz from 'Baz';
inline, which marks just one name in the import as type-only:
import {type Foo} from 'Foo';
// flow only
import {typeof Bar} from 'Bar';
Users care about consistency when it comes to the use of inline type imports - they either want them, or they don't.
I would like to propose a rule which enforces either for, or against the use of inline type specifiers.
The rule would have an option which would enforce one way or another, i.e.
type Options = [
'perfer-inline' | 'prefer-top-level',
];
Examples
✅ Valid always
import type Foo from 'Foo'; // default specifiers are always good
import type * as NS from 'Bar'; // namespace specifiers are always good
✅ Valid with prefer-top-level
, but ❌ Invalid with prefer-inline
import type {Foo} from 'Foo';
import type Foo, {Bar} from 'Foo';
// flow only
import typeof {Foo} from 'Foo';
❌ Invalid with prefer-top-level
, but ✅ Valid with prefer-inline
import {type Foo} from 'Foo';
import Foo, {type Bar} from 'Foo';
// flow only
import {typeof Foo} from 'Foo';
Fixer
For prefer-top-level
:
import {Foo, type Bar, typeof Baz} from 'Foo';
// becomes
import {Foo} from 'Foo';
import type {Bar} from 'Bar';
import typeof {Baz} from 'Baz';
For prefer-inline
:
import type {Foo, Bar} from 'Foo';
// becomes
import {type Foo, type Bar} from 'Foo';
import type Foo, {Bar} from 'Foo';
// becomes
import type Foo from 'Foo';
import {type Bar} from 'Foo';
Note that the fixer need not necessarily concern itself with de-duplicating the imports, as import/no-duplicates
can be turned on by the user to handle that concern.
Niznikr