New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rule Proposal: nonblock-body-position #6067
Rule Proposal: nonblock-body-position #6067
Comments
I think this rule is going to conflict with |
I tried it, but |
the other problem with it seems that positioning of the single line, whether braced or not, should be part of this one rule (perhaps renamed to |
Thank you @danielcavanagh . Also, original rule is warning the first statement of a block which has multiple statements as well. |
So, the intention of original JSCS rule is "Disallow that statements locate at beside For JSCS compatibility:
|
How does this relate to #8099 now that we have that hammered out? We're consolidating some other existing rules that enforce padded newlines around nodes into that rule - seems like this could introduce a new conflict. Should this maybe be covered by that rule as well? |
As far as I can tell, this addresses a separate issue from #8099. #8099 addresses newlines between consecutive statements, whereas this addresses newlines between nested statement nodes. For example, consider the following /* eslint newline-between-statements: ["error", ["blankline", "if", "return"]] */
if (foo)
return 1; // newline-between-statements *does not* enforce a newline before this statement.
return 2; // newline-between-statements *does* enforce a newline before this statement. |
@not-an-aardvark Thanks, that's a really helpful distinction. Makes sense! |
Sorry to respond to this so late in the game, but I also wonder if we can decide on a name that more clearly describes what this rule is checking. |
I look at this again, I wonder if () => foo()
// or
() =>
foo() |
@mysticatea Thinking about this more, I wonder if we shouldn't include ArrowFunctionExpressions. Seems like it's the odd one out, since the rest of the nodes it checks are statements. Could be confusing, particularly if we change the name to include |
We can always cover arrow function expressions in a separate rule. I think we should focus on statements in this one. |
About including arrow expressions seems unpopular in team, so let's go as is. |
From requireNewlineBeforeSingleStatementsInIf.
This rule will enforce the position of bare statements at the body of
if
,else
,do-while',
while,
for,
for-in, or
for-of`.position
"below"
(default) - Requires newline before the body's statement."beside"
- Disallow newline before the body's statement."any"
- Does not enforce the position.overrides
- People can override setting for each kind.Valid:
Invalid:
The text was updated successfully, but these errors were encountered: