Prohibiting two consecutive newlines at EOF does not work as expected

Tell us about your environment

• ESLint Version: ^6.8.0
• Node Version: 10.0.0
• npm Version: 5.6.0

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

Please show your full configuration:

Configuration

{
  "env": {
    "es6": true,
    "node": true
  },
  "extends": [
    "airbnb-base"
  ],
  "globals": {
    "Atomics": "readonly",
    "SharedArrayBuffer": "readonly"
  },
  "parserOptions": {
    "ecmaVersion": 2018,
    "sourceType": "module"
  },
  "rules": {
    "no-multiple-empty-lines": ["error", { "max": 1 }]
  }
}

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

Source code:

// Source code of any .js file of the project

Command:

npx eslint .

What did you expect to happen? What actually happened?

I want to ensure there is exactly one newline at the end of each file. Since I am extending the Airbnb style guide, eol-last is already enabled, which afaik requires at least one newline at the end of the file. So all that’s left for me to specify is that more than one newlines at the end of the file are disallowed. I thought I might be able to accomplish this like so:

"no-multiple-empty-lines": ["error", { "max": 1 }]

Now, there should be both

• the requirement of at least one newline at the end of the file, due to eol-last being enabled in the Airbnb style guide, as well as
• the requirement of no more than one newline at a time (applying to the whole file, not just the end of the file), due to manually setting no-multiple-empty-lines to { "max": 1 }.

However, this still configuration seems to still allow two consecutive newlines at the end of the file.

In the Gitter chat room, it was recommended to set maxEOF to 1. This, however, does not change the fact that two newlines at the end of the file are being accepted. The fact that this does not fix the issue is to be expected, as max is already set to 1, so setting maxEOF to 1 also should not have an effect.

In the Gitter chat room it was concluded to file a bug report.

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

Maybe. It would be an honor but I’m not sure I can. I’ll take a look.

[mdjermanovic]

It seems we all agree that the rule is working as intended and that it would be great to improve the documentation, so I marked this as an accepted “documentation” issue.

[mdjermanovic]

maxEOF has to be set to 0 to enforce exactly one line at the EOF. Also, the documentation gives no clue about this.

I believe it’s technically zero empty lines at the EOF, but it looks like one empty line in most editors.

I agree this should be explained in the documentation. Also, I think there should be an example with maxEOF: 0 because it’s a common configuration for this rule. PR is welcome!

Just, I’m not sure how to avoid this confusion in maxEOF examples because the presentation depends on the editor/viewer.

For instance, if you open to view a source file on GitHub and see a code that looks exactly like the actual incorrect example in the docs (GitHub shows 8 lines, last 2 are empty), it’s indeed an incorrect code by this rule. If you open the same file in VSCode, there will be one extra line (VSCode shows 9 lines, last 3 are empty).

However, if you open another source file in VSCode, and see a code that looks exactly like the actual incorrect example in the docs (VSCode shows 8 lines, last 2 are empty), it’s actually a correct code by this rule.

It’s same in ESLint Online Demo

So, these examples can be indeed confusing.

Also, it looks that some other rules like max-lines inconsistently treat this issue, because it seems that SourceCode#lines does contain an extra line after the last linebreak.