e.g. Int64/long can be marshalled to JS as number or BigInt. Most use cases will be covered with number, which is the current marshalled type. This is a somewhat big assumption (that number covers most use cases), but configurable marshal types seem to add little value at this time.
It'd be preferable to swap the target JS type from number to BigInt for now. If the user does not need such large numbers, they can always convert their C# classes to Int32. Furthermore large long values dont actually fit in number as its 52 bits (wtf), the interop library will throw when encountering such values.
In a nutshell
TypeShim will not support configurable JSType configurations for now.
e.g.
Int64/longcan be marshalled to JS asnumberorBigInt. Most use cases will be covered withnumber, which is the current marshalled type. This is a somewhat big assumption (that number covers most use cases), but configurable marshal types seem to add little value at this time.It'd be preferable to swap the target JS type from
numbertoBigIntfor now. If the user does not need such large numbers, they can always convert their C# classes toInt32. Furthermore large long values dont actually fit innumberas its 52 bits (wtf), the interop library will throw when encountering such values.In a nutshell
TypeShim will not support configurable JSType configurations for now.
long/Int64fromnumbertoBigInt