eslint: padding-line-between-statements: Missing functionality covered by deprecated lines-around-directive

Tell us about your environment

  • ESLint Version: 5.9.0
  • Node Version: 10.13.0
  • npm Version: 6.4.1

What parser (default, Babel-ESLint, etc.) are you using? default

Please show your full configuration:

Configuration
module.exports = {
  rules: {
    'lines-around-directive': ['error', { before: 'never', after: 'always' }],

    'padding-line-between-statements': ['error',
      { blankLine: 'never', prev: '*', next: 'directive' },
      { blankLine: 'always', prev: 'directive', next: '*' },
    ],
  }
}

What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.

<empty line>
'use strict';

console.log(1);

also

/**
 * Copyright
 */

'use strict';

console.log(1);

command:

eslint .

What did you expect to happen?

Both the lines-around-directive (deprecated) rule and padding-line-between-statements rules should warn about the unexpected empty line at the start of the file.

What actually happened? Please include the actual, raw output from ESLint.

Only the lines-around-directive rule produced an error:

  2:1  error  Unexpected newline before "use strict" directive  lines-around-directive

Are you willing to submit a pull request to fix this bug?

Maybe. The hard part here is figuring out what to do about this.


The problem seems to be that prev: '*' in the padding-line-between-statements configuration doesn’t match the top of the file before the 'use strict'; directive.

This is a real problem because the lines-around-directive rule was deprecated in ESLint v4.0.0 with the claim that it will be replaced by the padding-line-between-statements rule. However, the padding-line-between-statements rule is not able to fully replicate the functionality of the lines-around-directive rule because of this bug.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 15 (14 by maintainers)

Most upvoted comments

One other thought: we currently have padded-blocks, lines-around-comment, lines-between-class-members, and padding-line-around-statements.

Could we deprecate padding-line-around-statements, lines-around-comment, and lines-between-class-members in favor of a new rule padding-lines that allows for the enforcement of padding lines between any syntax in the same scope (including statements, properties, methods, comments, directives - everything!). It could essentially have the same API and configuration options it does now with the addition of options needed to cover the cases from the other rules.

We can then deprecate padded-blocks in favor of a new rule called padded-scope that covers all that padded-blocks currently does, but also covers the file/module scope (and therefore cover BOF and EOF).

This way, we could have two padding line rules - one for padding lines between syntax in the same scope and one for padding lines within new scopes (including the file/module scope).

I know our padding lines rules have changed a lot over the years, but I don’t know how useful it is to have multiple rules for different syntax, and I think having two more generic, highly configurable rules could allow for users to have more control over this.

If the team is amenable to this, I can do some more research and write up a formal proposal.

@nwoltman, @kaicataldo. I check this on v.6.4.0 no-multiple-empty-lines is worked now in this situation example:

    'no-multiple-empty-lines': ['warn',
      { max: 2, maxEOF: 0, maxBOF: 0 }
    ],
    1:1  warning  Too many blank lines at the beginning of file. Max of 0 allowed  no-multiple-empty-lines
  336:1  warning  Too many blank lines at the end of file. Max of 0 allowed        no-multiple-empty-lines

✖ 2 problems (0 errors, 2 warnings)
  0 errors and 2 warnings potentially fixable with the `--fix` option.

ps: no-multiple-empty-lines - Allows \n on the last line, and does not conflict with eol-last