Today in the web3 programming market there are two libraries that are
widely used in JavaScript projects, whether on the frontend or backend: the older Web3.js and the more modern EthersJS. And just as we had a major evolution that broke a lot of things when Web3.js went from version 1 to v2, the same thing happened recently with Ethers changing from v5 to v6.
I write this post the way I would have liked to have found it on the Internet when I needed to update applications from Ethers 5 to Ethers 6 and I hope it helps you too. Some changes are subtle and you may have already resolved them yourself, others are even more gross and mainly affect TypeScript users, who are more sensitive to these type changes. This is not meant to be an extensive post and at the same time it should be updated over time as I learn more about EthersJS v6.
I write this post the way I would have liked to have found it on the Internet when I needed to update applications from Ethers 5 to Ethers 6 and I hope it helps you too. Some changes are subtle and you may have already resolved them yourself, others are even more gross and mainly affect TypeScript users, who are more sensitive to these type changes. This is not meant to be an extensive post and at the same time it should be updated over time as I learn more about EthersJS v6.8.1
Changes from v5 to v6.8.1
Most of the changes are simple, as they correspond to changes in the library's folder structure. In fact, until version 5 I felt the library was somewhat verbose and had excessive use of the utils folder, which is one of the main changes: there is no longer a utils folder. Everything that was in utils is now directly in ethers.x. For example:
//v5
ethers.utils.x
//v6
ethers.x
The same goes for providers. Before we had to specify the path through providers, now it is no longer necessary, we call the providers directly from the ethers object.
Speaking of providers, another change that impacted me was the change of name from Web3Provider to BrowserProvider. I confess that it was an excellent name, as it is used precisely for integration with browser wallets such as MetaMask, but it is still a breaking change that affected my projects here. So if we combine the previous change and this one, we will have:
//before
ethers.providers.Web3Provider
//after
ethers.BrowserProvider
Still within the scope of providers is the change to the provider.getSigner function, used to prepare to sign transactions for the blockchain. Before, the getSigner function was sync, now it is async and returns a promise, so be careful with this as we know it interferes a lot with the execution flow.
//before
const signer = provider.getSigner();
//after
const signer = await provider.getSigner();
Furthermore, in addition to this change to get the signer from the provider, for those using TypeScript we have had some changes to type definitions that affect integration with Smart Contracts. Like this one, from the ABI of a contract that used to be ContractInterface and is now InterfaceAbi.
//before
const contract = new ethers.Contract(ADAPTER_ADDRESS, ABI as ethers.ContractInterface, provider);
//after
const contract = new ethers.Contract(ADAPTER_ADDRESS
And there must certainly be other types that have changed, this is one that I was impacted by in my projects.
One last point that has changed drastically breaking compatibility are static calls. Static calls allow you to send transactions to the blockchain without paying for their costs, but also without being persisted, as if they were “fake” or test calls. See the before and after static calls on Ethers.
//before
const quotedAmountOut = await quoterContract.callStatic.quoteExactInputSingle(params);
//after
const quotedAmountOut = await quoterContract.quoteExactInputSingle.staticCall(params);
In addition to the name itself changing from callStatic to staticCall, the location where it should be called changed, from before the contract function to after it.
That's all for for today, I have only covered those changes which affected my projects you can read the offical guide and release note here.