Update: rule 'padding-line-between-statements' - add number of lines
See original GitHub issue[x] Documentation update [x] Changes an existing rule (template) [x] Add autofixing to a rule
What rule do you want to change?
https://eslint.org/docs/rules/padding-line-between-statements
Does this change cause the rule to produce more or fewer warnings?
No, the number of warnings will remain the same.
How will the change be implemented? (New option, new default behavior, etc.)?
For this rule, the set of possible options for using the blankLine
parameter
will be expanded by adding the ability to specify the required number of blank lines.
Please provide some example code that this change will affect:
/*eslint padding-line-between-statements: [
"error",
{ blankLine: 2, prev: "*", next: "class" },
{ blankLine: 2, prev: "class", next: "*" }
]*/
"use strict";
class A {}
function b() {}
What does the rule currently do for this code?
Currently, you cannot specify the required number of blank lines.
What will the rule do after it’s changed?
The rule will start using the number of blank lines only after setting the blankLine
parameter to a numeric value.
In this case, the problem will be displayed if the number of blank lines is greater than or less than the specified value.
What changes did you make? (Give an overview)
- Added ability to specify numeric value in
meta.schema.definitions.paddingType
- Added a new message view with the number of blank lines
- Added to
function verifyForAlways
output of new messages depending onblankLine
parameter - Changed the “rule fixer” so that it could replace blocks in the code with the required number of blank lines
- In
function getPaddingLineSequences
added search the current number of blank lines to display in the problem message - Updated tests and documentation
Is there anything you’d like reviewers to focus on?
Do I need to cover any other cases with tests?
Example This change will improve the readability of the source code by highlighting the concept blocks. And it will also automate the process of formatting.
Here is an example of the configuration I plan to use with these updates:
"rules": {
"lines-between-class-members": "error",
"padding-line-between-statements": [
"error",
{ "blankLine": 1, "prev": "*", "next": ["cjs-import", "cjs-export"] },
{ "blankLine": 1, "prev": ["cjs-import", "cjs-export"], "next": "*" },
{ "blankLine": 2, "prev": "expression", "next": ["cjs-import", "cjs-export"] },
{ "blankLine": 2, "prev": ["cjs-import", "cjs-export"], "next": "expression" },
{ "blankLine": 2, "prev": "*", "next": ["class", "function"] },
{ "blankLine": 2, "prev": ["class", "function"], "next": "*" },
{ "blankLine": 1, "prev": ["directive", "const", "let"], "next": "expression" },
{ "blankLine": 1, "prev": "expression", "next": ["const", "let", "return"] },
{ "blankLine": "never", "prev": "cjs-import", "next": "cjs-import" },
{ "blankLine": "never", "prev": "cjs-export", "next": "cjs-export" }
],
"padded-blocks": [
"error",
{ "blocks": "never", "classes": "always", "switches": "never" },
{ "allowSingleLineBlocks": true }
]
}
Before eslint . --fix
'use strict'
const any = require('any')
const { any2 } = require('any2')
const CONST1 = 'CONST1'
const CONST2 = 'CONST1'
/**
* My class
*/
class Test {
constructor() {
this.a = any + any2 + CONST1
}
any(a) {
let anyText = 'any'
if (a) {
anyText = 'a' + CONST2
}
return anyText
}
}
/**
* My function
*/
function test() {
const t = new Test()
console.log(t)
return t
}
console.log('any' + test())
module.exports.Test = Test
module.exports.test = test
After eslint . --fix
'use strict'
const any = require('any')
const { any2 } = require('any2')
const CONST1 = 'CONST1'
const CONST2 = 'CONST1'
/**
* My class
*/
class Test {
constructor() {
this.a = any + any2 + CONST1
}
any(a) {
let anyText = 'any'
if (a) {
anyText = 'a' + CONST2
}
return anyText
}
}
/**
* My function
*/
function test() {
const t = new Test()
console.log(t)
return t
}
console.log('any' + test())
module.exports.Test = Test
module.exports.test = test
Issue Analytics
- State:
- Created 4 years ago
- Reactions:3
- Comments:10 (9 by maintainers)
Top GitHub Comments
I support this change.
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.