GeezerVison

Problem

With useBigInt64: true, encodeBigInt64 branches only on the sign of the value and calls the native DataView.setBigUint64 / setBigInt64. Those methods truncate the value mod 2^64 instead of throwing, so a BigInt outside the representable range is silently corrupted on encode:

import { encode, decode } from "@msgpack/msgpack";

decode(encode(2n ** 64n,         { useBigInt64: true }), { useBigInt64: true }); // 0n
decode(encode(2n ** 64n + 1n,    { useBigInt64: true }), { useBigInt64: true }); // 1n
decode(encode(-(2n ** 63n) - 1n, { useBigInt64: true }), { useBigInt64: true }); // 9223372036854775807n  (sign flip)
decode(encode(-(2n ** 100n),     { useBigInt64: true }), { useBigInt64: true }); // 0n

No error is raised, so the caller has no way to notice the data loss.

Fix

The MessagePack int family is fixed 64-bit, so the only representable range for a BigInt is the union of signed int64 and unsigned uint64: [-2^63, 2^64 - 1]. This adds a range check in encodeBigInt64 that throws for anything outside that range, before the writes.

This matches how the encoder already rejects other unrepresentable inputs (too-long strings, too-large arrays/maps/binaries all throw rather than emit corrupt bytes).

Tests

Extended test/bigint64.test.ts:

• the four out-of-range cases above now throw
• the boundary values still round-trip: 0n, 42n, 2n ** 63n - 1n (max int64), -(2n ** 63n) (min int64), 2n ** 64n - 1n (max uint64)

Full suite: 329 passing, lint clean.