Rule proposal: `space-ops`

This proposal is continually edited. The evolution can be found here

As discussed earlier on #3587, #5553 and #3380, we need a new rule to replace space-infix-ops and space-unary-ops since it became harder to categorize new option requests as ‘infix’ or ‘unary’.

Please describe what the rule should do:

• This rule should be the single, configurable replacement to space-infix-ops and space-unary-ops

• This rule should be configured for each NodeType:

  ConditionalExpression, (Ternaries)

  UnaryExpression, (unary - | unary + | ! | ~ | typeof | void | delete)

  UpdateExpression, (++ | --)

  AssignmentPattern, (function(a=2) { ... })

  VariableDeclarator, (const a = 2)

  AssignmentExpression, (= | += | -= | *= | /= | %= | <<= | >>= | >>>= | |= | ^= | &=, **=)

  BinaryExpression, (== | != | === | !== | < | <= | > | >= | << | >> | >>> | + | - | * | / | % | | | ^ | & | in | instanceof, **)

  LogicalExpression, (|| | &&)

  NewExpression, (new Image(...))

  YieldExpression (function *foo () { yield (0) })

  AwaitExpression (async function foo() { await {bar: 2} })

• The rule seems to need special cases and overrides for specific operators on top of NodeTypes. For instance we’d normally want typeof something and !someBool but since both are UnaryExpressions, it is impossible to enforce a single rule to both to achieve the desired output. For this reason the rule should also have per-operator overrides under a config key overrides: { operators: { or something.

for example:

"space-ops": ["error", {
  "AssignmentExpression": true,
  "BinaryExpression": {
    "before": true,
    "after": false
  },
  "UnaryExpression": {
    "words": true,
    "nonwords": false,
    "overrides": {
      "~": true
    }
  }
}]

• Currently, space-infix-ops allows more than one space around operators. So this rule should also follow that.

• While having extensive configuration options, this rule should also have at least one default configuration

Proposed Default Configuration

{
  "AssignmentExpression": true,
  "AssignmentPattern": false,
  "BinaryExpression": true,
  "ConditionalExpression": true,
  "LogicalExpression": true,
  "NewExpression": true,
  "UnaryExpression": {
    "words": true,
    "nonwords": false
  },
  "UpdateExpression": false,
  "YieldExpression": true,
  "AwaitExpression": true
}

What category of rule is this? (place an “X” next to just one item)

[x] Enforces code style

[ ] Warns about a potential error

[ ] Suggests an alternate way of doing something

[ ] Other (please specify:)

Provide 2-3 code examples that this rule will warn about:

Default parameter spacing: (This will add support for PEP8-style default parameter spacing, which is discussed at #3587)

"space-ops": ["error", {
  "AssignmentPattern": false
}]

// allowed
function foo(param=1) {
  /* ... */
}

// disallowed
function foo(param = 1) {
  /* ... */
}

---

Unary operators (UnaryExpressions / UpdateExpressions / NewExpressions / YieldExpressions / AwaitExpressions):

Non-word UnaryExpressions (!, ~, Unary + and Unary -) and Word UnaryExpressions (typeof, delete, void) can be configured explicitly.

"space-ops": ["error", {
  "UnaryExpression": {
      "words": true,
      "nonwords": false
    }
  }
]

// allowed
delete foo;
-bar

// disallowed
+ 3;
typeof!foo;

---

"space-ops": ["error", {
  "UpdateExpression": true
}]

// allowed
foo ++;

// disallowed
foo++;
--bar;

---

Infix operators (BinaryExpressions / AssignmentExpressions / Logical Expressions):

"space-ops": ["error", {
  "BinaryExpression": true,
}]

// allowed
foo + bar;
foo     + bar;

// disallowed
foo+bar;
foo +bar
foo  +bar

---

Both sides of infix operators can be configured explicitly

  "space-ops": ["error", {
    "LogicalExpression": {
      "before": false,
      "after": true
    }
  }]

// allowed
foo|| bar;
foo&&   bar;

// disallowed
foo     && bar;
foo||bar;
foo &&bar

---

Ternary operators

"space-ops": ["error", {
  "ConditionalExpression": true
}]

// allowed
foo ? "bar" : "baz";
foo   ? "bar" :     "baz";

// disallowed
foo? "bar"  : "baz";

Why should this rule be included in ESLint (instead of a plugin)?

It’s a replacement for two existing eslint core rules

[BYK]

@not-an-aardvark okay this is a more actionable feedback so thanks a lot 😃 Now I and @onurtemizkan have some more work to make this better. 😉

[onurtemizkan]

Thanks for feedbacks, @BYK @not-an-aardvark and @kaicataldo.

I have updated the proposal accordingly. This one has simpler configuration and a default configuration proposal.

Also in my opinion, with this configuration options, this rule source will probably be simpler and easier to extend than its predecessors, if we use ESQuery selectors while implementing it.

Note: I’m editing the first post but evolution of the proposal can be found here