[shakna]

But frustratingly, a JS BigInt is nothing like a BigInt in any other language.

In JS - BigInt is 64bit integer.

In anything else - BigInt is a arbitrarily large integer.

[anematode]

Hm? JavaScript BigInts are arbitrary precision, and you need to use methods like BigInt.asIntN(64, a) to convert them to 64 bits

[mort96]

I hate this so much because you can’t nicely serialise a BigInt as JSON. Using a string is nicer but it only makes sense where int64 is used as an ID, not where it’s used as a number; and you don’t wanna have to configure this per field per query.

[sheept]

You can serialize a BigInt by specifying a replacer:

    const obj = { a: 9007199254740993n }
    JSON.stringify(obj, (_key, value) => typeof value === 'bigint' ? JSON.rawJSON(value.toString()) : value)

[mort96]

And then you end up with strings on the other side, not numbers.

[sheept]

No you don't? The example I gave produces

    {"a":9007199254740993}

not

    {"a":"9007199254740993"}

[mort96]

Oh, that's much worse! The JSON string `{"a":9007199254740993}` decodes to the object `{"a":9007199254740992}` with typical JSON parsers like JavaScript's `JSON.parse`.

[marcosdumay]

IMO, I'm tending toward thinking that having types on your readable serialization format is a mistake, and that they should be always input to the (de)serializer instead.

[nh2]

JSON has arbitrary length numbers in the spec only.

[mort96]

Completely and utterly irrelevant.

[Etheryte]

This is simply not true? Or maybe I misunderstand what you mean?