Make v6 better, what do I miss every time when using v6 or upgrading a project from v5

[valamidev]

Hi everyone,

I do have to say that once I switched to Ethers(v5) from Web3JS it was like a never go back decision, I have been used heavily v5 Ethers writing/deploying contracts(unit-test), back-end, front-end, indexing blockchain and using a wide-range of plugins to make my life easier.

With Ethers v6 I have very mixed feeling, obliviously the new EVM features are required, however upgrading a v5 project to v6 is very time consuming and inconvenient.

Issues what I facing regular basis:

• Google still prefer to guide to v5 documentation there is no button to switch v6 or any highlight that you are reading something possibly obsolete thing.
• Handy features from Utils class like parsing values like 1 gwei, 1 ether
• Lack of useful documentation of v6, most of the documentation is just an auto-generated schema.
• Missing import and examples in the documentation, these were not in the v5 neither, but in v6 many method has much more common naming which confuse auto-import every time.
• Forced BigInt, it is good to decrease the package size, but almost every use case the output have to be formated to BigNumber to continue work with them.

[nomo-app]

I agree with you that the v5 -> v6 migration is still a big mess.
Native ES2020 bigint's were an important upgrade, so I think it was the right decision to enforce native bigint's instead of having a chaos of native bigint's plus legacy bigint mixed.
However, I hope that the path from v6 to v7 will be much smoother.

[ricmoo]

That is the plan. V6 to v7 should be painless-ish. :)

The v5 to v6 was a big change because it moved from supporting exclusively ES3 targets to using modern JavaScript features, which opened up a lot of new features, like BigInt and Proxy.

Basically the hacky things that had been around for a while to support modern JS using legacy JS could go away.

The build system also got much cleaner and vanilla, which will have the additional benefit of maintaining a v6 and v7 in tandem will be much easier. :)

I’m also open to any suggestions. And will have a beta of v7 out soon and would love feedback.

The main reason for a major bump this time is just to address Account Abstraction, so that an Abstract Account can be used basically the same as any other Signer.

I’m also fixing up a few internal things that cause issues with certain platforms; I’m considering moving to using WeakMaps directly rather than private fields, which seem to bork a lot of Babel things.

Again, suggestions welcome. :)

[nomo-app]

Thank you very much!
Especially Account Abstraction is a hugely important feature in my opinion, I am looking forward for it to come to v7!

[arshcodemod]

Hi Richard,

This is Arsh from Codemod.com, I went through the ethers.js upgrade guide and I went through community .We're developing an open-source platform for automated code migrations and have already provided free, fully open-source codemods for frameworks like React, Remix, MSW, and React Native.
We are also in the official upgrade guide of React aswell.

I created some github issues for an upgrade from ethers.js 5->6 as per information available.
codemod-com/codemod#797
codemod-com/codemod#794

Codemod : https://go.codemod.com/vdXS7aq

You can also make this github request and our AI will help build the codemod in one click.

This will save a lot of engineering time building these codemods and will provide Ether v5-> v6 builders with a seamless experience.

If this interests you, could we schedule a brief (15-30 minute) intro/demo/Q&A session?

Thanks
Arsh Goyal

[SvenMeyer]

@ricmoo Most annoying when doing a v5 to v6 migration is that getting the address of a user/signer now is an async call which requires me to change hundreds of instances of user.address to await user.getAddress() .. or am I missing something ?

https://docs.ethers.org/v6/api/address/#Addressable

[ricmoo]

The problem, even in v5, is that address wasn’t always an address. It could have been an ens name. So, if you don’t care about that, you can always assert contract.target is a hexstring and just go from there and there isn’t much difference from v5.

If you use await ethers.resolveAddress(contract.target, provider) though, you will always get an address.

Part of the changes in v6 is that target can also be an Addressable, like a contract or signer, so for example you can do new Contract(otherContract, abi, signer) or for an abstract account new Contract(signer, abi, signer) to connect to the Abstract Account with a Contract interface.

This is the main reason behind the change.

[ricmoo]

Oh, keep in mind in ethers you can use an Addressable anywhere you can use an address. So if you are using await obj.getAddress() to pass into a contract method, or things like provider.getBalance, you can just pass the object in directly, like provider.getBalance(signer). It will do the getAddress for you.

[f1lander]

@ricmoo I have a question, I'm using in my project ethers.js alongside with @ethersproject/providers now I'm facing a problem that I can get ens names on holesky, seems I need to upgrade ethers.js to v6 but @ethersproject/providers since not updated to use the new provider, my question, should get rid off @ethersproject/providers and just use ethers.js v6? the other thing is the web3-react/core library that's actually expect a WEb3Provider type and not he new one on v6 BrowserProvider.

[ricmoo]

Yes, v5 and v6 providers aren’t interchangeable. Are you currently using the Eip1137Bridge to get the Web3Provider? Or does it work with a Web3Provider directly? If so, does it work with a BrowserProvider if you force it using a cast? Can you pass me a link to the docs too? I can possibly reach out to them and help them migrate. :)

[sambacha]

Hey @ricmoo some of the changes seem fairly straightforward, why not utilize codemods? For example, Nextjs uses this in upgrades, see https://nextjs.org/docs/app/building-your-application/upgrading/codemods

[jcb31416]

Yes, good point @valamidev. Hmm.. I have an idea for that. Maybe already exists, or have some flaws that I ignore, but that's why I wanted to put into discussion. Since libraries change so much along with the versions (not only ethers), why not to create a collective interface for them. So they need to be changed only once, for the whole community. Let me do a representative example,

we'll use these two examples of ethers migration v5 to v6:

// example_1
// v5:
provider = new ethers.providers.Web3Provider(window.ethereum)
// v6:
provider = new ethers.BrowserProvider(window.ethereum)

// example_2
// v5
provider = new StaticJsonRpcProvider(url, network);
// v6: 
provider = new JsonRpcProvider(url, network, {
  staticNetwork: network
});

we'd use the library interface for that, updated in v6 without worrying if I only know about v5

import {I_ethers_v5v6} from 'libinterface';

const Ieth = I_ethers_v5v6; //I_ethers_v5v6 would work for example like function(string_method, [array_args])
const provider_1 = Ieth('ethers.providers.Web3Provider', [window.ethereum] );
const provider_2 = Ieth('StaticJsonRpcProvider', [url, network] );

Let's say now appears v7 and again it's a bit nightmare. All we should do is changing at the beggining I_ethers_v5v6 to I_ethers_v5v7, and if certain function don't appear, we contribute to adding it in the official repo of I_ethers_v5v7. What do you think..?

[tenthirtyone]

Yeah, just piling on, because today is another wasted day moving to v6 on an corner piece of code that works exactly how we want but some library now requires v6 and this is another waste of developer hours. 5 worked great, 6 didn't, 7 is fool me twice. I would rather stay downrevved on 5 until I cannot, then I will invest the effort into another library before trying "fool me twice." Ethers is in that spot web3 was when everyone was desperate for ethers.

A sad thing to see and have to say.

[AlexSerbinov]

II have been updating our projects from v5 to v6 for almost a week now. And it's very painful.
My PM is telling me to revert everything to V5, because I have no succuss :(
The worst part is that I can't find the changelog, and it's very difficult to understand what went wrong.

[ricmoo]

I am always available on discord (when not asleep) to assist, but what issues are you finding the most problematic? Please let me know things that are missing or could be better explained in the migration documentation...

[HugaidaS]

Many popular DeFi libraries like Uniswap or AAVE are using v5 and they just do not support v6 and it seems like they are not going to. It is a big pain to make the system work now. The only solution that actually worked is to install both v5 and v6 in one project. Because v5 and v6 interfaces are just not compatible anymore, at least some backward compatibility would be nice to have. For now, it is indeed a mess. Especially with these BigInt and BigNumber...

[ricmoo]

I would also love a list of projects that are still using v5 and possibly a contact to get in touch with to help migrate from v5 to v6.

Including both v5 and v6 can have its own set of consequences, and I'd love to help any project migrate from v5 (which is over 2 years old) and find out why they haven't migrated yet.