web3.js: library is not tree-shakeable

[johnrees]

Problem

@solana/web3.js is not tree-shakeable.

I've created an example repo with a short README demonstrating this issue. To summarise it very briefly...

Currently bundlers such as webpack and rollup cannot extract specific sections of code from web3.js, including the .esm.js build. This means that any project that using it will either be including the entire library or at least a significant portion of it.

Some of the issues I think this raises -

• increased bundle size means there's up to approximately 0.5MB minified JS overhead for end users to download and process
• dependencies and/or polyfills (e.g. window.crypto) which can be tricky to configure with tools like React Native, Vite/WMR, are always loaded, even if they're not required by the code that was imported by the developer
• the unused code adds more noise for auditors who try to identify 'rugs' when examining compiled bundle code

Proposed Solution

Perhaps the esm build could be produced by typescript's tsc and then be verified to be tree-shakeable with something like agadoo as an extra CI step before publishing. I did make a quick attempt at this but it looks like it's going to need more work than just building with tsc.

The recommended steps by Rich Harris (rollup creator) in the Agadoo README are -

If tree-shaking still fails, it's because Rollup thinks that there are side-effects somewhere in your code. Follow these guidelines:

• Avoid transpilers like Babel and Bublé (and if you're using TypeScript, target a modern version of JavaScript)
• Export plain functions
• Don't create instances of things on initial evaluation — instantiate lazily, when the functions you export are called

[steveluscher]

I started work on this, this week.

[steveluscher]

OK, but don't get too excited. :)

[steveluscher]

Alright, I did a ton of hacking and slashing. You can take a look at a draft of this work in solana-labs/solana#25014. But probably don't. But if you do, I welcome your feedback.

There are two main obstacles that an optimizing compiler faces when trying to tree-shake our JavaScript SDK.

1. We perform a lot of work in our module factories – baking layouts before they're used – and an optimizing compiler can't know for sure that work is side-effect free. The target amount of work to do in module factories is zero.
2. For all the work we do in module factories that a compiler sees as potentially side-effectful, the libraries that we pull in through npm do even more.

I'm going to have a think about what I've done so far, and come back to it next week with fresh eyes. I think it's close.

[steveluscher]

Hello frens. I have not forgotten about this. Now that my head is slightly above water, having shipped the first version of the mobile phone JavaScript SDK, I can turn some attention back to stuff like this.

[petrucioinica99]

any updates on this? i am trying to bundle a package that has solana web3 as a dependency with rollup and i keep jumping from one error to another.

[steveluscher]

The tack I'm taking at the moment is to rewrite web3.js entirely, with tree-shakeability as a core tenet. You can follow along as I build it up, piece by piece, https://github.com/solana-labs/solana-web3.js/tree/master/packages/library.

[github-actions]

Because there has been no activity on this issue for 7 days since it was closed, it has been automatically locked. Please open a new issue if it requires a follow up.