Investigate tree-shakeability of our umbrella fuels package

[nedsalk]

From this comment:

We could try variations with different usages simulating real-world case scenarios to see how tree-shakable things are.
One variation is the quickstart/scaffold PR that @Dhaiwat10 started (#1408)
Another is the wallet itself. (cc @FuelLabs/frontend)
There might be others as well.

For example, our demo-react-vite app has this import statement: import { BaseAssetId, encrypt, decrypt } from "fuels";, but the impact on bundle size is +187kB, which is too much for such simple imports.

[nedsalk]

Currently as it is, our packages satisfy the main requirement of tree-shakeability, which is that we are generating ESM javascript. However, our packages suffer from three problems that cause suboptimal tree-shakeability:

1. Having a dependency on a CommonJS package that's not tree-shakeable (e.g. semver, elliptic, bn.js)
2. Depending on packages that are not optimally tree-shakeable or that export more than we need due to the way they're internally structured, whereas we can implement the functionality ourselves (e.g. ethers, graphql-request) ,
3. Writing code that's not properly tree-shakeable (using large classes instead of functions, using enums where discriminated unions of strings can be used, static fields like FuelError.CODES don't tree-shake properly...)

The biggest bang for the buck would be solving the problems in the order above.
For a reference on the least tree-shakeable parts of the fuels package, you can take a look at #1461. In an ideal world, all of the @fuels-ts packages in that list would be zero, which would mean that they're fully tree-shakeable.

Other things worthy of mentioning:

• We don't need to build cjs and iife modules because we're targeting node v18 and above, which has support for esm, and iife modules were traditionally built to not pollute the global namespace but esm modules have their own scope so that case is obsoleted.
• Setting esModuleInterop to false in tsConfig.base.json might be helpful when getting rid of CommonJS dependencies. For example, it causes our semver imports to break.
• We should maybe change the tsconfig.base.json fields module and moduleResolution to ES2022 and Bundler, respectively. This is to be explicit that we're aiming for ESM and not be bitten by some misconfiguration down the line.
• Setting package.json's type property to module will tell node that the package should be built as ESM. If not specified, it'll build it like CommonJS. Still, it seems like our tsup settings override this in the format property because we are building ESM code.

[arboleya]

Cross-referencing with:

• Feedback - WebAuthn App QA Results #1545

I experienced large bundle sized when building with fuels-ts, I'd consider having a CI check to ensure the way we have the sdk published can be properly tree shaken. This could be due to my bundler, but we should check to ensure it's not.

[arboleya]

Thanks for your investigations so far. 🙏

Before deciding on a path forward, we should try assembling a table with:

1. List of problematic dependencies
   • Do we have alternatives to them?
2. List of problematic packages
   • How much KB would we save by re-working each?

The goal is to have a quick glance at the trade-off between effort x benefits before prioritizing anything.

Note

1. iife might be useful for in-browser playground (or via CDN)
2. We can't change things like moduleResolution yet because of the Wallet (using an old bundler)
3. Changing the project to module could also break apps already using it (such as the Wallet)

[nedsalk]

1. List of problematic dependencies - Do we have alternatives to them?

Listing the dependencies that I remember off the top of my head (not a final list):

• semver - We are only using a subset of it that can be easily implemented internally. I easily did it with GitHub Copilot, lol. feat: replaced semver dependency with custom implementation #1594
• ethers - We only use like four of their exports and it seems like we can just copy-paste the bare minimum that we need.
• elliptic - We are only interested in secp256k1 from this package, which we could replace with the audited @noble/secp256k1. feat: replace elliptic with @noble/curves #1601
• bn.js - This is already a topic in Migrate bn.js to bignumber #1542.
• graphql-request - it can be replaced with a simple fetch. feat: remove graphql-request dependency #1597

List of problematic packages - How much KB would we save by re-working each?

A lot of the issues related to tree-shakeability will be solved by fixing problematic dependencies. The packages that would most benefit from removing those dependencies are listed in #1461. We shouldn't spend time analyzing them until we solve the dependencies problem first because we won't know the state of our code properly until then. It's arduous to go through the generated code, and trying to analyze our own faults while lots of non-treeshakeable dependency code surrounds it just adds to the difficulty.

[arboleya]

These two issues seem a bit overlapping.

Can we merge them and have a final report to look at?

[arboleya]

Also, it'd be good to have a clearer table with everything.

Problematic dependencies

Package	KBs (before)	KBs (after)	Alternative	Notes
abc	N	N	xyz	Lorem ipsum et dolor..

Problematic packages

Package	KBs (before)	KBs (after)	What needs to be done?
provider	N	N	Lorem ipsum et dolor..

[nedsalk]

Problematic dependencies

Package	kBs	Issue or PR	Notes
elliptic	48.16	#1601	DONE
bn.js	22.09	#1542
ethers	12.85		copy-paste necessary code or use smaller libs?
graphql-request	10.74	#1597
semver	9.02	#1594	DONE
tai64	3.78		custom implementation?
bech32	1.08		https://github.com/paulmillr/scure-base
graphql-tag	0.81	#1597	handled in same PR as graphql-request
ramda	0.62		This is small already
uuid	0.3	#1608

An interesting thing to note is that some PRs are reducing the bundle size more than the reported effect of the corresponding library on the bundle size (e.g. #1594 reduces it by 19.86 kB but the table above reports its size to be 9.02 kB). I don't know the reason behind this and I don't think it's worth investigating. The main benefit of #1461 was reaped: we got a list of the most impactful libraries that we need to investigate/replace. If the removal of a library reduces the size even more - great!

[nedsalk]

These two tables summarize the clearly actionable parts of #1461 and, in accordance with this comment, I'll close #1461.
Once the content of these tables is resolved completely/partially, we can revisit the process done in #1461 and update these tables accordingly.

[arboleya]

Good stuff! Thanks for the comprehensible list.

I'd discard everything but the first 5x items in the table — the increase in complexity doesn't seem worth the optimization.

Even these can be tricky:

1. elliptic
2. bn.js
3. ethers
4. graphql-request
5. semver

I wonder if we should internalize all five.

[nedsalk]

I'm okay with internalizing everything except the elliptic functionality, because that's related to cryptography and the library that's replacing it in #1601 is audited. However, there might be some place for improvement here as well. I initially tried using this library of the same author that's only for secp256k1, but I had some issues with CommonJS compatibility around templates/nextjs as that library is ESM-only. I just checked and using that library would save us an additional 5-6 kB - if we managed to solve the CJS issue. I don't know what's causing it.

[arboleya]

Swapping for other libraries is preferable to internalizing, that's for sure!

Whatever strategy fixes the problem with less work should be the default.

But we can still ignore everything <4kb, as the gain would be marginal.

[danielbate]

Tai64 is probably being removed in #1627. I am looking at internalising as much as ethers as possible (#1401, #1640 and WIP) but will report the overly complex areas.