-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Comments
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. |
I'm confused, why would you want the two separate import statements? |
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
}
]
}
] |
and if you set |
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}]
✅ Valid with
["error", {"prefer-type-imports": true}]
The text was updated successfully, but these errors were encountered: