As I mentioned in my comment here: #3950 (comment)
I don't think this rule should be in the business of condensing imports when they are correctly "typed".
Instead that would be the concern of a rule like no-duplicate-imports (or even better would be import/no-duplicates - #4238 - because ESLint's base rule doesn't support typed imports as it's not "pure JS" syntax).

EG this code:

import type { cType } from './c';
import { aValue } from './a'; 
import type { bType } from './a';

Or this code:

import type { cType } from './c';
import { aValue, type bType } from './a'; 

Would never error in this rule - regardless of config - because all the types are imported via type imports.

However, I do think that this lint rule's fixer could very much be concerned with fixing to "condensed" imports when configured to do so.
I'd accept option like fixStyle which works like this

• separate-type-imports
  • always fix type imports to standalone import type { ... } statements.
  • reuse existing import type { ... } if one exists for the module.
  • This is the current behaviour, and would be the default for the option (or else it'd be a breaking change).
• inline-type-imports
  • reuse existing import type { ... } if one exists for the module, if one exists.
  • otherwise - always fix type imports to inline import { type x, ... }.
• mixed - combine the above:
  • reuse existing import type { ... } if one exists for the module, if one exists.
  • if there are no value imports for a module, prefer import type { ... }.
  • if there are value imports for a module, prefer import { type x, ... }.

(option names are up to whomever implements - the above are just an example)

Fixed output example:

import type { dType1 } from './d';
import { dType2 } from './d';
import { cType } from './c';
import { aValue, bType } from './a'; 

// `separate-type-imports` fix to
import type { dType1, dType2 } from './d';
import type { cType } from './c';
import type { bType } from './a';
import { aValue } from './a'; 

// `inline-type-imports` fix to
import type { dType1, dType2 } from './d';
import { type cType } from './c';
import { aValue, type bType } from './a'; 

// `mixed` fix to
import type { dType1, dType2 } from './d';
import type { cType } from './c';
import { aValue, type bType } from './a'; 

Yes, totally agree with having this in no-duplicate-imports instead. Do you accept a PR to add a config to that rule? Something like ignoreTypeImports?: boolean. I'm honestly not sure of the naming here.

Regarding the fixer, like you said, it could be a little complicated, so I might not pursue it here. But I want to bring to your attention, the inline-type-imports fix might not work well. Please see the discussion here - microsoft/TypeScript#47118

Basically

import { type cType } from './c';

will cause a Typescript compilation error when importsNotUsedAsValues: true if there is no non-type imports.

Yes, totally agree with having this in no-duplicate-imports instead. Do you accept a PR to add a config to that rule?

I don't believe we should be maintaining our extension rule, no-duplicate-imports - #4238.
There's no reason for us to do so when there is a much better version of the rule in the ecosystem which already supports things - import/no-duplicates.

I would like to remove our extension rule in the next major, so I don't hugely want us to add more functionality into it for now.

@bradzacher that's a very fair point! I totally forgot about this base rule. I will close this issue now.

I'll leave this open as a tracking issue in case someone wants to implement the changes to the fixer.

You can now achieve this with canonical/prefer-inline-type-import.

I believe this is still something we want in this repo even with the additions to the canonical? If so, I've started working on a fix.

Is there any way to disable the fixer for consistent-type-imports in the meantime? The fixer just ends up causing hundreds of new issues when used in conjunction with import/no-duplicates.

@blingerson Could you detail some of the issues you found and perhaps we can fix them? Even better in a new issue!

import-js/eslint-plugin-import#2469 has been merged but not yet released.

@bradzacher Amazing!

Just to note, we have 2/3 left to get proper inline imports. This PR is next I believe.

import-js/eslint-plugin-import#2475