Proposal: Represent int64 as BigInt in JavaScript/TypeScript

[VojtechVitek]

int64 is too big for JavaScript's Number type (IEEE-754 double-precision floating point).

JavaScript looses precision on values higher than Number.MAX_SAFE_INTEGER (9007199254740991) and rounds them up.
Technically, we could error out in JS runtime, if we notice values bigger than that if we decide to keep Number in JS/TS generators.

Current workarounds:

message User
  - id: string
    + go.field.type = int64
    + go.tag.json = id,string

message User
  - id: string
    + go.field.type = prototyp.BigInt # sequence prototyp

Proposal - switch to BigInt

I think it would make sense to represent int64 as BigInt in JavaScript and TypeScript generators. BigInt looks to be well supported.

[pkieltyka]

btw, I completely agree we should add a new BigInt primitive type to webrpc which could be a viable option on Go/TS/other

[VojtechVitek]

We already have int64 primitive type in webrpc and it doesn't fit JavaScript's number. It can produce bugs.. Should we change it to BigInt() in JS?

If we're to add a new BigInt primitive -- would that mean values beyond 64bits, i.e. "math/big" in Go and BigInt() in JavaScript?

[austinmilt]

webrpc is really only compelling if it creates an explicit contract between client and server. In that sense, it should try to ensure that numbers are treated the same way regardless of the environment in which they are used. However,

• both int and uint are supported in webrpc schemas, but by convention these refer to the default width supported by language and platform which may vary between client and server. In addition to adding BigInt support, I'd consider removing int and uint from support for this reason.
• while using BigInt in JS/TS (and by extension Dart) is probably necessary, a BigInt primitive type in webrpc weakens the contract of the schema that other declarations like uint64 and int32 provide. My guess is that if a developer thinks they need an arbitrarily-sized integer, they havent really thought about the design of their system. I'd rather see webrpc support int128, int256, etc.