Discussion: Package size of 672.5 kB Minified

[mvdschee]

While implementing UAL-anchor for a project (Nuxt3), I found that adding this package doubles the size of our codebase. As its core functionality, it would be included in the main module. There is a possibility we can work around this, but in my view, the package is too big.

I used BundlePhobia to inspect the bundle size: https://bundlephobia.com/package/ual-anchor@1.1.2

What do you guys think?

[aaroncox]

The ual-anchor package itself is only a fraction of that size and I believe this reporting tool is displaying all the adjacent dependencies as part of its overall size, which is sort of misrepresenting the impact this one plugin for UAL has.

Most of what's displayed there (eosjs, asmcrypto, etc) is already included when UAL is added, so the packager in the end should be preventing that from being duplicated and not actually increasing it by that much.

I'll check on our end to see if there's any optimizations we can make, both to make tools like this report more accurately and to see if there's any bloat we can cut out.

[mvdschee]

Yes, I saw that the code you guys wrote is the smallest, but the dependencies are pretty big.

To give a fair comparison, I did a build in the project itself:

• Basic build without UAL (nuxt3, vue3, eosjs, ....) Σ Total size: 1.69 MB (403 kB gzip)

• Build with UAL (ual-plainjs-renderer) Σ Total size: 1.79 MB (433 kB gzip)

• Build with UAL & Anchor (ual-anchor) Σ Total size: 3.29 MB (748 kB gzip)

The builder that Nuxt3 uses in the background is Vite (Rollup.js) which is quite good at three shaking and de-duplicating.

[jnordberg]

What's the extra dependencies pulled in to that ual-anchor build? anchor-link is designed to have overlap with eosjs for all big dependencies so I wonder if there is something preventing deduplication here

[mvdschee]

I checked the dependencies and found you have five core packages. The last two are already included, so we can ignore those. Looking at the unpacked size gives an idea of where the majority of the package size is.

• @greymass/eosio (there are 2 versions being used 0.5.3 and 0.4.9) Unpacked Size: 845 kB
• anchor-link Unpacked Size 2.83 MB
• anchor-link-browser-transport Unpacked Size 832 kB
• eosjs (already included) Unpacked Size 419 kB
• universal-authenticator-library (and this one too) Unpacked Size 23.7 kB

If we look closer to anchor-link we get the following packages.

anchor-link@^3.3.4:
  version "3.3.4"
  resolved ....
  integrity ....
  dependencies:
    "@greymass/eosio" "^0.4.0"
    asmcrypto.js "^2.3.2"
    eosio-signing-request "^2.2.0"
    fetch-ponyfill "^7.1.0"
    isomorphic-ws "^4.0.1"
    pako "^2.0.3"
    tslib "^2.1.0"
    uuid "^8.3.2"
    ws "^7.4.3"

And we can again take a look at what takes up the most space:

• @greymass/eosio (We can ignore this one) Unpacked Size: 845 kB
• asmcrypto.js (This one looks like the biggest package) Unpacked Size 4.09 MB
• eosio-signing-request Unpacked Size 269 kB
• fetch-ponyfill Unpacked Size 29.7 kB
• isomorphic-ws Unpacked Size 3.89 kB
• pako (is this a dev dependency?) Unpacked Size 1.58 MB
• tslib (is this a dev dependency?) Unpacked Size 39.1 kB
• uuid Unpacked Size 116 kB
• ws Unpacked Size 127 kB

Side note: For nuxt3 (server-side rendering), not all code is compiled to what is used, and packages are imported in the code as import ... from .... So overall package size ends up playing a role in serving faster to end-users.

In my opinion, That is not your responsibility to look after, just letting you know that's something that's happening.

[jnordberg]

Hmm, thanks for looking into that but how are you getting the bundle sizes? Because the complete bundle for anchor-link with all dependencies included is 471kb uncompressed (146kb gzipped). (can be found on unpkg https://unpkg.com/anchor-link@3.3.4/lib/anchor-link.bundle.js)

pako, elliptic, bn.js and hash.js are shared with eosjs so shouldn't affect your bundle size if you are already using that.

asmcrypto.js is really big but shouldn't contribute much to the bundle size because we are only using a small part and it is tree-shakeable.

[mvdschee]

He @jnordberg That's not bundle sizes, what is happening with nuxt3 is that it doesn't bundle everything, the server understands how to handle imports so it will include the the package itself and use it without bundling. I'm not sure the whole reason why they would do that but I will look in to the bundled files and figure out what it includes and what not.

[mvdschee]

I made an build and run a server and it looks like the user would receive: Bundled package (ual-plainjs-renderer, ual-anchor and a bit of template for the layout) Transferred 151,72 KB (588,22 KB size) This is just one of the modules that Nuxt will load on the client, so the total transfer is higher.

to take a look at the bundle yourself: https://gist.github.com/mvdschee/1e4466822efd5bc1751429aa41970499

[mvdschee]

I would recommend:

• license information in a LICENSE file.
• Extract css to a styling file.

[aaroncox]

Responding to just let you know that despite a lack of time to do this, it's still something on our radar. Our team is tied up in writing research papers at the moment and most non-critical work is on hold until that's complete in a month or so.

We think we identified a few things in the dependency tree that can be optimized to reduce the duplication and size.

[mvdschee]

@aaroncox Thank you for the update :) I can understand and I will see the updates once they are there 👍