Migrate away from web3-provider-engine

[pi0neerpat]

According to the maintainers, it looks like web3-provider-enginer is no longer actively maintained / no longer recommended (see readme)

I discovered this issue when trying tackling duplicate dependencies. They are using old versions of ethereumjs-util and eth-sig-util read more

I will open a PR in their repo to update those dependencies. In the meantime I thought I'd start the discussion for migrating away.

[pedrouid]

I've been wanting to do this for the longest time but previous attempts were unsuccessful to achieve compatibility with web3.js because it's huge legacy debt and resistance from Dapp developers to upgrade to latest

The ecosystem has evolved a little bit more now and web3.js is getting less buggy plus Dapp developers seem to finally moving forward. Maybe it's worth trying again...

[dmihal]

If you guys are interested in building a replacement for web3-provider-engine, I'd love to help out.

This library is an important tool for building providers, but it's very out-of-date and buggy. I use it in burner-core, and I'd love to swap it out for a nice, modern replacement.

[fubhy]

Also subscribing to this. As it stands, due to the absurd dependency chain pulled in by web3-provider-engine and other dependencies of this provider it currently clocks in at

@walletconnect/web3-provider.js      1729 KB    513.33 KB  403.79 KB

(first is unzipped, second is gzipped, third is brotli).

This is twice(!) the size of the whole React library.

This makes it somewhat painful to include walletconnect into a web dapp. Furthermore, a wide range of these dependencies blindly pull in node ecosystem dependencies (non-browser deps) and seem to have no idea how to properly declare dependencies in package.json (peer / dev vs. plain deps) and the main vs. browser, etc. - They are also not ESM compatible and thus fail with modern dev tools like Snowpack / esbuilder.

I think the Ethereum community as a whole has a long way to go to properly unspaghetti this mess of incorrectly built low-level node tools and packages.

For this package, I don't think it's possible to solve this problem as it stands. Therefore I think it would be a good first step to simply decouple it from web3 and web3-provider-engine entirely (without replacement) and only offer these as opt-in addons on top.

If you want help with this I am happy to assist.

[pedrouid]

We all definitely want that... next weekend I can try to explore this again and try to use or port eth-provider

I would love @floating to comment on this 🙌

[fubhy]

I've actually built a slim ethers.js provider in the meantime now that only uses the low level sdk of walletconnect instead. If you want I can share that here and submit a pull request for your monorepo?

As far as the web3 connectors are concerned: I personally think that composing providers together (web3-provider-engine, etc.) belongs in user space. So even ignoring the fact that that package is a huge mess in terms of dependencies I don't think it makes sense to include it here anyways. We are not using web3 anymore so this is not a huge priority for me. I just noticed the dependency graph blow up when I updated the packages in our legacy app. I have to admit though that I have not spent a lot of time with walletconnect yet and don't know the reasons for choosing this approach (it might very well be for a good reason (!)). So apologies if my judgement is simply based on a lack of understanding.

[floating]

Hey @pedrouid! What is needed to be able to use eth-provider directly as a dependency? I'd be happy to revisit adding a WalletConnect connection module to eth-provider to handle any custom logic you need. Do you know where we left off with that in floating/eth-provider#29?

[bpierre]

Just to add to the discussion: web3-provider-engine imports native Node modules (util and events, here for example), which means that bundlers using it or WalletConnect need to provide Node polyfills.

eth-provider imports one native Node module at the moment, but this PR fixes it: floating/eth-provider#38 merged 🙂

Edit: eth-provider is also much smaller: 7.1kb vs. 82.4kb.

[fubhy]

Hey @pedrouid! Are there any news around this? I think the we are seeing an exodus of web3.js and web3-provider-engine all across the space with more and more projects moving to ethers. We've managed to eliminate every single dependency rabbit hole in our app except the one caused by the deps that WalletConnect pulls in. We would love to get that one resolved too. Is there anything that we can help with to get this resolved?

[pi0neerpat]

I'll pledge 300 DAI right now to a bounty. Anyone else here care to join me?

[ShravanSunder]

Hey @pedrouid! Are there any news around this? I think the we are seeing an exodus of web3.js and web3-provider-engine all across the space with more and more projects moving to ethers. We've managed to eliminate every single dependency rabbit hole in our app except the one caused by the deps that WalletConnect pulls in. We would love to get that one resolved too. Is there anything that we can help with to get this resolved?

could you share your fork ?

[ChenKuanSun]

Any update?
Bundle size too large.
Have someone working on it?

[finessevanes]

@ChenKuanSun are you still experiencing an issue?