Reevaluate decision to skip running rules when linting whitespace-only files

When I was refactoring Linter a few months ago, I was surprised to find that we have a special case when linting text that only contains whitespace; we skip running rules, and always return 0 linting errors.

Looking back at the when that case was added, I found that this was an intentional design decision made in https://github.com/eslint/eslint/issues/546. From what I can tell, the reasoning for the decision was that users might not expect ESLint to inform them that their files are empty.

In the 3 years since that decision was made, a few things about ESLint have changed:

• We’ve introduced whitespace-only rules like no-trailing-spaces, which would have a well-defined and useful behavior for files that only contain whitespace.
• Many more people now write custom rules, and they frequently use RuleTester to test their rules. A whitespace-only string is occasionally used to test that a rule works correctly when a program contains nothing of interest. However, since Linter ignores empty strings, any “valid” test on a whitespace-only string does not run the tested rule at all. This is usually unexpected for rule developers. Case in point: We have 15 buggy tests in the ESLint codebase (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15) where the test author incorrectly assumed a test was making an assertion about a rule, when it actually was not. In my view, this is undesirable because ESLint could unexpectedly conceal rule logic errors, leading to potential bugs.
• We have many more people using ESLint’s Node.js API than we used to, so I think it’s important that the API remains intuitively consistent to avoid unexpected conditions in integrations. I think it’s unexpected that Linter#verify runs rules on almost all strings that get passed to it, but it does not run rules when a string happens to only contain whitespace. This seems like it would lead to unanticipated edge cases for API users.

Due to these issues, I think the current behavior on whitespace-only files is actually more unexpected than the alternative. I think we should remove this special case and have ESLint treat whitespace-only strings the same way it treats other text.

[platinumazure]

This would let people use the feature sooner rather than later, and also disable it if it breaks rules that haven’t been fixed to work on empty files.

It would also allow us to gather more data on actual/potential breakage from users when we flip the switch in a major release. I definitely would support something like this.

[j-f1]

To allow people to use this feature without a breaking change, could we add a checkEmptyFiles option (false by default) in a minor release, then change the default to true in v5?

This would let people use the feature sooner rather than later, and also disable it if it breaks rules that haven’t been fixed to work on empty files.