Skip to content

Prefer type imports in import/no-duplicates #3185

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Mrazator opened this issue May 2, 2025 · 4 comments
Open

Prefer type imports in import/no-duplicates #3185

Mrazator opened this issue May 2, 2025 · 4 comments

Comments

@Mrazator
Copy link

Mrazator commented May 2, 2025

It's possible to auto-fix detected duplicated import types as inline types with import/no-duplicates ("prefer-inline": true), but it's not possible to keep type imports as they are.

Therefore, import/no-duplicate should be extended to prefer type imports when fixing duplicates

❌ Invalid ["error", {"prefer-type-imports": true}]

import { AValue, type AType, type BType } from './mama-mia'

import { CValue, type CType } from './papa-mia'

✅ Valid with ["error", {"prefer-type-imports": true}]

import { AValue, } from './mama-mia'
import type { AType , BType } from './mama-mia'

import { CValue } from './papa-mia'
import type { CType } from './papa-mia'
@dwelle
Copy link

dwelle commented May 7, 2025

import { AValue, } from './mama-mia'
import type { AType , BType } from './mama-mia'

import { CValue } from './papa-mia'
import type { CType } from './papa-mia'

IMO this is fine, too.

@ljharb
Copy link
Member

ljharb commented May 9, 2025

I'm confused, why would you want the two separate import statements?

@Mrazator
Copy link
Author

Mrazator commented May 9, 2025

Multiple reasons, in general they serve different purpose and have different characteristics.

Regular imports influence both build time (bundlers) and runtime, so we have to be careful about those. It matters what you import from where, while for types it does not matter that much (i.e. circular dependencies are fine).

Mixing the two in one import statement could lead to accidental runtime imports, which could cause headaches later on (i.e. circular dependencies, browser-only code included in server-only bundles, unnecessary large browser / server bundles, etc.).

Separating the imports also improves overall readability, so it's immediately obvious which abstractions (types) your module depends on, as you don't have to find it somewhere inside a regular import.

Is also allows us to specify specific rules for regular imports (like package A can't import from package B), while tolerating type imports e.g.:

 "@typescript-eslint/no-restricted-imports": [
  "error",
  {
    "patterns": [
      {
        "group": ["../../excalidraw", "../../../packages/excalidraw", "@excalidraw/excalidraw"],
        "message": "Do not import from '@excalidraw/excalidraw' package anything but types, as this package must be independent.",
        "allowTypeImports": true
      }
    ]
  }
]

@ljharb
Copy link
Member

ljharb commented May 9, 2025

and if you set prefer-inline to false, what happens?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants