The node 10 release line has introduced a native BigInt type along with new syntax for this. It will reach LTS status in October. It would be nice if the Hapi.js ecosystem somehow handles this native type by then.
The simple solution is to add a catch-all clause to the API documentation, which states that BigInt is not supported or used, unless otherwise specified.
From a framework user POV, it would be nice if method arguments or configuration options that currently supports an integer number, also handles it passed as a BigInt. However, this does not go for return values from api calls, where it it needs to be explicit since number and bigint doesn't mix.
Would it make sense to change all integers to be BigInt? With casting for input & configuration? Along with casting non-integer input to a Number?
No matter the handling, this will likely necessitate a breaking change that requires node >= 10.4. It should be noted that a module, which relies on BigInt, can effectively no longer be transpiled using babel, etc.
The node 10 release line has introduced a native
BigInttype along with new syntax for this. It will reach LTS status in October. It would be nice if the Hapi.js ecosystem somehow handles this native type by then.The simple solution is to add a catch-all clause to the API documentation, which states that
BigIntis not supported or used, unless otherwise specified.From a framework user POV, it would be nice if method arguments or configuration options that currently supports an integer number, also handles it passed as a
BigInt. However, this does not go for return values from api calls, where it it needs to be explicit sincenumberandbigintdoesn't mix.Would it make sense to change all integers to be
BigInt? With casting for input & configuration? Along with casting non-integer input to aNumber?No matter the handling, this will likely necessitate a breaking change that requires
node >= 10.4. It should be noted that a module, which relies onBigInt, can effectively no longer be transpiled using babel, etc.