Should we extend no-constant-condition to catch comparisons that are constant due to type mismatch?

What rule do you want to change?

no-constant-condition

Does this change cause the rule to produce more or fewer warnings?

More

How will the change be implemented? (New option, new default behavior, etc.)?

New default behavior

Please provide some example code that this change will affect:

(a + b ?? c)

(!foo == null)

(!foo ?? bar)

((a + b) / 2 ?? bar)

const bar = String(foo); (bar == null)

(String(foo.bar) ?? baz)

const bar = <div>Hi!</div>; (bar == null)

(<div>Hi!</div> ?? foo)

("hello" + name ?? "")

([foo?.bar ?? ""] ?? [])

What does the rule currently do for this code?

Nothing

What will the rule do after it’s changed?

Warn/Error

Are you willing to submit a pull request to implement this change?

Possibly

No Useless Null Checks

There are some types of comparisons which we can tell statically will always create the same result. One such example is performing a null check on an ObjectExpression. In many cases, these type of coding errors are harmless since they merely guard against edge cases which can’t actually exist. However, in other cases they represent a misunderstanding of how the code will behave. For example:

• a + b ?? c Misunderstanding of operator precedence.
• <SomeComponent /> ?? <Fallback /> Incorrect assumption about JSX returning the result of render function

no-constant-condition guards against many of these types of errors but it does not currently try to understand comparisons that are constant due to the statically knowable type of the values being compared.

My question is: should it?

On one hand this seems like these are constant conditions that ESLint can determine, so it should! On the other hand, if ESLint wanted to report all possible constant conditions of this sort, it would end up implementing a type system, which is clearly out of scope for this project.

Speaking of type systems, it’s worth noting that many of these errors, type systems (Flow and TypeScript) do not currently report as errors.

Faced with the question of “how far should a rule like this go?” I decided to pick an arbitrary subset of “constant comparisons to null” and write a rule specifically to check for that. You can find it here.

Surprisingly it found hundreds of errors in our (very large) code base, so I believe the rule has some non-trivial value.

I would be curious to hear any maintainer’s thoughts on if this would be a good addition to no-constant-condition, of if it seems out of scope in some way.

If the rule that checks for constant null comparisons seems like a good addition, then it might be worth considering other similar checks that could be performed, such as constant boolean comparisons: {} || fallback.

Thanks to @bradzacher for some initial insight which lead to this rule.

[ljharb]

That’s a really good point, thanks for clarifying.

[captbaritone]

I can work on this. Busy this weekend, but can pick it up next week.