[import/no-duplicates] (prefer-inline) Does not detect across type and regular imports

[benkrejci]

I misread the no-duplicates doc to mean that when using the "prefer-inline" option, the following would be detected as an error:

import type { Type } from "mod";
import { value } from "mod";

And would fix to:

import { type Type, value } from "mod";

I realize now that this is not what is stated in the doc, but I still want this behavior. It is possible to implement, and from my perspective is probably what those using prefer-inline actually want. But if not, perhaps could be implemented with a new option, e.g. prefer-combined-type-imports

[benkrejci]

This works locally: #2835

[kevinbosman]

This took me by surprise too. The docs say:

In order to support fixing to an inline type import when duplicate imports are detected, prefer-inline can be set to true.

I find it hard to read this in any way other than how @benkrejci also interpreted it. Earlier in the same document a duplicate is defined as "have to point to the same module on the filesystem". Surely a 2-line import as posted above should classify as a "duplicate import" using this definition?

If I'm also reading this incorrectly, an edit to the documentation to clarify would be greatly appreciated. Thanks!

Edit: Looks to be a duplicate of #2715 and #2675

[ljharb]

I definitely agree that when prefer-inline is set, only one from 'mod' should remain.

[benkrejci]

Since there seems to be some agreement here, I added tests and an example to the doc: #2835

[benkrejci]

@ljharb hey any idea when the next release will be? (Or maybe we could get an -alpha release 🙏). Happy to help if I can, thanks.

[ljharb]

I don't do prereleases, and I don't have planned release dates, but I am hoping to get one done soon.