fix: emit valid JS for BigInt64Array and BigUint64Array in uneval

[elliott-with-the-longest-name-on-github]

Problem

uneval renders typed-array elements by interpolating the array directly into a template string, which invokes Array#toString and produces bare numbers:

uneval(new BigInt64Array([1n, 2n, 3n]))
// → 'new BigInt64Array([1,2,3])'

But the BigInt64Array/BigUint64Array constructors require bigint elements, so the emitted code throws when evaluated:

Cannot convert 1 to a BigInt

This affects any BigInt64Array/BigUint64Array whose buffer isn't separately shared (the common case), including subarrays. There was previously no test coverage for these two types.

Fix

Emit bigint elements with an n suffix (e.g. new BigInt64Array([1n,2n,3n])) via a small stringify_typed_array_elements helper used by both the inline and the deduplicated (hoisted) code paths. Non-bigint typed arrays are unchanged.

Scope

• stringify/parse were not affected — they encode the underlying ArrayBuffer as base64 and rebuild the view from bytes, so elements are never stringified individually.
• The uneval shared-buffer path was also already correct (it reconstructs from the buffer); only the inline-elements path was broken.

Tests

Adds fixtures for BigInt64Array (with a negative value) and BigUint64Array, plus a repetition fixture, which run through the existing uneval / stringify / parse / round-trip harnesses.

[changeset-bot]

🦋 Changeset detected

Latest commit: 8bc2da9

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
devalue	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR