Reduce the library size

[imaksp]

Is your feature request related to a problem? Please describe.
It seems with new features size is increasing, Readme file says 322kb uncompressed but it reality it is 748kb. which seems large.
For example in Next.js pages with some ethers import & some other basic ui lib page initial load is going above 240Kb
This image is from bundle analyser & total parsed size with ethers related imports is around 177kb:

& this is from browser if full lib is loaded:

Describe the solution you'd like
May be some another lite version for web3 provider. or more modular structure & better way to import specific module from web3 provider in which tree shaking works in better way in all frameworks like Angular, React Or Next.js (with webpack 5).

[ricmoo]

Better tree shaking is part of v6, but won't be ported back to v5 as it requires a lot of file restructuring. Part of v6 is also shrinking the size again and move more things into ancillary packages.

This may also be related to #2058, which I'm fixing right now. Somehow the other language wordlists are getting bundled into the UMD; it must have broken when modifying the rollup configs at some point.

Each package is also available separately, so if only a small subsection of functionality is needed, the specific packages can be imported, which will also assist tree shaking and the bundler.

[imaksp]

Sounds good, but I have imported only web3 provider (using import { providers, utils, Contract } from 'ethers' can't import just web3provider or just 3-4 util functions) & it is importing 177kb of data so tree shaking is working, but I still feel size is large, hope it will be reduced in v6.

[wmitsuda]

@aksdevac I think you can import individual providers/functions by importing from "@ethersproject/" namespace.

It takes some work to discover exactly which module corresponds to the function you want, but it works for me.

By just doing that, the create-react-app build was able to treeshake my project.

Not sure what the recommended practice should be because it is not mentioned on the docs, but I guess importing from "ethers" is helpful for starting learning about ethers, for "serious" use you should do more granular imports from "@ethersproject/".

[ricmoo]

@wmitsuda Yes, that is the ideal way for v5 if you only need a handful of functions. I don't have a super easy way to identify which package to pull from (I should add that to the docs, and do have a task for it, I just haven't had time), but one easy method is to look up the function in the docs and click the "source" link, which will take you to that functions source code on GitHub, from which the path will look like packages/abi/src.ts/index.ts; the abi indicates it is in the @ethersproject/abi package.

[imaksp]

@wmitsuda Hi, thanks for your suggestion but I have already tried to import only web3provider from @ethersproject without any success, it simply does not work if I import it from @ethersporject, not tried much for utils function yet.

[wmitsuda]

@aksdevac I use JsonRpcProvider and it apparently works fine. Web3Provider inherits JsonRpcProvider, however doesn't it have a dependency on web3.js?

Feel free to correct me if I'm wrong, it is been a long time since I used web3.js, but doesn't web3.js itself has a dependency back on ethers? So, maybe the circular dependency from web3.js to ethers is blocking the tree shaking?

[ricmoo]

No part of ethers depends on Web3.js. The Web3Provider knows how to interact with a Web3.js provider, as well as EIP-1193 providers. But there is no dependency.

Web3.js depends on does depend on ether though, for the ABI coder.

The main thing the breaks tree-shaking is the way TypeScript handles static class method, which I’ve redesigned a bit in v6. Different tree shakers behave better than others too, which is why v6 makes extensive use of splitting functionality across separate files which helps tree shakers too.

[ricmoo]

(random note; there are only 5-6 dependencies for ethers, which are all small with the exception of the secp256k1 library; v6 uses the noble library which is substantially smaller. If you pull in any part of ethers in which uses elliptic maths, that is where most of your package size is likely coming from)

[ricmoo]

The v6 branch is well adapted to tree-shaking, so should result in as small a footprint as possible, based on what components you are using.

When min-zipped, the library is currently 140kb, if entirely included (for example, when using the /dist files).

Closing this now, but please feel free to continue discussions.

Thanks! :)