serde_v8::from_v8 for BigInts unsupported through `deserialize_any`
Deserializing BigInts is currently not supported unless a specific type is requested (e.g. it's unsupported through
deserialize_any path: https://github.com/denoland/deno_core/blob/main/serde_v8/de.rs#L131). This means that, for example, an object containing a field with a BigInt value cannot be deserialized. I assume this is because it's unclear which rust type to map it to?
If so, are there any issues with the following mapping rules?
- If the BigInt < 0 and within i64 bounds, then deserialize as i64
- If the BigInt >= 0 and within u64 bounds, then deserialize as u64
- Otherwise throw an errorGitHub
deno_core/serde_v8/de.rs at main · denoland/deno_core
The core engine at the heart of Deno. Contribute to denoland/deno_core development by creating an account on GitHub.
2 Replies
I wasn't able to find the answer to your question in the official Deno documentation. However, based on the information you've provided, it seems like you're discussing a specific issue with the
serde_v8 library related to deserializing BigInts.
From what you've described, it does seem reasonable to map BigInts to i64 or u64 based on their value and whether they fall within the bounds of those types. However, this advice is not based on the Deno documentation, and I would recommend double-checking the accuracy of this approach. It's important to consider the implications of such a mapping, including potential loss of precision for BigInts that exceed the bounds of i64 and u64.
If you're considering implementing this mapping, you may want to look into how other systems handle similar situations or consider contributing to the discussion on the relevant GitHub issue or pull request for the serde_v8 library. It's also a good idea to consider the use cases of your application and whether this mapping would meet the needs of your users.In retrospect, this seems more appropriate as a GH issue