Skip to content
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

Error for import type, Imported multiple times in typescript #2843

Closed
njfamirm opened this issue Jul 30, 2023 · 9 comments
Closed

Error for import type, Imported multiple times in typescript #2843

njfamirm opened this issue Jul 30, 2023 · 9 comments

Comments

@njfamirm
Copy link

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
Copy link

Tirke commented Jul 31, 2023

Impacting us quite a lot, reverted for the moment.

@unicornware
Copy link

unicornware commented Aug 1, 2023

@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
Copy link

unicornware commented Aug 1, 2023

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.

unicornware added a commit to flex-development/tutils that referenced this issue Aug 1, 2023
- #342
- import-js/eslint-plugin-import#2843

Signed-off-by: Lexus Drumgold <unicornware@flexdevelopment.llc>
@Tirke
Copy link

Tirke commented Aug 1, 2023

@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
Copy link
Author

njfamirm commented Aug 1, 2023

@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
Copy link
Member

ljharb commented Aug 5, 2023

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
Copy link

askoufis commented Aug 16, 2023

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
Copy link
Member

ljharb commented Aug 16, 2023

Yes, I believe #2716 will address that.

@njfamirm
Copy link
Author

@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 ❤️

unicornware added a commit to flex-development/grease that referenced this issue Oct 9, 2023
unicornware added a commit to flex-development/grease that referenced this issue Oct 9, 2023
- import-js/eslint-plugin-import#2843

Signed-off-by: Lexus Drumgold <unicornware@flexdevelopment.llc>
unicornware added a commit to flex-development/nest-commander that referenced this issue Oct 22, 2023
- import-js/eslint-plugin-import#2843

Signed-off-by: Lexus Drumgold <unicornware@flexdevelopment.llc>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

5 participants