@skanman it appears to be a part of a larger library of constants, some of which make more sense to have as a library. If you pull like a 100 of them they might even outweigh the test frameworks they use to verify that 2^8-1 does indeed equal 2^8-1 and that all browsers are indeed capable of doing basic math that's a part of javascript since its inception.

@Amikke fair enough, but if somebodies biggest concern is testing this constant against every browser ever. It's possible to test them algorithmically without creating dependencies that might accidentally end up in production code. I haven't seen many people create projects that only QA gets a test version that verifies constants. I can see the concern though cause of the get() and set() methods in objects that create hells possible like (a == 1, a == 2, a == 3) // true. But I've been cranking JS algorithms for an eternity and unless you're crafting either some freaky new encryption that's unstandardized, which is actually good practice. I'm not sure where anybody would need this. There's the fringe possibility the application runs in a NodeMCU which isn't using a browser at all but still executing front end code as middleware, but again, the developer would know that's going to happen and just read the documentation for the environment.