Prohibiting two consecutive newlines at EOF does not work as expected

[ghost]

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.

[kaicataldo]

I’m unable to reproduce this. I know you mentioned you did try the maxEOF option in the Gitter chat, but it looks like that is working correctly (see demo here).

I’d have to look at the Git history, but I’m assuming the maxEOF option exists so that this rule can be configured to not conflict with eol-last.

[ghost]

Like I described above: Setting maxEOF to 1 should not make a difference, since max is already set to 1. In the docs it says:

maxEOF can be used to set a different number for the end of file. The last blank lines will then be treated differently. If omitted, the max option is applied at the end of the file.

And it really doesn't make a difference, two consecutive lines at EOF are being permitted -- no matter whether maxEOF is explicitly set or not.

[mdjermanovic]

eol-last doesn't require an empty line at the end of the file. It requires that the last character in the source code is \n. There is no empty line at the end of the file after that last \n, although it looks like that in editors. You'd probably want to set maxEOF to 0.

[ghost]

This certainly solved my issue. Thus, closing this issue is fine by me. However, you guys might want to leave it open, as this behavior is really non-intuitive. Without the explanation that @mdjermanovic just gave, it's really hard to grasp why maxEOF has to be set to 0 to enforce exactly one line at the EOF. Also, the documentation gives no clue about this.

[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.

[kaicataldo]

Right, an empty line is actually \n\n. Would be great to clarify this in the documentation!

[mdjermanovic]

There is an option in VSCode to modify this behavior: "editor.renderFinalNewline": false

And it seems to be true by default on Windows only, false otherwise.

Also, the question does a newline/linebreak/eol sequence ends the current line or creates a new line (i.e. is there an empty line after the last \n) may be just a matter of convention in a particular environment, so it might be best to be neutral in the documentation - to just explain that editors/viewers/tools render and treat this differently and say that the rule doesn't count this as an empty line.

I was thinking to provide both views on the same examples in the docs - one representing a screenshot of a viewer that doesn't render an extra empty line, the other representing a viewer that does render an extra empty line. (not real screenshots, just code blocks with extra lines)

Does this seem like a good idea?

There is also the following potential problem: code examples in the documentation have a different appearance on eslint.org and GitHub.

This looks like 2 empty lines at the end:

This looks like 0 empty lines at the end:

There are three \n\n\n on the site after var bar = 3;, while the GitHub viewer renders only one \n.

This usually doesn't matter but in this particular case users might already get the wrong impression on how the rule works at the EOF depending on where they're reading the documentation.

[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.

[kaicataldo]

I was thinking to provide both views on the same examples in the docs - one representing a screenshot of a viewer that doesn't render an extra empty line, the other representing a viewer that does render an extra empty line. (not real screenshots, just code blocks with extra lines)

Does this seem like a good idea?

Sounds good to me! I think it would helpful to show this with line numbers anyway.

[mdjermanovic]

Sounds good to me! I think it would helpful to show this with line numbers anyway.

That's a great idea!

Is there already a way to show line numbers in code blocks (at least on eslint.org)?

[kaicataldo]

We don't have anything set up as far as I know, but it might be worth looking at the options for the Markdown -> HTML plugins we're using in Eleventy to see if there's a built-in way to do it. If not, we can implement it. That being said, I don't think that needs to be a blocker for the documentation update!

[eslint-deprecated]

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 accepted issues failing to be implemented after 90 days tend to
never be implemented, 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.