Request to add allowSingleLineArrow flag for brace-style
See original GitHub issueWhat rule do you want to change?
brace-style
Does this change cause the rule to produce more or fewer warnings?
Fewer
How will the change be implemented? (New option, new default behavior, etc.)?
I propose that a new option be add to the rule. The option would be allowSingleLineArrow
, boolean, defaulting to false.
Please provide some example code that this change will affect:
functionWithCallback((var1) => { doSomethingWithoutAReturn(); });
What does the rule currently do for this code?
The following error is thrown:
error Statement inside of curly braces should be on next line brace-style
What will the rule do after it’s changed?
If allowSingleLineArrow
is set to true, the preceding code would be allowed. However, the following code would still error:
if (a === b) { doSomething(); }
Are you willing to submit a pull request to implement this change?
Yes
Issue Analytics
- State:
- Created 5 years ago
- Reactions:4
- Comments:7 (2 by maintainers)
Top Results From Across the Web
brace-style - 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 >Artistic Style 3.1
The statement must be on a single line. The braces will be added according to the requested brace style. If no style is...
Read more >How to add brace-style rules to prettier? · Issue #26 - GitHub
So I want to use stroustrup for my brace-style, I updated my .eslintrc file as per below but prettier keeps complaining and I...
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
@not-an-aardvark I appreciate your clear explanation, but I disagree with your viewpoint that it’s overly specific. I think many folks have a brace style for things like conditionals, functions, and other true block elements where they don’t want a single line, but they’re willing to allow a single line for arrow functions for brevity.
For example, in our standards, we have this:
On the other hand, we allow it for arrow functions because it’s clear when you see an arrow function that you need to look at the function body - to the right. Generally the locations arrow functions are used, you’re not likely to misread something in vertical scanning (like you might in the previous example).
We actually did already create a forked version of this rule in eslint-plugin-silvermine. It was only a few lines of change from the one that’s included in core (as you see in the PR #11227). We’d greatly appreciate if you would consider including it in core. Thanks!
Hi, sorry about the lack of activity here. You might be interested in
eslint-rule-composer
– it’s a tool that would allow you to make some minor changes to rules for your project without forking the whole thing, and I think it would work well for a change like this.