keyword-spacing from merged space-before-keywords and space-after-keywords

[mysticatea]

I thought the way of detecting keywords is the same in space-before-keywords and space-after-keywords, so I made an idea that merges two.
This rule is similar to semi-spacing, comma-spacing, and arrow-spacing.

{
    "keyword-spacing": [2, {"before": true, "after": true}]
}

Note:

• Should check only spacing which is preceded by a closing parenthesis (), ], }) and spacing which is followed by a opening parenthesis ((, [, {). This is to avoid conflicts with semi-spacing, comma-spacing, arrow-spacing, space-in-parens, array-bracket-spacing, object-curly-spacing, block-spacing, space-infix-ops, and key-spacing.
• Should ignore spacing which is preceded by function, return, throw, case, new, delete, typeof, void, or yield. It's checked by space-before-function-paren, space-return-throw-case, and space-unary-ops.
• Should ignore spacing which is between super and (. It's checked by no-spaced-func.

Perhaps space-return-throw-case can be merged if there is an overrides option that is similar to operator-linebreak's.

Original rules are marked deprecated and will be removed at 2.0.0.

---

Could I get your opinion?

I'm happy to work on this if accepted.

[nzakas]

Are all the exceptions you list already implemented in the existing rules?

[mysticatea]

@nzakas No, the first exception is not implemented. So space-before-keywords can be conflicting with semi-spacing, arrow-spacing, comma-spacing, key-spacing, and space-infix-ops (#3878) in the following patterns.

But I'm not 100% sure this exception is proper.

2nd and 3rd exceptions is the same behavior as the existing rules.
space-after-keywords is not checking spacing which is preceded by function, return, throw, case, new, delete, typeof, void, yield, and super.

[nzakas]

Can you explain the first exception some more? I'm not sure I understand what it would do.

[mysticatea]

The first exception limits checking spacing to avoid conflicting with other spacing rules.
(I found missed pattern right now, so I modified a bit)

• Only when the previous token is one of ), ], and }, it checks spacing between the previous token and a keyword.

if (a)var b = 0; // missing a space.

if (a) {
}else {} // missing a space.

// I cannot found any `]` pattern...

//--------

let a;function b() { } // semi-spacing.
(0,function() { }); // comma-spacing.
() =>function() { }; // arrow-spacing.
(function() { }()); // space-in-parens
a[this.b] = 0; // array-bracket-spacing
{function a() { }} // block-spacing
var a = 100 *this.b; // space-infix-ops
var a = {foo:function() { }}; // key-spacing

• Only when the next token is one of (, [, and {, it checks spacing between the next token and a keyword. If space-return-throw-case is merged, there are additional tokens: !, ~, +, -, ++, and -- (these are unary operators).

if(a) { } // missing a space.
class A extends(b ? C : D) { } // missing a space.

class A extends[] { } // missing a space.

if (a) { }
else{ } // missing a space.
class A extends{name: "a"} { } // missing a space.

return(a + b);
return[];
return{a: 0};
return!foo;
return~foo;
return+foo;
return-foo;
return++foo;
return--foo; // missing a space (space-return-throw-case)

//------------

var a = this; // semi-spacing
var a = () => (foo(), this); // space-in-parens
var a = {b: 0, c: this}; // object-curly-spacing

[nzakas]

Ah, I see. Thanks for explaining.

@eslint/eslint-team thoughts?

[nzakas]

@eslint/eslint-team we need to come to consensus on this proposal. Thoughts?

[xjamundx]

Changing rules can be confusing for some folks, so without a bit more clear added value, I'm not overly enthused about it. Does this fit in with other efforts to combine rules? In general I've seen rules go the other way. Obviously a lot of thought has been put into it, so maybe there's more to it than that.

[platinumazure]

👍 from me- I like how many of the other whitespace rules are symmetrical and I appreciate the thought that went into ensuring this new rule wouldn't conflict with existing rules.

[ilyavolodin]

I don't see any problem with merging those two rules. Should be a bit easier to configure for new users.

[nzakas]

@xjamundx we've generally been merging space-before-* and space-after-* into *-spacing rules since people tend to configure both or neither.

If we want to do this, then it would be good to get into 2.0.0, otherwise we'd need to wait until 3.0.0.

[xjamundx]

Makes sense 👍

[mysticatea]

And may I merge space-return-throw-case also?
returns, throw, and case are keywords...

[nzakas]

What would configuration for this new rule be with all these options?

[mysticatea]

My plan for options of this rule:

{
    "keyword-spacing": [2, {"before": true, "after": true, "overrides": null}]
}

• "before" (boolean, default is true)
  • If true, this rule checks there are space(s) between a keyword and the previous token of the token. If there are not the space(s) followed by a keyword, it warns the keyword.
  • If false, this rule checks there are not space(s) between a keyword and the previous token of the token. If there are the space(s) followed by a keyword, it warns the keyword.
  • If the previous token is none of ), ], and }, this rule does nothing for this.
• "after" (boolean, default is true)
  • If true, this rule checks there are space(s) between a keyword and the next token of the token. If there are not the space(s) preceded by a keyword, it warns the keyword.
  • If false, this rule checks there are not space(s) between a keyword and the next token of the token. If there are the space(s) preceded by a keyword, it warns the keyword.
  • If the next token is none of (, [, {, !, ~, +, -, ++, and --, this rule does nothing for this.
• "overrides" (object|null, default is null)
  • Keys are keywords, and values are an option object to overwrite.
    For Example {"if": {"before": true, "after": false}, "case": {"after": true}}

[nzakas]

Sounds good, let's try to get this into 2.0.0.

[nzakas]

Sounds like this would also fix: #4006

[mysticatea]

I'm working on this.
There are so many test cases!

[mysticatea]

I'm writing tests to check that it doesn't conflict with space-infix-ops.

space-infix-ops seems to not check in and instanceof operators.
Because it's checking only punctuators: https://github.com/eslint/eslint/blob/master/lib/rules/space-infix-ops.js#L33
But this operators list includes in and instanceof : https://github.com/eslint/eslint/blob/master/lib/rules/space-infix-ops.js#L14

Which is intentional behavior of space-infix-ops?

[ilyavolodin]

@michaelficarra Do you remember what was intended for space-infix-ops? I would guess in and instanceof should be checked.

[platinumazure]

@ilyavolodin Speaking as an end user, I would expect any infix operators (punctuation or word) to be checked. That said, how common is that anyway?

[nzakas]

Related discussion: #3587