Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: replace jsbn with native BigInt #169

Open
mahnunchik opened this issue Feb 19, 2024 · 4 comments
Open

Feature: replace jsbn with native BigInt #169

mahnunchik opened this issue Feb 19, 2024 · 4 comments

Comments

@mahnunchik
Copy link

It would be nice to replace jsbn with native BigInt.

It is widely supported even in browsers https://caniuse.com/bigint

@beaugunderson
Copy link
Owner

beaugunderson commented Feb 19, 2024 via email

@robmanganelly
Copy link

robmanganelly commented Apr 2, 2024

Please consider (when you are taking this step) also providing a proper implementation of toJSON that doesn't expose bigint. This is forcing consumers to implement themselves, because JSON.stringify cannot serialize bigints,
Curent implementation has this issue too.

Thanks for the great job guys

@silverwind
Copy link

silverwind commented Apr 26, 2024

Please consider (when you are taking this step) also providing a proper implementation of toJSON that doesn't expose bigint. This is forcing consumers to implement themselves, because JSON.stringify cannot serialize bigints, Curent implementation has this issue too.

Thanks for the great job guys

You can easily serialize BigInt into JSON with a replacer function:

JSON.stringify(obj, (_, v) => typeof v === 'bigint' ? v.toString() : v)

@robmanganelly
Copy link

Yes it can be done, but it means that you could inadvertently break something down the stream. It happened to me and I ended patching my serializer with a custom replacer, and it also happened on another project, which ended with a slightly different version of the replacer. This mean that the same class might have a different serialization in every project, which is not ideal IMHO. This is why added the recommendation, because that way you will ensure that the class gets serialized in the same way in every place, and can define your own rules for hydration, perhaps with static methods, or any other variant. ensuring consistency at the end of the day.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants