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
[no-duplicate-imports] Treat namespace imports as different #12758
Comments
I think this is reasonable since these two cannot be merged into one, so the rule at the moment indirectly disallows named imports if the namespace is imported. This could be indeed user's preference, but I'm not sure that such restriction was the intention of this particular rule. Maybe this can be treated as a bug and become a new default behavior instead of an option? |
I've got no major preference so your call; If released as a bug fix / default behaviour change it shouldn't have any negative impact since it's fixing what is currently an error. Worst case we'll have someone in 6 months asking if Either way, the actual fix implementation is mostly uneffected by if it's controlled by an option or not (it just changes the amount of code that's in the rule). If people are happy, I'll get started on a PR later this week :) |
Let's wait for other opinions from the team, and for consensus about the new option if this isn't a bug. While at the subject, what should be the behavior in cases such as these: import * as parsers1 from 'parsers';
import * as parsers2 from 'parsers'; // these two can be merged
import * as parsers from 'parsers';
import DefaultParser from 'parsers'; import DefaultParser, * as parsers from 'parsers';
import { SpecificParser } from 'parsers'; |
👍
The first I class as an actual duplicate that can be fixed by replacing the second with I think in general the behaviour of |
This makes sense as a heuristic to me. 👍 |
That's reasonable, but following the same logic the original example can be replaced with Not saying that it shouldn't be reported as a duplicate, just trying to find out what makes the most sense as the responsibility of this rule. |
Probably (I've not tried, but I don't think the transpiling would change it enough to cause that not to work), but it would mean I'd have to rename if I was already importing that specific parser.
Actually I think you could argue it does, because those imports can be merged by renaming them to share the same name. I think what you're after here is a heuristic for what "can be merged" means, which I'd say is:
Then, with that defined, this rule takes on the heuristic for its responsibility to be:
So, in applying this we get:
Personally, I also think that it's a good thing to encourage not duplicating such imports, as (based on my understanding on the specification for modules) there is completely no reason to do so - it's effectively the namespace form of Overall, I totally agree that this is an interesting question, but I don't think it's big enough to be worth the bikeshed given it's very easy to implement an option for later 🙂 I do think that the fixer for merging the last case should be a suggestion, since it will cause other to be invalid. |
imo this isn't an enhancement, it's a bug, and should be marked as such. |
I agree, this seems like a bug. |
Marking as accepted since three team members agree that this is a bug. |
Working on this issue. |
Solved in this PR. If someone can have a look 🙏 |
Unfortunately, it looks like there wasn't enough interest from the team Thanks for contributing to ESLint and we appreciate your understanding. |
Unfortunately, it looks like there wasn't enough interest from the team Thanks for contributing to ESLint and we appreciate your understanding. |
This remains a bug with an open PR; please reopen. cc @mdjermanovic |
Per #12767 (comment), we should also address #12760 in this issue. |
I'm going to do this, give me two weeks. |
@boutahlilsoufiane great, thanks! |
Hi, if this ticket is still open, i'll be happy to work on it :) |
@misfitonie we do have a volunteer (@boutahlilsoufiane) so let’s wait for now unless you two want to decide between yourselves who wants to work on this. |
@boutahlilsoufiane do you need some help ? Or you just need time ? |
@misfitonie thank you for proposing your help, I need just time. |
After spending too many hours trying to figure out how to run eslint project to test my changes in lib\rules\no-duplicate-imports.js, I didn't find anything. I tried this command node ./bin/eslint.js test.js. test.js:
The eslint report these errors:
I need a way to test my code, I'm stuck!!, I will appreciate any help |
The tests for this change should be added to tests/lib/rules/no-duplicate-imports.js Command to run the tests: You can find more details about the tests here: |
Hi mdjermanovic! |
Could be worth mentioning that TSLint has/had an option for this; maybe we can reuse their implementation or at least use it as inspiration?
|
Hi @mdjermanovic, I worked on your notes, could you review the PR, please? |
Hi @mdjermanovic, could you review the PR, please? |
…) (#14238) * Fix: ignore unmergable imports when checking no-duplicate-imports (fixes #13180) & Fix: Ignore re-export all in no-duplicate-imports (fixes #12760) * Fix: ignore unmergable imports when checking no-duplicate-imports (fixes #13180) & Fix: Ignore re-export all in no-duplicate-imports (fixes #12760) * Fix: ignore unmergable imports when checking no-duplicate-imports (fixes #13180) & Fix: Ignore re-export all in no-duplicate-imports (fixes #12760) * Fix: ignore unmergable imports when checking no-duplicate-imports (fixes #13180) & Fix: Ignore re-export all in no-duplicate-imports (fixes #12760) * Fix: ignore unmergable imports when checking no-duplicate-imports (fixes #13180) & Fix: Ignore re-export all in no-duplicate-imports (fixes #12760) * Fix: ignore unmergable imports when checking no-duplicate-imports (fixes #13180) & Fix: Ignore re-export all in no-duplicate-imports (fixes #12760) * Fix: ignore unmergable imports when checking no-duplicate-imports (fixes #13180) & Fix: Ignore re-export all in no-duplicate-imports (fixes #12760) * Fix: ignore unmergable imports when checking no-duplicate-imports (fixes #13180) & Fix: Ignore re-export all in no-duplicate-imports (fixes #12760) * Fix: ignore unmergable imports when checking no-duplicate-imports (fixes #13180) & Fix: Ignore re-export all in no-duplicate-imports (fixes #12760)
What rule do you want to change?
no-duplicate-imports
Does this change cause the rule to produce more or fewer warnings?
Reduces warnings.
How will the change be implemented? (New option, new default behavior, etc.)?
Behavioural change, which could be either option controlled or new default behaviour.
Prior art: TSLint.
Please provide some example code that this change will affect:
What does the rule currently do for this code?
Marks the imports as duplicates
What will the rule do after it's changed?
Not mark the imports as duplicates
Are you willing to submit a pull request to implement this change?
Yes
The primary use I have for the above is with mocking in jest, such as here where I want to both use the parsers & also spy on them to test that specific ones are called.
While I can use destructuring, or reference off
parsers
, the former won't be understood by auto-importers (i.e TS & IDE), and the latter would be inconsistent to how I use the functions in the rest of the codebase.The text was updated successfully, but these errors were encountered: