Add no-dupe-ternary-expressions

Please describe what the rule should do: The rule will catch and mark as errors any ternary operator that has identical left and right hand expressions. It wall also catch and mark as errors identical ternary conditions which necessarily results in unreachable code.

What new ECMAScript feature does this rule relate to? It does not relate to a new ECMAScript feature, but please indulge me a little and read on. I read the updated contribution guidelines but thought the value of this proposed rule might be high enough despite the fact that it’s not related to new JS features.

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

• Warns about a potential error (problem)

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

const getFee = (isMember) => isMember ? 2.00 : 2.00
// "Error: identical ternary expressions"

thing === otherThing ? getFee(isMember) && myBoolean : getFee(isMember) && myBoolean
// "Error: identical ternary expressions"

Edit: removed examples pertaining to no-unreachable-ternary.

Why should this rule be included in ESLint (instead of a plugin)? I understand that the nature of ESLint is that it’s a pluggable linter and after reading the contribution guidelines, new rules are only generally accepted if they relate to new JavaScript standards/functionality. Considering there are already 200+ rules this principle makes a lot of sense.

Even so, I would argue that duplicate ternary expressions (in the form of statements or conditions) are always and necessarily an error, even if the developer doesn’t at first realise what the ternary (or chained ternary) operator is doing.

Avoiding unreachable code is already a great thing for a linter to detect and if we assume that developers want to be informed when a ternary operator does the exact same thing whether or not the condition it evaluates is true or false, then this rule covers both those cases and would be very valuable in any project.

The rule is stand alone (although relates to no-unreachable and no-unneeded-ternary) and it’s hard to imagine a scenario where developers would not want this rule enabled by default.

For these reasons, I would ask that the ESLint core contributors (hello there!) consider accepting this proposal, which (if accepted and taken as a recommended rule) would be a breaking change and need to be bundled in a major release.

Are you willing to submit a pull request to implement this rule? Absolutely 😸

Do you have an idea how this rule could be implemented? Yes - the implementation would tokenize all expressions as well as all ternary symbols (so [‘:’, ‘?’]) and create an ordered array. Every element inside the array that is exceeded by a ‘?’ token is a condition and every element that is exceeded by a ‘:’ (or if it is the last element in the array) is an expression.

Some exception/logic for handling complex expression (i.e. function calls or boolean expressions) may be needed.

The resulting array could then easily be searched for identical conditions and identical left and right hand expressions.

[GrayedFox]

That said, I did say that I understood that without consensus there was no guarantee of a merge or implementation, and I did also read the docs about new rules relating to new language features, so I will of course accept that outcome if that is the case 🙇🏾‍♂️

[nzakas]

Our official (and documented) policy is that new rules must be related to new language features. Unofficially we might consider new rules not related to new language features if the errors they unveil are serious enough.

To me, this proposal doesn’t meet the bar of “serious enough.” The downside of not flagging this pattern is that everything works. This is flagging an efficiency issue, not really an error.

This seems exactly the case where a plugin makes sense.