Right now this is "working as intended"
The rule is built around the idea of reducing the number of truthy/falsy states that are evaluated in a condition.

if (boolean | object | undefined) {} has:

• 2 truthy states:
  • true
  • object
• 2 falsey states:
  • false
  • undefined

With your options - you've specified that you don't care about the undefined case (eg for the purposes of the rule, there's only 1 falsey case).
However this means we still have 2 truthy states.

Which begs the question: "is true intentionally treated the same as object exists?"
They're distinct values - do they mean the same thing logically?

The question is - how should we handle this?
What's the correct behaviour? From a strictness / case handling POV - the rule is correct in flagging this.
From a user's perspective - I can definitely understand how this is a surprising result.

Yeah, I definitely come down on the user's side on this one 😉 Mainly because given the settings, if the value were either of the two truthy states it would be allowed, so I would want the combination to be allowed. But if extra strictness is desire/required, maybe have a strictUnions option or something that would opt into that behavior?

It works fine in this case. This rule is all about being explicit. You should write your condition as something like value != undefined && value !== false and it should work. The whole reason for this rule is to make the conditions explicit about what values they check.

Try using != null. It's shorter, understood by TS and clear to developers.

children != null && <div>{children}</div>

At Facebook the entire codebase exclusively uses == null checks because in flow there is the "maybe" operator (?boolean means boolean | null | undefined). Because of the operator we never annotate | null manually, so we always have to check for undefined in code. IMO it's a huge improvement in coding style.

Thanks, that's interesting; so it sounds like you don't enforce triple-equals in TS. That makes sense; I hadn't even considered that eqeqeq ceases to be a useful rule once you've got all these TS rules up and running in their place. I'm definitely going to give that a try.

so it sounds like you don't enforce triple-equals in TS.

On the contrary - eqeqeq is enabled, but we have the option turned on which allows you to use double equals specifically for comparisons with null

See the end of this section: https://eslint.org/docs/rules/eqeqeq#always

"eqeqeq": ["error", "always", {"null": "ignore"}],

Wow, that is 1000x better than what I was doing, thank you!

Edit: "eqeqeq": ["error", "smart"] is great as well.

I believe this issue can be closed

Indeed. I think the rule is working as intended, as previously mentioned. There are two falsy cases in type boolean | { prop: any } | undefined; the intent of the rule is to stop checks on them from happening.

One could make an argument that the combination of allowNullableBoolean and allowNullableObject should stop that case, but each argument on its own is only meant to target a type union of just that type + nullable.

Marking this as working-as-intended because of all that, and that there's been very little activity on this issue in the almost 2 years it's been open. Feel free to post back or make a new issue if you think this is incorrect! Thanks all!