We may want to look into sharing logic with prefer-optional-chain since that has lots of analysis in similar area

Indeed I'm interested!

More realistic test case with false positive (playground)

const test1 = nullOrObject !== foo && bar != null
  ? nullOrObject
  : 42;

Actually - I think this was a case of #10724 and is fixed in #10732

@kirkwaiblinger,

#10732 fixes your second use case:

const test2 = nullOrObject !== foo && null !== null
  ? nullOrObject
  : 42;

https://deploy-preview-10732--typescript-eslint.netlify.app/play/#ts=5.7.2&fileType=.tsx&code=CYUwxgNghgTiAEYD2A7AzgF3igrhCA8jAQEYBW4GAXNnhPAD7wDe8UNmMAligObwBfANwAoUJFgJk6LADMkSGlBQBPESOmZ4GEJgCM8ALy18RUhTBYAhIeM4UoWTxDB4AMjcn6N47nwj4eAB%2BLzNySgD4GgAWACZRDVQtHUxYo1DicMt4H3h5JHdPP29bL0iQ4rCLDEiY%2BKA&eslintrc=N4KABGBEBOCuA2BTAzpAXGYkACAXAngA4oDG0AlobgLQrzkB2uA9IdIgGaLTUML3IAFtRIB7AIZJkJRgHN0UbtFHRIAXxBqgA&tsconfig=N4KABGBEDGD2C2AHAlgGwKYCcDyiAuysAdgM6QBcYoEEkJemy0eAcgK6qoDCAFutAGsylBm3TgwAXxCSgA&tokens=false

Also to consider:

declare let x: { a: string } | null

x?.['a'] ? x.a : 'foo'
x?.a ? x.['a'] : 'foo'

// see `prefer-optional-chain`
x !== null && x.a ? x.a : 'foo'

Also to consider:

declare let x: { a: string } | null

x?.['a'] ? x.a : 'foo'
x?.a ? x.['a'] : 'foo'

I raise you this abomination (false positive) 😁:

const a = 'b';

declare let x: { a: string, b: string } | null

x?.a != null ? x[a] : 'foo'

Let's spin off a separate issue for that (both would fall under the umbrella that we should potentially use the static member access utils to compare the property being accessed... or maybe we just need to be careful about checking for computed member access in isNodeEqual?)

// see `prefer-optional-chain`
x !== null && x.a ? x.a : 'foo'

Hmmmm. I guess yeah this could technically be converted (subject to ignorePrimitives) but it seems ok to me if it's first flagged by prefer-optional-chain to simplify it into something that this rule can better analyze... But, maybe we can reuse some of the analyzeChain code and get this type of case somewhat "for free" in prefer-nullish-coalescing? I'm not sure 🤷‍♂

I raise you this abomination (false positive) 😁:

😱

I’ll file an issue.

// see prefer-optional-chain
x !== null && x.a ? x.a : 'foo'

Hmmmm. I guess yeah this could technically be converted (subject to ignorePrimitives) but it seems ok to me if it's first flagged by prefer-optional-chain to simplify it into something that this rule can better analyze... But, maybe we can reuse some of the analyzeChain code and get this type of case somewhat "for free" in prefer-nullish-coalescing? I'm not sure 🤷‍♂

At first I thought going for the "for free" option, but maybe someone disabling the prefer-optional-chain on purpose would be unhappy with it, although it’s true that the ones enabling it would benefit (on a 2-step basis).

At first I thought going for the "for free" option, but maybe someone disabling the prefer-optional-chain on purpose would be unhappy with it, although it’s true that the ones enabling it would benefit (on a 2-step basis).

Oh, yeah, that's a good point. I think, since you can't actually fix it without optional chaining (e.g. (x !== null && x.a) ?? 'foo' has wrong semantics) maybe yeah we should leave that case up to the prefer-nullish-coalescing entirely. But good spot!

@kirkwaiblinger, did #10861 address everything you had in mind? If so I think the issue can be closed.

Cc @JoshuaKGoldberg

Yep, looks like it! Thanks again for your work on this! ❤