Allow object-curly-newline to permit newlines around single property
See original GitHub issueWhat rule do you want to change?
object-curly-newline: ["error", { "multiline": true }]
Does this change cause the rule to produce more or fewer warnings?
This change would optionally cause fewer warnings.
How will the change be implemented? (New option, new default behavior, etc.)?
New option, or new configuration added to an existing option.
Please provide some example code that this change will affect:
let a = {
b: "c"
};
What does the rule currently do for this code?
Warns “Unexpected a line break after this open brace. (object-curly-newline)” on the first line and “Unexpected a line break before this close brace. (object-curly-newline)” on the last line.
What will the rule do after it’s changed?
Not warn when an object with a single property places that property on its own line.
As @platinumazure said on Gitter:
It seems like the option enforces two rules: No linebreaks around curlies if all properties are on the same line; and required linebreaks around curlies if all properties are not on the same line. Seems like you want just the second half of that.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:2
- Comments:6 (5 by maintainers)
Top GitHub Comments
Sorry @captbaritone @ivantcov, looks like i lost track of this!
@eslint/eslint-team this would be a backwards-compatible enhancement to
object-curly-newline
to allow newlines between curlies if there is only one property in the object literal. Here’s the proposed schema: https://github.com/eslint/eslint/issues/7609#issuecomment-261014672. Looks like @captbaritone would also be willing to implement this if it gets accepted. Anyone interested in giving some 👍 's?Thanks for your interest in improving ESLint. Unfortunately, it looks like this issue didn’t get enough support from the team and so I’m closing it. While we wish we’d be able to accommodate everyone’s requests, we do need to prioritize. We’ve found that issues failing to reach consensus after a long time tend to never do it, and as such, we close those issues. This doesn’t mean the idea isn’t interesting, just that it’s not something the team can commit to.