Update: check ternary : even if ? was reported in space-infix-ops

[mdjermanovic]

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update
[X] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:

Tell us about your environment

• ESLint Version: v7.16.0
• Node Version: v12.18.4
• npm Version: v6.14.6

What parser (default, @babel/eslint-parser, @typescript-eslint/parser, etc.) are you using?

default

Please show your full configuration:

Configuration

module.exports = {
  parserOptions: {
    ecmaVersion: 2015
  }
};

What did you do? Please include the actual source code causing the issue.

Online Demo

/* eslint space-infix-ops: "error" */

a ?b :c

What did you expect to happen?

Since this rule reports and underlines operator tokens, I'd expect two errors: one for ?, the other for :.

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

Only 1 error, and it underlines only ?

  3:3  error  Operator '?' must be spaced  space-infix-ops

Nonetheless, the multi-pass --fix correctly fixes the code to a ? b : c, because fixing the error for ? causes the error for : to appear.

What changes did you make? (Give an overview)

Changed the space-infix-ops rule to report : if it isn't spaced, even when ? from the same ternary expression was already reported.

Is there anything you'd like reviewers to focus on?

• Am I missing something?
• One report used to hide another, so this change shouldn't normally cause new reports in a lint-free code. However, I marked this as an Update since it can produce more reports (which might matter with --max-warnings), and it could even make a lint-free code to fail in some edge cases, like this:

/* eslint space-infix-ops: "error" */

a
    ?b // eslint-disable-line space-infix-ops
    :c

[nzakas]

Stylistic rules are frozen because we don’t want to spend time maintaining them anymore. I’m not sure this is worth fixing at this point.

[mdjermanovic]

I found this while checking how the newly added multiline-ternary fixer works together with space-infix-ops. It looked like an oversight and an easy fix, but I'd be fine with closing this.

[nzakas]

Understood. It’s just that if we say rules are frozen, and then constantly make little changes, we lose credibility and basically end up in the same situation we had prior to freezing the rules where we need to evaluate every request. Unless you or someone else feels strongly about this, I’d rather stick to our policy.

[nzakas]

TSC Summary: this PR fixes a slight bug in space-infix-ops. Per our policy, this rule is frozen so we are no longer making changes to it.

TSC Question: Should we close this PR without merging?

[btmills]

We collectively forgot that our policy already says we'll fix bugs, so this PR is good to go.