Proposal: extending object-curly-spacing with rules for empty objects
See original GitHub issueTell us about your environment
- ESLint Version: v3.8.0
- Node Version: v6.7.0
- npm Version: v3.10.7
What parser (default, Babel-ESLint, etc.) are you using? default
Please show your full configuration:
{
"rules": {
"object-curly-spacing": ["error", "never"]
}
}
What did you do? Please include the actual source code causing the issue.
var a = { }
What did you expect to happen?
I expected that the rules should complain about the stray space between the curly braces { }
I also think it would be a good idea to add a separate config for empty objects, since I think that people who have this rule set to "always"
still doesn’t want any whitespace inside empty objects.
What actually happened? Please include the actual, raw output from ESLint.
No error was raised
Issue Analytics
- State:
- Created 7 years ago
- Reactions:5
- Comments:11 (11 by maintainers)
Top Results From Across the Web
object-curly-spacing - ESLint - Pluggable JavaScript Linter
Rule Details This rule enforces consistent spacing inside braces of object literals, destructuring assignments, and import/export specifiers.
Read more >object-curly-spacing | typescript-eslint
Enforce consistent spacing inside braces. ... This rule extends the base eslint/object-curly-spacing rule. It adds support for TypeScript's object types.
Read more >A tour of the Dart language
Everything you can place in a variable is an object, and every object is an instance of a class. Even numbers, functions, and...
Read more >OpenAPI Specification - Version 3.0.3 - Swagger
Format. An OpenAPI document that conforms to the OpenAPI Specification is itself a JSON object, which may be represented either in JSON or...
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 Free
Top 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
Sounds great, thank you for the thorough response 👍
I’m not opposed to changing them all to
"always"
and"never"
(in a backwards compatible way), though!