This would be a great addition - it's a really common pattern that could be simplified. Though I can see this being an option - I can see some people might prefer the more verbose form.

Though it's worth noting that this would be non-trivial to build and handle all the cases.

What about multiple statements?

if (foo) {
  foo.bar();
  foo.baz();
}

It could be simplified but some would see it as "non-performant".

I think that it'd make sense as an auto fix of a single statement, but not multiple. If anything, if I see this I'd want it fixed in the opposite direction (separate rule):

o?.foo()
o?.bar()
o?.baz()

It's not technically safe to auto-fix multiple statements. An earlier statement might modify the value being optionally chained.

https://typescript-eslint.io/play/#ts=5.2.2&fileType=.tsx&code=JYOwLgpgTgZghgYwgAgGIHt0HF1gQCzmQG8AoZZAIzigAoBKALmQDd1gATAbnKrgC8GzNpx4BfUqQA2EMMhiZmGbLgJEAPsgCuIDhBigIHZAF4SvanXrmKFBelPbd%2Bw915iANBYEMSyCRKkAPRByABC%2BuhQEIykwDDItPbWZHaYAHSWDDxp6Jk%2B9OKSIcgAgjCQUKT2APz5Vjy1%2BYKFQA&eslintrc=N4KABGBEBOCuA2BTAzpAXGYBfEWg&tsconfig=N4KABGBEDGD2C2AHAlgGwKYCcDyiAuysAdgM6QBcYoEEkJemy0eAcgK6qoDCAFutAGsylBm3TgwAXxCSgA&tokens=false

• Before: Cannot read properties of undefined (reading 'baz')
• After: no crash

One shudders to imagine the use case for wanting to preserve the thrown error, but it does technically change code behavior.

It's not technically safe....

See also: ill-behaved getters 😁

I agree with not rewriting multistatement optional chains, but, I think that in general we should follow TS's lead in control flow modelling, where a function call, or, god forbid, a member access, does not invalidate narrowing.