-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
feat(eslint-plugin): add extension rule no-duplicate-imports
#2609
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
Conversation
Thanks for the PR, @yeonjuan! typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community. The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately. Thanks again! 🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint. As a thank you, your profile/company logo will be added to our main README which receives thousands of unique visitors per day. |
Codecov Report
@@ Coverage Diff @@
## master #2609 +/- ##
==========================================
+ Coverage 92.82% 92.84% +0.01%
==========================================
Files 293 294 +1
Lines 9619 9657 +38
Branches 2697 2709 +12
==========================================
+ Hits 8929 8966 +37
Misses 326 326
- Partials 364 365 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - thanks for your contribution!
if (typeImports.has(value)) { | ||
report('exportTypeAs', node, value); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait... is this really how the base rule works?
What is wrong with the code
import { T } from 'foo';
export { A } from 'foo';
This seems like it's much better than
import { T, A } from 'foo';
export { A };
Because the latter code defines a local variable for no reason.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bradzacher right! This rule seems just focus on duplicate module sources.🤣
I've run into some false positives with this rule when used with Specifically, the following code triggers this new rule: import type Foo from "my-module"
import type { Bar } from "my-module" But it is not actually possible to write import type Foo, { Bar } from "my-module" because that results in the TypeScript error
This rule may need some additional logic to handle this case. |
please file a new issue. |
New issue is here: #2636 |
parser: '@typescript-eslint/parser', | ||
}); | ||
|
||
ruleTester.run('no-dupe-class-members', rule, { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi :)
Isn't this rule id should be no-duplicate-imports
, not no-dupe-class-members
?
fixes #2315
I made an extension rule which distinguishes type-only import from standard import. :)