That is how it evaluates, not what the original author intended in the example in the OP.

    return a === b ?? c;

The intent was

    const bOrDefault = b ?? c;
    return a === bOrDefault;

You posted the actual (buggy) evaluation. I agree that its better if that is what you intend.

Wait, your example doesn't even make sense to me on second thought (and was the ultimate point in the article)

aIsB is guaranteed to not be null or undefined so the ?? is a no-op. You just did a comparison so it's either true or false.

I was referring particularly to my parent's point about adding parentheses to remove ambiguity. That prettier oftentimes removes parentheses that I explicitly want. So rather than risk that, I remove the ambiguity by moving one of the comparisons off into a named variable.

I agree.

I was just pointing out that this is a case prettier wouldn't do anything. The expression parses differently and adding or removing parentheses to any subexpression will change its meaning.

That by manually doing the transform in your example that you would realize your cody was a no-op or that the intended version was what I posted.