Wasn't sure how to title this and will preface this by saying I understand the semantics of nullish coalescing, and why the prefer-nullish-coalescing exists, but in it's current state, it's quite troublesome to enable. My story:

• I recently applied this rule to our codebase, as a warning, which revealed hundreds of call sites. Pretty awesome stuff that it takes the types into account and flags them correctly.
• I then ran --fix on them all, which worked. Ok cool, this is even more awesome.
• I then ran our test suite, which started failing over the place. Uh oh, this isn't going to be fun...

The crux is that we use empty string/JSX fall-through patterns a lot, for example providedMessage || "Fallback message". The rule however will flag this (rightly so since the value isn't null or undefined, but a string) and convert it to providedMessage ?? "Fallback message", which is entirely incorrect as it will break our expectation/render.

I hope you see the problem here. In it's current state, we have the following options, none of which are ideal/easily solved.

• Enable the rule and rewrite our code to use verbose checks instead of fall-through logic.
• Enable the rule and add eslint-disable-next-line comments all over the source for all these string (and number) call sites.
• Disable/not use the rule and lose all insights.

The 1st option is probably the best past forward, but is also a lot of work, sometimes too much work. The 2nd option is the worst for obvious reasons. The 3rd option is "acceptable" but we lose so many benefits provided by this rule.

I'm not really looking for a solution here, but hopefully spark some conversation on this, as I'm sure others will run into this.

Possible solutions

• Not flag || usage where the left and right sides are both the same type (strings, numbers, etc).
• Have the fixer not convert patterns where the left side is a string.
• Add some rule options to avoid flagging it if the left side is a string (or number)?