"Make more readable" looks awful too, the correct output would've been something like:

    (a == null || b == null) ? NaN :
    a < b ? -1 :
    a > b ? 1 :
    a >= b ? 0 :
    NaN;

That’s not readable at all. Chaining ternary operators like that is much worse than the code the article shows.

Maybe it’s a stylistic choice, but there’s nothing wrong with a sequence of “else ifs” as long as you don’t go deeper (like in the example)

Chained ifs add a whole lot of visual noise, aren't guaranteed to be total, and introduce the temptation to add more logic into the cases.

That said, I do wish more languages had copied Haskell's guard syntax for this kind of chain... For reference, that looks like:

    cmp x y | (x == Nothing || y == Nothing) = NaN -- (assuming x and y are Maybe, but this would typically be non-idiomatic)
            | x < y = -1
            | x > y = 1
            | x >= y = 0 -- inert bug copied from original, "should" be == instead
            | otherwise = NaN

I too always find myself wanting features from functional languages, I haven't done much Haskell but love the syntax for pattern matching in Elixir with guards, plus the pipe operator.

This would be a perfect case for a match expression, which, surprisingly, PHP now supports:

  return match(true) {
    $a == null && $b == null => null,
    $a < $b => -1,
    $a > $b => 1,
    $a == $b => 0,
    default => null;
  }

I’m surprised this feature isn’t prevalent in modern languages. It makes the code so concise and easy to understand, it’s marvellous.

What interests me here is that both your version and the else if version perpetuate the error in the original code which is the case where a is greater than b, which is handled once by a greater than comparison, and then again by a greater than or equal to comparison, which is clearly redundant. Neither CoPilot, nor you, nor the article author I presume caught this error in the flow control. Catching errors like these adds more value then making it more readable, although making it more readable certainly did expose the error more clearly to me.

I did notice it but wanted to keep the AST identical. But yes, it would have been worth pointing out, heh.

Actually it is not redundant as >= do numerical comparsion (so convert a and b to number) while == do not do that. So it has different result on objects.

You learn something new every day! I have written JavaScript off and on for years and did not encounter that.