eslint: Allow `brace-style` rule to enforce different styles on different block types

@jrsearles Sorry for losing track of this, but where are we here? Have I missed your PR?

I really want to see this implemented too, as the current brace-style implementation is not nearly granular enough. My style is mostly Stroustrup, but for class, function and method declarations I use the Allman style with the braces on their own line. There’s no way to express this to ESLint so I’m currently forced to disable the brace-style rule entirely.

Please describe what the rule should do: I would like to enhance the brace-style rule by allowing for different brace handling based on the type of block. For example, different handling for IfStatements vs FunctionDeclaration or FunctionExpression.

Ideally you would be able to use individual options to mimic the predefined formats (“1tbs”, “strousoup”, “allmans”), providing full backwards compatibility.

What category of rule is this? (place an “X” next to just one item)

[X] Enforces code style [ ] Warns about a potential error [ ] Suggests an alternate way of doing something [ ] Other (please specify:)

Provide 2-3 code examples that this rule will warn about:

WARNINGS

/* eslint brace-style { FunctionDeclaration: "new-line", FunctionExpression: "same-line", IfStatement: "same-line", noCuddledElse: true } */
function doSomething() {
  // function body
}

invokeCallback(function() 
{
});

if (true) 
{
  // body
} else {
}

EXPECTED

/* eslint brace-style { FunctionDeclaration: "new-line", FunctionExpression: "same-line", IfStatement: "same-line", noCuddledElse: true } */
function doSomething()
{
  // function body
}

invokeCallback(function() {
});

if (true) {
  // body
} 
else {
}

Why should this rule be included in ESLint (instead of a plugin)? This is adding flexibility to an existing rule. I feel like i’m fighting with my tooling (VSCode) when using the brace-style rule and would like the possibility of adding additional properties for the rule to better fit within our preferred code formatting and development tooling.

@jrsearles Wow, nice work on that plugin. I’d love to see this considered for core. I will take the plugin as a proposal.

@eslint/eslint-team I’ll champion this. Any endorsements?

I created a plugin (https://github.com/jrsearles/eslint-plugin-brace-rules) which is a reworking of the brace-style rule with the flexibility i’m looking for. It’s completely backwards compatible (at least all tests pass). I also made it fixable, since this is only stylistic issue it’s nice to just let the tool fix it.

I’m more than happy to submit this as a PR. The change i made allowed the second argument to be an object literal with the node types specified with an enum (“always”, “never”, “ignore”) to determine how to enforce the brace rule. Then added a couple additional properties to account for the variance in the Stroustrup style.

BTW, i gotta say the documentation on your site is fabulous. It made creating a plugin a breeze.

If you don’t want to incorporate these changes in core feel free to close this issue.

I haven’t had a chance to do anything with this, but I did make a plugin to support this extensibility.

I don’t think developers would typically know specific variants and if they did they would probably use those instead of the individual options.

Due to the way the existing options work, a developer would have to know specific variants anyway in order to configure this rule at all. I think it’s better to keep the same options for consistency. If we were redesigning the rule from scratch I might agree with you, but I don’t think we should have two separate groups of options that mean largely the same thing.

My personal preference would be using options like “new-line” and “same-line”. I find them more descriptive and discoverable. I don’t think developers would typically know specific variants and if they did they would probably use those instead of the individual options.

I don’t super enjoy using “1tbs” vs “allman” etc. as values for the individual configurations, because to me those are brace styles that apply equally to all blocks; however, I respect that there is practical value in using values that users will already be familiar with.

The only potential confusion I can see is the use of “allman” vs “stroustrup” for non-if blocks (e.g., function bodies). In that case, they mean the same thing since there is no “else block” to consider. Is that potentially ambiguous, or can we write the rule to respect both of those values?

I think I ultimately favor @jrsearles’ most recent suggestion, which is “same-line”, “new-line”, and “ignore” (though we would still need to figure out the best way to handle “else” blocks for IfStatement nodes).

I’d really love to see this get in-- let’s figure out a good design and get this in pronto! 😄