Error for import type, Imported multiple times in typescript

[njfamirm]

Hello
On the 2.28.0 version of this package, I'm getting an error from eslint: Imported multiple times.
This happens when I use import type in addition to normal import!

For example:
``Ts
import {createServer} from 'node:http';
import type {IncomingMessage, ServerResponse} from 'node:http';

In the above code, we have the same error from [eslint-plugin-import](https://github.com/import-js/eslint-plugin-import)

This is the complete dependabot lint workflow [log](https://github.com/AliMD/alwatr/actions/runs/5691651979/job/15427232981)

[Tirke]

Impacting us quite a lot, reverted for the moment.

[unicornware]

@njfamirm given your example, passing code for this rule would be the following:

import {
  createServer,
  type IncomingMessage,
  type ServerResponse
} from 'node:http'

(assuming the rule in question is no-duplicates 😅)

[unicornware]

there is an error with no-duplicates when all type imports are from the same file, however:

import type testSubject from '../properties'
import type { Properties } from '../properties'

yields an imported multiple times error.

[Tirke]

@njfamirm given your example, passing code for this rule would be the following:

import {
  createServer,
  type IncomingMessage,
  type ServerResponse
} from 'node:http'

(assuming the rule in question is no-duplicates 😅)

Yes we can make it pass by doing that but as type imports will not end up in the outputted JS, it would be good if we can actually differentiate (like the previous version did) between purely type imports and imports when it comes to no-duplicate.

[njfamirm]

@njfamirm given your example, passing code for this rule would be the following:

import {
  createServer,
  type IncomingMessage,
  type ServerResponse
} from 'node:http'

(assuming the rule in question is no-duplicates 😅)

Yes, you're right.
My question is, is this a bug? or a new rule of this plugin?
If it's a rule, we should decide to disable them or solve lint errors in our code.

[ljharb]

no-duplicates just looks at the specifier. It makes sense to me that if there's only one import and only one import type from the same specifier, that it would not warn - I'd be happy to review a PR that made that change.

[askoufis]

Will #2716 address this issue (among others)?

I've also run into a similar situation in the following case with prefer-inline: true:

import type React from 'react';
import { useEffect } from 'react';

The no-duplicates rule complains about the code, but the fix merges the imports incorrectly:

import type React, { useEffect } from 'react';

This is both a typescript error and a consistent-type-imports error. The latter rule then invokes another fix that splits the imports back to their original form (as above).

import { useEffect, type default as React } from 'react'; is a valid fix, but I don't like it stylistically. IMO the no-duplicates rule should ignore the split imports in that case.

[ljharb]

Yes, I believe #2716 will address that.

[njfamirm]

@njfamirm given your example, passing code for this rule would be the following:

import {
  createServer,
  type IncomingMessage,
  type ServerResponse
} from 'node:http'

(assuming the rule in question is no-duplicates 😅)

Yes, you're right. My question is, is this a bug? or a new rule of this plugin? If it's a rule, we should decide to disable them or solve lint errors in our code.

ok, this is new rule, so we update our codes to remove this lint error.
Thank you and everyone who answered ❤️