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

sort-imports: Inconsistent behaviour with named imports #14570

Closed
last-partizan opened this issue May 6, 2021 · 4 comments
Closed

sort-imports: Inconsistent behaviour with named imports #14570

last-partizan opened this issue May 6, 2021 · 4 comments
Labels
archived due to age This issue has been archived; please open a new issue for any further discussion works as intended The behavior described in this issue is working correctly
Projects

Comments

@last-partizan
Copy link

last-partizan commented May 6, 2021

What rule do you want to change?
sort-imports

Does this change cause the rule to produce more or fewer warnings?
This change will produce less warnings, when modifying existing code.

How will the change be implemented? (New option, new default behavior, etc.)?
Default behaviour should be changed.

Please provide some example code that this change will affect:

This is code 1

/* eslint no-unused-vars: "off" */
/* eslint sort-imports: "error" */
import { cloneDeep, debounce } from "lodash";
import { BForm } from "bootstrap-vue";

This is code 2

/* eslint no-unused-vars: "off" */
/* eslint sort-imports: "error" */
import { cloneDeep, debounce } from "lodash";
import { BForm, BFormInput } from "bootstrap-vue";

What does the rule currently do for this code?
code 1 is considered correct by eslint.
code 2 raises error Imports should be sorted alphabetically sort-imports

What will the rule do after it's changed?
Rule should either treat single named import as multiple, or it should change naming to default and named import groups to avoid confusion.

Are you willing to submit a pull request to implement this change?
No.

@last-partizan last-partizan added bug ESLint is working incorrectly repro:needed labels May 6, 2021
@eslint-github-bot eslint-github-bot bot added this to Needs Triage in Triage May 6, 2021
@nzakas
Copy link
Member

nzakas commented May 7, 2021

Please edit your issue to use one of our issue templates:
https://github.com/eslint/eslint/tree/master/.github/ISSUE_TEMPLATE

We can take a look at that point. Thanks I’m advance.

@nzakas nzakas moved this from Needs Triage to Triaging in Triage May 7, 2021
@last-partizan
Copy link
Author

@nzakas i updated issue to use RULE_CHANGE.md template.

@nzakas
Copy link
Member

nzakas commented May 11, 2021

Thanks. I’m not very familiar with this rule, so I’ll defer to others as to how to evaluate this.

@nzakas nzakas moved this from Triaging to Needs Triage in Triage May 11, 2021
@mdjermanovic mdjermanovic added works as intended The behavior described in this issue is working correctly and removed bug ESLint is working incorrectly repro:needed labels May 11, 2021
@mdjermanovic
Copy link
Member

This works as designed, per the documentation:

  • multiple = import multiple members.
  • single = import single member.

@last-partizan I agree with you that "default" and "named" would make more sense than "multiple" and "single". Given that the core stylistic rules are frozen, I think the best course of action would be to make a custom rule with a different set of options.

I'm closing this issue since the rule works as intended, and per our rules policies we're not accepting changes related to stylistic rules.

Triage automation moved this from Needs Triage to Complete May 11, 2021
@eslint-github-bot eslint-github-bot bot locked and limited conversation to collaborators Nov 8, 2021
@eslint-github-bot eslint-github-bot bot added the archived due to age This issue has been archived; please open a new issue for any further discussion label Nov 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
archived due to age This issue has been archived; please open a new issue for any further discussion works as intended The behavior described in this issue is working correctly
Projects
Archived in project
Triage
Complete
Development

No branches or pull requests

3 participants