Change from == to === in code generators

[jschanker]

Describe the bug

In the conversion from == to === in PR #5599, some strings of generated code were changed as well:
E.g., for checking if a number is prime:
https://github.com/google/blockly/blob/49c99377540a7bfd5ef612cb38663d754dedb195/generators/javascript/math.js#L161

Or for checking if a number is even: https://github.com/google/blockly/blob/49c99377540a7bfd5ef612cb38663d754dedb195/generators/javascript/math.js#L183

Expected behavior

I'm not sure if this change is intended or not because while using === is the new preferred style, it breaks backward compatibility.

Additional context

My students were in the process of correcting a bug in operator precedence and had based their changes on the original repository with ==. Once it changed to === some generator tests failed (https://github.com/RichDoherty/blockly/pull/10/checks#step:8:97).

[NeilFraser]

Confirming, this is a bug. We never intended to change the output of existing code.

Specifically, the following code used to treat the input as a number and return true:
https://blockly-demo.appspot.com/static/demos/code/index.html#384y9p
Whereas the new === version will fail to cast the input, and returns false.

Will fix this ASAP. Will take a little while to ensure that I get all the different places this affects.

[NeilFraser]

I've finished analyzing the code. There's only one line that introduces a change in execution behaviour, the mathIsPrime function:
if (n === 2 || n === 3)
All the rest of the equality conversions are safe.

However, your comment indicates that any change (even a non-functional one) to the generated output breaks backwards compatibility. We'd only consider it a breaking change if the execution of the generated output produced different output. Can you clarify why you'd categorize any change in the JavaScript to be breaking backwards compatibility?

I'll hold off on submitting my PR for the above issue until I get a better understanding of the issue you are facing.

[jschanker]

This isn't an issue for anything I'm working on, but what if for example, a teacher were using the generated JavaScript code to automate the checking of a student's solution?

Also, for users trying to learn how to program by examining the code the blocks generate, it might be a little confusing to initially see == and then later see === after the update. When I introduce == and === together, students will always ask me questions about the difference between the two (even after I've explained the difference and they've understood).

Leaving it as === where code execution remains the same seems reasonable to me, I just wasn't sure if this was intentional or not. I think it might be good to list it as a potentially breaking change though even though it seems likely that no one's code will be directly affected.

[NeilFraser]

Fixed the case of passing the strings '2' and '3' to isPrime.

As for the code changes which don't affect execution, we are trying to generate code which is legible and matches user expectations. As of late, === has emerged as the default equality operator in the JavaScript world. Personally I prefer ==, but consistency with the rest of the world is more important.

[jschanker]

@NeilFraser Sounds good. Thanks for the quick fix!