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
object-curly-newline for named imports not working as expected #12018
Comments
It's not clear to me if this is reporting an issue with auto fixing or a lint error. Do you mind clarifying, and if it is a lint error, share the output of that error? Additionally, to clarify whether it's an issue with ESLint itself or the Webstorm ESLint integration, can you run ESLint from the command line and confirm that it yields the same results? |
Yes autofixing is enabled, even launching the command from the console there is no fix in the import statement. |
I can probably expand a little on this, but only using the 5.16.0 version of ESLint and using babel-eslint as the parser. (limited to 5.16.0 as we're using create-react-app on the project and that has a hard requirement for the 5.x series of ESLint) This is the simplified rule from my .eslintrc.js: 'object-curly-newline': ['error', {
"ImportDeclaration": { "minProperties": 3, "consistent": false, "multiline": true },
}], According to the example on the ESLint documentation ( https://eslint.org/docs/rules/object-curly-newline#multiline) the following line should raise an error with ESLint as it has a) >= 3 named imports and b) all of them on the very same line, which should be forbidden by the multiline: true setting: import {
ButtonControl, DatePickerControl, SelectControl, TextboxControl,
} from '../../../../shared/Form/elements'; I would expect this to be reformatted to have each import on it's own line: import {
ButtonControl,
DatePickerControl,
SelectControl,
TextboxControl,
} from '../../../../shared/Form/elements'; Calling eslint from the commandline to analyze just one file like this: I also tried changing the object-property-newline rule to disable the If I change the conflicting import to be just a single line it will complain, but only move the named imports to the format specified above on a single line with the parenthesis on separate lines. |
Same issue, even @mastacheata can't fix mine. The lint can't enforce the rule to separate line from destructuring import. Like
Above code pass lint easily no warning no fixing.
|
Same here. On my project, we want to be able to see github blame for each named import. To do that we need developers to put each named import on a separate line. So the ability to enforce one named import per line would be amazing. |
Unfortunately, it looks like there wasn't enough interest from the team Thanks for contributing to ESLint and we appreciate your understanding. |
+1 |
Is there any plan on fixing this? |
Obviously not, The issue is closed, so noone will have it on their radar for things to fix. |
Reopening to clarify, as this doesn't look like a bug.
The rule to enforce line breaks between properties is |
But isn't the Multiline option of that rule exactly for this situation? |
Could you please post an example where it seems that the rule doesn't work as expected? That would be helpful to find a potential bug or clarify what's the responsibility of this rule. |
I'll gladly provide an example on Monday afternoon when I'm in the office again. |
Unfortunately, it looks like there wasn't enough interest from the team Thanks for contributing to ESLint and we appreciate your understanding. |
@mdjermanovic if this isn't a bug then the documentation for the rule isn't accurate. According to the documentation: // With this rule config in .eslintrc.js
"object-curly-newline": ["error", {
"ImportDeclaration": "always",
}]
// operating on this subject statement
import { foo, bar } from "lodash"
// the rule's documentation implies that eslint --fix will change the subject to
import {
foo,
bar
} from "lodash"
// However, the actual result of eslint --fix is
import {
foo, bar,
} from "lodash" This is different from the implied "correct code" example in the rule's documentation. The result of the ES Lint fix is still breaking AirBnB styleguide rule 10.8 so I'm surprised you won't fix it. If you don't fix it then please at least update the documentation to reflect what --fix really does, and/or prevent this rule from being fixed for import statements at all. |
@lukenofurther thanks for the suggestions! Correct examples do not intend to represent the result of
Any code that satisfies these conditions is correct for this rule: // correct example
import {
foo,
bar
} from "lodash"
// also correct example
import {
foo, bar
} from "lodash"
// incorrect example
import { foo, bar } from "lodash"
// incorrect example
import { foo,
bar } from "lodash"
// incorrect example
import { foo, bar
} from "lodash"
// incorrect example
import {
foo,
bar } from "lodash" The documentation is correct in this case, but it would be nice to have both examples (with and without line breaks between
As for the line breaks between |
Tell us about your environment
6.1.0
12.2
6.9.0
What parser (default, Babel-ESLint, etc.) are you using?
default through webstorm
Please show your full configuration:
Configuration
What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.
automatically done by webstorm
What did you expect to happen?
I expect this code
What actually happened? Please include the actual, raw output from ESLint.
to be like this
Are you willing to submit a pull request to fix this bug?
No
The text was updated successfully, but these errors were encountered: