Migrate to ethers@6

[Siegrift]

Most of our repos use ethers@5, while some already use viem (e.g. dao dashboard). The ethers@5 is deprecated and many other supporting software (e.g. typechain) recommends viem. Hardhat now also supports viem.

Ideally we should agree on the strategy:

• what library do we prefer for new projects
• how and when to migrate old projects

The commons library should migrate to this.

[Siegrift]

We are using viem for @api3/chains (little usage) and our internal OEV service (more advanced usage). It's fair to say we are not satisfied with it. Similar thing can be said to ethers v6 which migration guide is incomplete and there are multiple things which are not mentioned and the migrator needs to figure them out (agreement of both @andreogle who attempted the migration for Airnode and @Siegrift who migrated Airseeker-v2).

Note, that it would be ideal if the package did export also v5 bindings for legacy projects, but at the same time not include both versions of the package (because bundle size matters for FE). This, along with #4 might justify making commons a monorepo.

[andreogle]

I still like Viem APIs significantly more than Ethers APIs. The main problem for me is that Viem still feels slightly immature. It's missing several important things that are already present in Ethers (e.g. fetching multiple log topics in one getLogs() call). Viem typings and (imo) the documentation is also much better, but the rough edges are still a problem. Maybe this will change in 6+ months

[Siegrift]

In the 3 months, I don't think much has improved with viem, although ethers@6 has its quirks as well (e.g. not being able to call only "eth_gasPrice" or the issue with creating the RPC provider).

That said, what API is used under the hood does not matter much in commons, because we only use it for common utilities such as deriving wallets and encoding/decoding things. The consumers of the package can use whatever they want.

Let's migrate to ethers@6

[jxom]

What needs improving in Viem? You'll likely see major performance & stability improvements by integrating – and we aim to keep issue count near zero. We maintain Viem full-time, so happy to guide on some things.

fetching multiple log topics in one getLogs() call

this is possible: https://viem.sh/docs/actions/public/getLogs#multiple-events

The main problem for me is that Viem still feels slightly immature

curious on what you think makes Viem immature! It is being used in production by many large web3 orgs now (Stripe, Shopify, ENS, Coinbase, Optimism, Uniswap, Sushiswap, Pancakeswap, etc) – consuming via apps, server-side, and tooling. 😊

[Siegrift]

Hi, and thanks for reaching out :). First, I have to admin, our attitude wasn't the best, because we complained - but didn't create issues on your repo - sorry for that. Anyway:

this is possible: https://viem.sh/docs/actions/public/getLogs#multiple-events

The problem we have, is that we need to fetch multiple events from the same contract, but also use an indexed argument. The JSON-RPC supports that but viem does not. We worked around that by calling eth_getLogs ourselves.

The main problem for me is that Viem still feels slightly immature

This is likely subjective and comes from our history with ethers. It's not perfect, but we've learnt to work with its quirks over time (and also with v6) while viem is a bit new for us. The resources on stack-overflow or even tools like chat GPT were less helpful.

The last problem we've encountered was that viem error message stringify to a huge string. We deployed our service and our error logs exploded. As far as I recall, there was often calldata of the transaction (and maybe ABI of the contract) present. We've fixed it by "sanitizing" the error this way:

export const sanitizeError = (viemError: Error) => {
  // Even the error.message is huge for certain errors, so we use shortMessage (and hope for the best).
  const error = new Error(viemError instanceof BaseError ? viemError.shortMessage : viemError.message);
  error.name = viemError.name!;
  // In practice, we rely on the developer supplied message anyway.
  delete error.stack;

  return error;
};