padding-line-between-statements: Custom STATEMENT_TYPE
See original GitHub issueWhat rule do you want to change?
padding-line-between-statements
Does this change cause the rule to produce more or fewer warnings? Fewer warnings.
How will the change be implemented? (New option, new default behavior, etc.)?
Allow specification of a custom STATEMENT_TYPE
that allows a user to specify certain statements to require spacing, such as an it()
statement in Mocha/Jest.
Please provide some example code that this change will affect:
Before allowing custom STATEMENT_TYPE
:
describe("Test Suite", () => {
it("has a test", () => {
expect(1).to.equal(1);
});
it("has another test", () => { // No way to enforce an error here
expect(2).to.equal(2);
});
});
After allowing a custom STATEMENT_TYPE
that adds it
as a statement requiring one or more newlines:
describe("Test Suite", () => {
it("has a test", () => {
expect(1).to.equal(1);
});
it("has another test", () => { // Error
expect(2).to.equal(2);
});
});
The code would be valid with the added option if it looked like this:
describe("Test Suite", () => {
it("has a test", () => {
expect(1).to.equal(1);
});
it("has another test", () => { // Valid
expect(2).to.equal(2);
});
});
What does the rule currently do for this code? Nothing.
What will the rule do after it’s changed?
Enforce padding line between a custom STATEMENT_TYPE
.
Issue Analytics
- State:
- Created 6 years ago
- Comments:10 (6 by maintainers)
Can we support selectors here?
For example:
{ blankLine: "always", prev: "ExpressionStatement > CallExpression[callee.name='it']", next: "ExpressionStatement > CallExpression[callee.name='it']" }
…A bit verbose, though!
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.