js-equality-game | The Worst Minesweeper 💣 Ever

js-equality-game is a JavaScript library. js-equality-game has no bugs, it has no vulnerabilities, it has a Permissive License and it has low support. You can download it from GitHub.

The == or loose equality operator (and its counterpart !=) in JavaScript tries to save the user from having to explicitly convert (cast) values to a common type to make comparisons, so, for example, "5" == 5 implicitly converts (coerces) the string "5" to a number, so the comparison 'just works'. Without loose equality, the same comparison would need to be expressed as either Number("5") == 5 or "5" == String(5), or, at the shortest, +"5" == 5 to be true. The general principle behind having implicit type conversion is called weak typing, and it's useful to the degree that it makes code more terse, but the flip side is that the implicit conversion rules are basically guesswork about what the user would expect, and, as such, can guess wrong and lead to unexpected results. Values that convert to either true or false are called truthy or falsy; for example, 0 is falsy because !!0 or Boolean(0) result in false. Other examples of falsy values are empty strings, null and undefined. Meanwhile, all objects (except document.all) are truthy, so !![] (array object converted to boolean) results in true. One would reasonably expect that being truthy also implies == true and falsy implies == false, but that's not the case: [] is truthy, but [] == true is actually false. Transitivity means that if A equals B and B equals C, then A should equal C, but this is not always true with ==; for example, '' == 0, and 0 == '0', but '' != '0'. Tripple equals or strict equality checking rules are much simpler than ==; objects are compared by identity and primitives by value (roughly speaking), but it's still possible to create subtle type-related error conditions by forgetting to convert the compared values to the same type. For example, the user might compare "1" === 2, intending to compare numbers, and the resulting false would suggest that the comparison is working correctly, even though "2" === 2 would fail. A language like TypeScript would catch these issues, because static typing follows the fail-fast design principle, while dynamic typing ultimately follows garbage in, garbage out – the responsibility is on the user to make sure that the comparison is sound.