brace-style 1tbs with allowSingleLine should not allow else on separate line

[kardasis]

What rule do you want to change?
brace-style

Does this change cause the rule to produce more or fewer warnings?
more

How will the change be implemented? (New option, new default behavior, etc.)?
new default behavior

Please provide some example code that this change will affect:

      if (condition) { doThisThing() } else {
        otherwiseDoThis()
      }

What does the rule currently do for this code?
It does not produce an error

What will the rule do after it's changed?
Produce an error indicating that you are mixing allowSingleLine with multiple lines

Are you willing to submit a pull request to implement this change?
yes

[g-plane]

Thanks for this issue.

However, allowSingleLine doesn't mean enforceSingleLine. That is, you can put them in one line, but not forced.

[kardasis]

It seems to me that the example I gave is a weird mix of single line and 1tbs since it’s not valid 1tbs, but it’s also not a single line statement.
If nothing else, the docs should make a mention one way or the other.

[kaicataldo]

PRs to improve documentation are always welcome!

[kardasis]

Cool. I’d be happy to contribute.
Would you consider an additional option that clarifies this? Something like allowSplitSingleLines

[kaicataldo]

@kardasis If you're proposing a rule change, do you mind filling out the rule change template with the updated proposal? Either updating the original comment or adding a new comment would be fine! Once we have a formal proposal, the team can evaluate it.

[kardasis]

I'll be submitting a PR with the docs shortly.
Honestly, i found myself using the docs and tests to point out some funny edge cases that I think should behave differently (or at least accept an option to behave differently) .
take a look and let me know what you think

[eslint-deprecated]

Unfortunately, it looks like there wasn't enough interest from the team
or community to implement this change. 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 accepted status after 21 days tend to
never be accepted, and as such, we close those issues.
This doesn't mean the idea isn't interesting or useful, just that it's
not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.