object-curly-newline for named imports not working as expected
See original GitHub issueTell us about your environment
- ESLint Version: 6.1.0
- Node Version: 12.2
- npm Version: 6.9.0
What parser (default, Babel-ESLint, etc.) are you using? default through webstorm
Please show your full configuration:
Configuration
{
"parser": "babel-eslint",
"extends": [
"airbnb"
],
"env": {
"browser": true
},
"rules": {
"arrow-parens": "off",
"comma-dangle": ["error", "never"],
"semi": ["error", "never"],
"no-confusing-arrow": "off",
"no-unused-expressions": "off",
"react/jsx-filename-extension": [1, { "extensions": [".js", ".jsx"] }],
"react/jsx-one-expression-per-line": "off",
"import/prefer-default-export": "off",
"no-param-reassign": "off",
"no-unused-vars": "off",
"import/extensions": "off",
"react/no-unused-prop-types": "off",
"object-curly-newline": ["error", {
"ObjectExpression": {"minProperties": 1},
"ObjectPattern": {"minProperties": 1},
"ImportDeclaration": {
"multiline": true,
"minProperties": 1,
"consistent": true
},
"ExportDeclaration": "always"
}],
"object-property-newline": ["error", {
"allowAllPropertiesOnSameLine": false
}]
},
"settings": {
"import/resolver": {
"webpack": {
"config": "configs/webpack.config.dev.js"
}
}
},
"settings": {
"import/resolver": {
"webpack": {
"config": "configs/webpack.config.dev.js"
}
}
},
"plugins": [
"react"
]
}
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
import {
Button, Divider,
Grid, LinearProgress, Link, MuiThemeProvider, Paper, Typography, withStyles
} from '@material-ui/core'
What actually happened? Please include the actual, raw output from ESLint. to be like this
import {
Button,
Divider,
Grid,
LinearProgress,
Link,
MuiThemeProvider,
Paper,
Typography,
withStyles
} from '@material-ui/core'
Are you willing to submit a pull request to fix this bug? No
Issue Analytics
- State:
- Created 4 years ago
- Reactions:6
- Comments:16 (5 by maintainers)
Top Results From Across the Web
object-curly-newline - ESLint - Pluggable JavaScript Linter
A pluggable and configurable linter tool for identifying and reporting on patterns in JavaScript. Maintain your code quality with ease.
Read more >javascript - ESLint - object-curly-newline
Is there a way to allow for {} (an empty object) while keeping the rest as is?
Read more >eslint-config-ash-nazg
I would like a rule to have declarations as close as possible to being just above any used scopes (for let and const...
Read more >vue/object-curly-newline - eslint-plugin-vue
The --fix option on the command line can automatically fix some of the problems reported by this rule. This rule is the same...
Read more >[Meta] Use Prettier for formatting JavaScript in Thunderbird
Preparation work is at least adding "curly: all" to eslint and do an intermediary step to fix that up (through mach lint --fix),...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
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.
@lukenofurther thanks for the suggestions!
Correct examples do not intend to represent the result of
eslint --fix
applied to incorrect examples."object-curly-newline": ["error", { "ImportDeclaration": "always" }]
expects a line break after{
, and a line break before}
.Any code that satisfies these conditions is correct for this rule:
The documentation is correct in this case, but it would be nice to have both examples (with and without line breaks between
foo
andbar
). PR is welcome!--fix
works as intended, because it makes a minimal change in the code to make it valid for this rule.As for the line breaks between
foo
andbar
, we don’t have a rule to enforce/disallow these at the moment. Feel free to open a new rule proposal!