Closed gfx closed 1 year ago
Patch coverage: 100.00
% and project coverage change: +0.06
:tada:
Comparison is base (
daae51c
) 98.31% compared to head (19ff295
) 98.38%.:exclamation: Current head 19ff295 differs from pull request most recent head df46c60. Consider uploading reports for the commit df46c60 to get more accurate results
:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
Hi @gfx, thank you for working on this feature. For the most part it looks good but I wanted to point out one design issue.
I see that you made the deliberate choice to encode and decode bigint
s completely separately from other integers. As a result, this code will always encode a JavaScript bigint
as a msgpack uint64 or int64, even if it is representable by a 32-bit integer or smaller.
For example, if I encode BigInt(1)
with this code it would produce the following byte array: [207, 0, 0, 0, 0, 0, 0, 0, 1]
. However I think many people will expect this to produce [1]
instead, i.e. the same encoding that the JavaScript number
1 would produce.
I say this because it's common for JavaScript msgpack code to be used in conjunction with components written in other languages, which don't have the same number
vs bigint
notion as JavaScript does. The msgpack implementation in these other languages would expect an integer to be encoded using the smallest possible representation, which right now isn't the case.
I understand your reluctance to enable this behavior by default, since as you pointed out bigint
s and number
s should not be used together in arithmetic. However, would you be willing to creating an additional option to make this behavior possible?
This PR introduces a new option
useBigInt64: boolean
, which enables "bigint mode" in this library.Unfortunately, the bigint-mode handles JavaScript numbers completely differently than non-bigint-mode. The following table describes the type mappings.
Because JavaScript's
bigint
is not calculable withnumber
, they should not be mixed. A field that is a bigint must always be a bigint even if it's encoded and decoded by this library.The default value of the option will be changed to true in a future major upgrade. Not sure when I'll do it so far.
ref. #115