Full BigInt support in ethers.js?

[egorFiNE]

Hello.

I would like ethers smart contract instances to return the BigInt native type for the numeric values instead of BigNumber. Are there plans to shift out of BigInt? Or maybe make it configurable like contractInstance.numberFormat = 'BigInt' or similar.

(Meanwhile I have created a small helper to recursively convert resulting values to BigInt.)

[frangio]

It's hard to overstate how important the migration to native BigInt will be for the ecosystem. Ethers 6 can play a big role in that.

Ideally, Ethers.js should simply return BigInts by default. If not, there should at least be a way to opt in to it.

BigInt is widely supported in all modern browsers.

Node 12 will be End-Of-Life on April 30th 2022. Node 14 and Node 16 already support native BigInt.

[ricmoo]

I had a long response to this, but while reviewing some of my research notes and updating them, found that many of the bottlenecks have become less of a hurdle, some even recently.

First off, let me just say I would LOVE to move to ES2020 BigInt. Numbers and maths are hard, and have plenty of room for mistakes. The ethers BigNumber library has been a lot of work to keep happy and keep the people who use it as happy as possible. It is also a tonne of code that exists, merely so people can add two numbers together in a way that is safe.

One issue still lies with Goja which does have a Pull Request open, but it looks like there may be issues with it. But this is one the main points of my resistance: ethers is used in many places, in various platforms and environments. For example, if it were to move to BigInt, ethers would no longer work in Geth, which uses Goja.

But with community assistance, these areas can be improved for everyone. :)

Regardless, I've added a poll to my twitter, in case anyone wishes to comment in a more impromptu fashion. :)

https://twitter.com/ricmoo/status/1499763668745084929?s=21

[frangio]

ethers would no longer work in Geth, which uses Goja

But Ethers 5 would continue to work in this environment. Although obviously we don't want Ethers 5 to have to be maintained forever, could it be an acceptable compromise until BigInt support is added?

[ricmoo]

And that is precisely why I'm reconsidering this. Maintaining v5 longer than usual is not high on my desires, but I've already started planning around it, if this comes to fruition, and v5.6 hopefully kicks the can down the road a bit on maintenance with important features that I wasn't planning to release until v6. :)

[egorFiNE]

@ricmoo Can I build ethers 6 and give it a try? I'd love to! Maybe even in production in some minor contract interactions. I would love to code to support BigInts.

[ricmoo]

I’ll be releasing a beta soon. Still waiting for more feedback on exposed BigInt support on twitter though if you have any views. :)

[egorFiNE]

Hey hey
Any updates on the beta? :)

[ricmoo]

npm install ethers@beta :)

It’s in the v6-beta branch of this repo, but there is not much in terms of docs yet…

[egorFiNE]

there is not much in terms of docs yet…

Excellent! What are the main changes to note?

[ricmoo]

Quite a bit, and I haven’t had time to create the migration docs, so for now it’s more of a “check out the .d.ts files if you need help”. Which is also why I haven’t made too much of a public announcement yet.

[sambacha]

fwiw using a library like JSBI shows minimal overhead https://gist.github.com/sambacha/e96b6248a068e76d542aa922358c2b13

edit: you can get more info here about the perf. diff https://bugs.chromium.org/p/v8/issues/detail?id=11515

[farwayer]

It was a good decision to use BigNumber in the past to support different environments. But by now most environments support native bigint's (or theoretically could use the ethers@5 or use transpiler). And the performance penalty is very annoying, even if you don't use BigNumber for calculations. For example when you request big arrays of numbers from blockchain ethers parse all of them to BigNumber's.

[ricmoo]

npm install ethers@beta-exports is the latest published version, but the v6 branch I’m leaning towards uses normal build processes, so you can clone the v6-beta-exports branch and just use npm link, which will give you the most up-to-date experience.

[egorFiNE]

@ricmoo could you please quickly summarize what's new in v6? And how far behind it is compared to current 5.x branch?

[sambacha]

It was a good decision to use BigNumber in the past to support different environments. But by now most environments support native bigint's (or theoretically could use the ethers@5 or use transpiler). And the performance penalty is very annoying, even if you don't use BigNumber for calculations. For example when you request big arrays of numbers from blockchain ethers parse all of them to BigNumber's.

I dont think iOS has support for this, which is a problem though can do a ponyfill if this is the case

@ricmoo is the Goja lack of support a blocker?

[ricmoo]

iOS definitely has support for this. They added support in JavaScriptCore in September 2020, which was one reason I’d been holding out and iOS picked it up shortly after.

Goja last I checked was missing the functionality, but had a PR that added it, although the PR needed some work, as I recall.

BigInt cannot be polyfilled, as it is a syntax change, but ethers does not use the incompatible syntax, so things that can work still will. But the number of environments not supporting ES2020 BigInts is minuscule and shrinking.

For people who do need support for old browsers, v5 will continue to available, although only receive security updates.

[ricmoo]

For some info on v6, see this article and this talk at about 3:58:00.