beaugunderson / ip-address

đŸ’» a library for parsing and manipulating IPv4 and IPv6 addresses in JavaScript
http://ip-address.js.org/
MIT License
580 stars 73 forks source link

Feature: replace `jsbn` with native `BigInt` #169

Closed mahnunchik closed 1 month ago

mahnunchik commented 8 months ago

It would be nice to replace jsbn with native BigInt.

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

beaugunderson commented 8 months ago

I agree but we still use some methods of jsbn that will need to be implemented on top of BigInt… I may not get to it for some months so PRs would be very much appreciated :)

On Sun, Feb 18 2024 at 20:31, Evgeny @.***> wrote:

It would be nice to replace jsbn with native BigInt.

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

— Reply to this email directly, view it on GitHub https://github.com/beaugunderson/ip-address/issues/169, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAPCX4WXNN3YYQR5XE2VWLYULBSTAVCNFSM6AAAAABDOXGCPOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGE2DCNBSGYYDINA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

robmanganelly commented 7 months ago

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 commented 6 months ago

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 commented 6 months ago

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.