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.