ES10 BigInt datatype

[zemse]

Hi, I've been using Ethers.js for a while and very much loving it. I just noticed the new ES10 BigInt primitive datatype (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt) implemented in my Chrome browser.

You can simply type 100n in your browser console. You will see BigInt in green (like we see Number in blue). You can also try doing typeof 100n to see something new. You can try seeing the difference by doing 125**282 vs 125n**282n.

At my company, non-blockchain developers always have a hard time understanding the concept of Big Number objects and why they need a separate library for adding and subtracting numbers in Javascript while there is no need in Python. But finally, now that we have a native BigInt type in JavaScript, we can make things better.

My purpose for creating this issue is to know if Ethers.js community is already planning to implement this in the upcoming versions, if yes then can I help on it?

Got my entire office changed from web3.js to ethers.js because this library is doing great. I would like to contribute my time to make it even better for new developers joining the Web3.0 world.

[ricmoo]

The v5 of ethers already supports the native BigInt any place a BigNumberish can be used, and will not throw exceptions when used for values that are unsafe for IEEE 754 values.

The results of all functions are still the BigNumber class though, since most environments will not support the BigInt for a while. I aim to continue supporting a variety of platforms, and Expo/ReactNative apps don't support it (maybe the newest version? but not most people maintaining their apps are running these), and PhantomJS is still a target (which may be dropped for v5), Duktape, Otto, slightly old nodejs and slightly old Andriod/iOS, and Safari do not support it yet. Basically, it cannot replace BigNumber... yet. But this is also the reason why ethers uses its own BigNumber wrapper, which will make it easier to swap out without affecting any consumers.

There will likely be an instance method that will return a BigInt (similar to the instance.toNumber()) to make it easier to use too. TypeScript still doesn't support BigInt (unless something has changed very recently), but I may just use any for now, with documentation indicating that this will be replaced in the near-future to use whatever TypeScript agrees on.

I do worry a bit about people using the BigInt, since all the same problems still exist, they just become far less obvious. Their existence is still a huge win, and I'm looking forward to using them, but I can already imagine the beginning of all the issues that will arise as a result of 3n * 1, and why 1000000000000000000n works, while 1000000000000000000 throws. People will also still do wildly unsafe things too; the number of times I've seen a unary + to cast a string to a number is scary... :p

Long story short, yes, it's in the pipeline. :)

[zemse]

The v5 of ethers already supports the native BigInt any place a BigNumberish can be used, and will not throw exceptions when used for values that are unsafe for IEEE 754 values.

That's great, I'll try out v5. Used to see it always in npm show ethers versions but didn't try yet. Seeing the beta.155 I just got a feeling that I'm going to see plenty of new things in it.

I do worry a bit about people using the BigInt, since all the same problems still exist, they just become far less obvious. Their existence is still a huge win, and I'm looking forward to using them, but I can already imagine the beginning of all the issues that will arise as a result of 3n * 1, and why 1000000000000000000n works, while 1000000000000000000 throws. People will also still do wildly unsafe things too; the number of times I've seen a unary + to cast a string to a number is scary... :p

Just like '1' + 1 converts Number into String and does the operation (because Number to String is possible but reverse is not always), 100n + 1 or 100n * 3 should convert Number into BigInt as any number can have BitInt version. This might bring down errors but would be inefficient due to data type changes. Really need to wait for what TypeScript agrees on. Thanks for your response.