I'm wondering if this section should be flipped to only specify the flags that aren't checked instead of the ones that are?

For now, no tests fail if I switch the logic to the following, where we don't bother with explicit options for or handling of void:

  let flagsToExcludeFromCheck = 0;
  if (options.checkAny !== true) {
    flagsToExcludeFromCheck |= ts.TypeFlags.Any;
  }
  if (options.checkUnknown !== true) {
    flagsToExcludeFromCheck |= ts.TypeFlags.Unknown;
  }
  if (options.checkString !== true) {
    flagsToExcludeFromCheck |= ts.TypeFlags.StringLike;
  }
  if (options.checkNumber !== true) {
    flagsToExcludeFromCheck |= ts.TypeFlags.NumberLike;
  }
  if (options.checkBoolean !== true) {
    flagsToExcludeFromCheck |= ts.TypeFlags.BooleanLike;
  }
  if (options.checkBigInt !== true) {
    flagsToExcludeFromCheck |= ts.TypeFlags.BigIntLike;
  }

  return !types.some(t => isTypeFlagSet(t, flagsToExcludeFromCheck));

Can we come up with some test cases that would

• demonstrate which approach is preferable
• solidify that approach rather than passing with either choice of logic

I haven't thought deeply about which logic makes more sense, so it would be lovely if you have time to give this some thought and justify with examples which way is preferable. Thanks!

For reference, I ask this because:

• prefer-nullish-coalescing does have the "only ignore specific types" approach, rather than "only check some hardcoded types plus allowed primitives" as in the existing implementation of this rule.
• the answer will determine whether creation of a new option is warranted

I will think about it more as I work, but I will leave a quick comment first. The more immediate the communication, the better. Even if it's not accurate!

1. I would recommend adding void options. My philosophy is that the more open source users can customize with options, the more use cases users can cover. (Adding options would likely require some additional documentation changes beyond the current commit.)
2. Since the defaults are given as true, it seems more natural to change to the suggested code. Even better, it prevents optional chaining from being skipped on unexpected types.
3. I guess I need to consider side effects when flagsToExcludeFromCheck = 0.

let allowedFlags = NULLISH_FLAGS | ts.TypeFlags.Object;

All tests will pass if flagsToExcludeFromCheck = 0 for now and I don't think there's a problem at all.(Due to 2), but something feels off because allowedFlags has default value...

Perhaps the test case would be to determine what error/suggestion occurs depending on whether the option is turned off.

Yes, I looked into it further and there is no problem logically even if the default value is 0.
And, I found a tc that causes an lint error even though I set all check options to false.

      {
        code: `
declare const foo: { x: () => { y: string } } | null;
foo && foo.x();
        `,
        options: [
          {
            checkAny: false,
            checkBigInt: false,
            checkBoolean: false,
            checkNumber: false,
            checkString: false,
            checkUnknown: false,
            checkVoid: false,
          },
        ],
      },

// --------------------------------
      {
        code: `
declare const foo: { x: { y: string } } | null;
foo && foo.x;
        `,
        options: [
          {
            checkAny: false,
            checkBigInt: false,
            checkBoolean: false,
            checkNumber: false,
            checkString: false,
            checkUnknown: false,
            checkVoid: false,
          },
        ],
      },

AssertionError: Should have no errors but had 1: [
  {
    ruleId: '@rule-tester/prefer-optional-chain',
    severity: 2,
    message: "Prefer using an optional chain expression instead, as it's more concise and easier to read.",
    line: 3,
    column: 1,
    nodeType: null,
    messageId: 'preferOptionalChain',
    endLine: 3,
    endColumn: 15,
    suggestions: [ [Object] ]
  }
]

In summary, this is a case for nested Objs. So the commit only adds one of the two tc
related commit: 4b92ad4

There are probably a few more, but I'll give them credit for the discovery.
Is there anything else I should know & work? @kirkwaiblinger

This doesn't test anything related to formatting, so there's no reason to use noFormat here. Let's remove it.

?

This should not report (see #11272 (comment)). Please revert.

Please revert these changes, since they turn out not to be related to the necessary changes.