Cleaning up of the dependency tree

[nivida]

Description

Use dependencies if possible directly or replace them with better alternatives.

[MicahZoltu]

Useful tool for helping with this process: http://npm.anvaka.com/#/view/2d/web3/2.0.0-alpha

[rumkin]

I've reviewed the project's dependencies and here it is the most terrible one:

1. Gulp as dependency of WebSocket. +17 Mb
2. Ethers as dependency o web3-eth-abi +3,5 Mb
3. Oboe with its' 7 Mb test JSON in web3-providers-ipc +7 Mb.

[MicahZoltu]

I think there are two separate issues. One is how big the web3.js bundle is after tree shaking (I'm assuming that web3 build does tree shaking). I have no idea why gulp is a dependency of websocket, but it should go away when tree shaking happens. Ethers on the other hand probably largely sticks around if it is actually being used. It does feel odd that ethers is a dependency of web3 though, since they are competitors.

The other issue is npm install time and install UX for users of the library, and to a more minor extent, developers of web3 itself. Besides just having to download 500MB (yes, I have seen libraries with hundreds of MB of transitive dependencies) when you npm install, the more dependencies there are the more likely it is that one of them is going to have a bad day either because the user's Dev environment can't handle it (node-gyp) or because some deep transitive dependency made a breaking change or pulled their library off of NPM.

Lastly, the more dependencies there are the more likely a known security vulnerability will be included in the tree and sometimes it takes a long time to propagate fixes up the chain.

[rumkin]

@MicahZoltu For the first issue: the size remain constant in case of server installation (for example in a container). NPM has no tree-shaking capabilities except of the installation without dev dependencies using --only=prod flag, but all of these packages are not one of them.

[MicahZoltu]

Presumably web3.js is built from all of that and packaged into a bundle for distribution and usage in browsers, and I would assume that that bundling process does tree shaking.

For the server-side use case, that is the second/third problem I mentioned where time-to-fetch all dependencies is high and risk of known vulnerability is high.

[cgewecke]

Closing in favor of

• Unpin every dependency #3186
• A possible strategy to reduce bundle sizes #3267