import-js/eslint-plugin-import

[no-duplicates] prefer-inline breaks unassigned and top-level type imports

Open

#3130 opened on Dec 23, 2024

View on GitHub
 (4 comments) (0 reactions) (0 assignees)JavaScript (4,946 stars) (1,540 forks)batch import
bughelp wantedtypescript

Description

"import/no-duplicates": ["error", { "prefer-inline": true }],

Will detect an error in the following typescript code:

import type { X } from "xyz";

import "xyz";

// [...]

It will auto-fix by removing the import "xyz"; statement. This is not the desired behavior. I would expect it to stay as is.

Merry Christmas 🎄

Contributor guide

Tech stack
typescriptjavascript
Domain
developer experience
Issue type
bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
half day
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
fresh
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
Understanding of TypeScript import typesBasic knowledge of ESLint rules
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
65
Research direction
The issue is about the `no duplicates` rule with `prefer inline` option incorrectly removing a side effect import when a type import from the same module exists. To fix, examine the rule's implementation in `src/rules/no duplicates.ts` (or similar) to understand how it handles `type` imports and side effect imports. The auto fix logic should preserve `import "xyz";` even when `import type { X }` is present. Look at existing tests for `prefer inline` to see how they handle edge cases and add a test case for unassigned imports. The issue reporter provided a clear failing example.