padding-line-between-statements: add generic multiline option

[hotforfeature]

What rule do you want to change?
padding-line-between-statements

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.)?
Add a multiline statement type that detects all multiline statements. This will be identical to multiline-block-like but match on any type instead of just block-like statements.

As a side effect, this would also match unknown multiline block-like statements, such as TypeScript interface declarations.

Please provide some example code that this change will affect:

foo(
  a,
  b
);
foo(a, b);

What does the rule currently do for this code?
Nothing

What will the rule do after it's changed?
Enforce newlines for the first multiline function statement.

[aladdin-add]

thanks for the proposal, however I'm 👎 to add this:

• in foo(a, b), a and b are not statements.
• padding-line-between-statements aims to enforce padding, not linebreak. so the option would enforce code like:

foo(
a,

b
);

can rule function-paren-newline work for this?

[hotforfeature]

That is not the use case I am proposing.

Before:

foo(
  a,
  b
);
foo(a, b);

After:

foo(
  a,
  b
);

foo(a, b);

The statement is the multiline foo() function invocation.

[aladdin-add]

ψ(._. )>sorry for misunderstanding! 😄

it seems a generic case. 👍 to make the change.

[platinumazure]

I think I could get behind this. 👍 from me.

[not-an-aardvark]

This seems similar to #9491. Would one of the proposals be better than the other?

[not-an-aardvark]

Thanks for your interest in improving ESLint. Unfortunately, it looks like this issue didn't get consensus from the team, so I'm closing it. We define consensus as having three 👍s from team members, as well as a team member willing to champion the proposal. This is a high bar by design -- we can't realistically accept and maintain every feature request in the long term, so we only accept feature requests which are useful enough that there is consensus among the team that they're worth adding.

Since ESLint is pluggable and can load custom rules at runtime, the lack of consensus among the ESLint team doesn't need to be a blocker for you using this in your project, if you'd find it useful. It just means that you would need to implement the rule yourself, rather than using a bundled rule that is packaged with ESLint.