eslint: "semi-spacing" rule doesn't work after "while"

Tell us about your environment

ESLint Version: 5.16.0
Node Version: 10.15.3
npm Version: 6.4.1

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

Please show your full configuration:

Configuration

{
  "env": {
    "es6": true,
    "node": true,
    "jasmine": true
  },
  "extends": "eslint:recommended",
  "parserOptions": {
  },
  "rules": {
    "semi-spacing": "error"
    "prefer-arrow-callback": "error",
    "no-else-return": "error",
    "no-multi-spaces": "error",
    "no-whitespace-before-property": "error",
    "camelcase": "error",
    "new-cap": "error",
    "no-console": "error",
    "comma-dangle": "error",
    "no-var": "error",
    "no-shadow": "error",
    "object-shorthand": [
      "error",
      "properties"
    ],
    "indent": [
      "error",
      4,
      {
        "SwitchCase": 1
      }
    ],
    "quotes": [
      "error",
      "single"
    ],
    "semi": [
      "error",
      "always"
    ]
  }
}

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

while (/*condition*/) ;

./node_modules/.bin/eslint ./lib

What did you expect to happen?

To error about the space between the end of while condition and ;, because of the "semi-spacing": "error" rule. This issue is specific to one-line (or empty) while statements.

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

It passes.

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

Maybe.

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 23 (18 by maintainers)

Most upvoted comments

@mysticatea You removed the “tsc agenda” label about a month ago but I don’t see any information here on what the TSC chose to do with this. Could you please add that information and then, if necessary, reopen this issue? Thanks!

platinumazure on Jul 7, 2019

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.

eslint-deprecated[bot] on Jul 7, 2019

TSC Summary:

An issue was reported where the semi-spacing rule does not check the space before or after a control statement with empty body (such as while (/*condition*/) ;). After some discussion between a few team members, consensus could not be reached on whether this should be regarded as a bug, an enhancement to semi-spacing, or justification for a new rule altogether. Discussion seems to hinge on whether the rule should be token-based and should work on most/all semicolon tokens regardless of node context, or if the rule should be node-based and should have different functionality for EmptyStatement nodes that are the body of control statements.

TSC Question:

Should the original issue be regarded as a bug, an enhancement request (i.e., is a new option needed for this case), or a feature request (i.e., is a new rule needed)?
Should we take any action around the other gap identified (no rule for enforcing space between conditional and single statement body)?

platinumazure on May 22, 2019

I’m leaning towards to that another rule should check this rather than semi-spacing rule.

Currently, we don’t have any rule that reports the following case:
while (a)foo();
//       ^ missing space
Maybe we should have a rule for the space between the head and the body of some syntaxes.

When there isn’t an empty statement as the body, I agree-- I think semi-spacing should handle the semicolon after foo() in the example, and a new rule should handle the missing space after (a). But I think if the body is an EmptyStatement, it would be more intuitive to users for semi-spacing to handle this, as the rule would be adding or removing a space around a semicolon.

platinumazure on May 20, 2019

I just think a token-based approach would work best because it would be intuitive to users and would be parallel to rules like comma-spacing, which literally enforces spaces around commas no matter what type of statement they are in.

We should design rules to keep the most common case simple, and less common customizations can be done with extra rule options.

In my opinion, having the rule not work at all for while (condition); is bad, but requiring that users use a new option just because that semicolon is associated with an extra empty statement is not a useful distinction for most users. Instead, we should have the rule work on those semicolons by default. If users say they want different behavior for empty statements, only then should we add an option for that customization.

platinumazure on May 18, 2019

@platinumazure I don’t think so. Different semantics should have different appearances to distinguish what you do. At least, I think it requires a space before the ; because the while statement and the empty statement is different statements. This is the same reason that we add a space after semicolon. Though, configurable is nice.

@vitaly-t while(text[++c] !== '\n'); means “repeats en empty statement until a line break.” - The body of the while statement is an empty statement. See the language spec: https://tc39.github.io/ecma262/#sec-iteration-statements. You can see the fact that while statement doesn’t have semicolon.

mysticatea on May 18, 2019