Replies: 3 comments 5 replies
-
|
I agree with you that the v5 -> v6 migration is still a big mess. |
Beta Was this translation helpful? Give feedback.
-
|
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. :) |
Beta Was this translation helpful? Give feedback.
-
|
Thank you very much! |
Beta Was this translation helpful? Give feedback.
-
|
@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 |
Beta Was this translation helpful? Give feedback.
-
|
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 This is the main reason behind the change. |
Beta Was this translation helpful? Give feedback.
-
|
Oh, keep in mind in ethers you can use an Addressable anywhere you can use an address. So if you are using |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
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. :) |
Beta Was this translation helpful? Give feedback.
-
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:
1 gwei,1 etherBeta Was this translation helpful? Give feedback.
All reactions