keyword-spacing does not work for function keyword

Tell us about your environment

Node version: v12.12.0 npm version: v6.11.3 Local ESLint version: v6.6.0 (Currently used) Global ESLint version: Not found

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

default

Please show your full configuration:

Configuration

module.exports = {
  "env": {
    "browser": true,
    "es6": true,
    "node": true
  },
  "parserOptions": {
    "ecmaVersion": 2018,
    "sourceType": "module"
  },
  "rules": {
    "keyword-spacing": "error",
  }
};

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

function test2(x) {
  return x;
}

const test1 = function(x) {
  if(true) {
    return 'test1' + x;
  } else {
    return 'test2' + x;
  }
};

eslint .

What did you expect to happen?

I expected two errors here

  5:15  error  Expected space(s) after "function"  keyword-spacing
  6:3   error  Expected space(s) after "if"  keyword-spacing

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

Only one error is reported, and the missing space after the function keyword remains undetected:

$ eslint .

test.js
  6:3  error  Expected space(s) after "if"  keyword-spacing

✖ 1 problem (1 error, 0 warnings)
  1 error and 0 warnings potentially fixable with the `--fix` option.

Since the error is not detected, of course I’m also not able to automatically fix it (--fix).

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

I would, but not sure where to start looking…

[friederbluemle]

Oh, and regarding the perceived rudeness in the previous response - no worries at all. I could tell it was unintentional. Thanks again!

[platinumazure]

Hi @friederbluemle. I apologize on behalf of the team for letting this slip through the cracks. I will attempt to provide a more complete answer to your questions.

• Why does the keyword-spacing rule not detect the space?

The short version is, because it intentionally is not designed to do so.

We had to make some decisions on how to make sure rules didn’t conflict with each other. If keyword-spacing and space-before-function-paren both watched the same location, it would be possible for one rule to be configured to require a space, and the other rule to be configured to forbid a space. This would be a horrible user experience. So, in some cases, rules have specific cases they might not enforce, and instead would leave those cases to other rules.

In this case, keyword-spacing chooses to leave the space between function and parentheses up to space-before-function-paren.

I would expect/hope that the documentation for each of those rules to reference the other rule, under related rules at least. I would also hope the rule documentation would point out cases where other rules are responsible. If the documentation can be improved, please feel free to submit a pull request.

• Does that mean there is some kind of internal “priority” (e.g. keyword-spacing has lower priority than space-before-function-paren)? If yes, where can I see this priority?

As I noted above, it’s not really a “priority” system. Instead, rules can collide in certain circumstances and we design the rules with some exceptions to avoid conflicts. So, keyword-spacing simply doesn’t enforce that particular space, and instead we want users to use space-before-function-paren for that case.

• The documentation lists always as the default for space-before-function-paren, though in order to make it do what I want, I had to manually enable and set it to:

This is actually a different issue.

Rules are disabled by default. If you don’t configure a rule (or extend a configuration which configures a rule), then that rule is completely disabled and will not run or report anything.

When a rule is enabled with no options (using syntax like "space-before-function-paren": "error" or "space-before-function-paren": ["error"]), then a rule will operate in a specific way by default. This is what the space-before-function-paren documentation was referring to when it said it uses the "always" option by default. "space-before-function-paren": "error" is the same as "space-before-function-paren": ["error", "always"]. However, you still need to explicitly configure the rule in your configuration in order to turn it on.

---

Also, I would like to apologize about the last response from a team member. It came off as rude, mostly due to language/cultural differences. I will work with that team member to explain that “What’s your problem?” with no other context is a statement that can indicate strong objection, which was uncalled for here and which I don’t believe was intended. He should have said something like “I don’t understand the question. Can you please explain the problem in more detail?” Additionally, your second question deserved a more complete answer than “No”, with more context in order to try to help you understand the underlying concepts.

I hope my answer has helped you and maybe partially made up for your earlier experience.

Thanks again for the issue. I apologize once more for both the unintentional rudeness and the delay in resolving this.