Measure packages sizes effectively

Measuring the package-size and it's impact for our project bundle is very important.
Bundlephobia is a popular tool used to analyze the size of packages before adding them to a project. However, it has limitations in terms of accuracy and functionality.
This article explores alternative tools that can provide more comprehensive insights into bundle size analysis.

Bundlephobia is not dynamic

Bundlephobia outputs the entire size of the package. It is not taking into account of what user is actually importing from it.
It gives a good idea of what to expect from the scanned package:

• whether it is tree-shakeable or not
• whether it has a side-effects
• how many dependencies does this package use

Bundlephobia only approach may lead to overestimates

Since it outputs the entire package size, the devs may reject packages based on hasty flat size check.

First alternative: pkg-size

Tool made by Hiroki author of many great packages like: tsx get-tsconfig It is using WebContainers to install packages in the browser.

• you can install multiple packages at once
• shows all of the dependencies of the package
• shows what module system the library exposes (cjs/esm)
• shows if given packages ship the types
• allow to download the build for further analysis

I have checked the date-fns format util - it correctly shows its real weight: 5.7kB (gzipped)

The only downside I found is fact, that rarely it falls into some infinite loop, however refreshing the site always resolves the issue.

General info about the package

Actual bundle size

Second alternative: bundlejs

Tool made by Okiki Ojo
It also installs the dependencies in the browser. It is not as detailed as the pkg-size.

• you can install multiple packages at once
• sharing feature through the url date-fns analysis share link
• shows the real package size based on the import
• shows the build outcome
• allow to tweak the bundler to your needs

I have checked the date-fns format util - it correctly shows it's real weight: 5.7kB (gzipped)

Sometimes it cannot fetch the dependency (in my case was the rare case scenario). Related Github issue

Example with date-fns analysis

The date-fns is well-known modular and modern date utility library. It is fully tree-shakeable and fits great for our example.
For our experiment, we will assume that our application needs just the formatting date functionality.
Additionally, the format function will be imported from the root-entry point import { format } from 'date-fns'
We know from the Bundlephobia that package:

• is tree-shakeable
• has 0 dependencies
• has no side-effects

The entire package (minified + gzipped) weight around 17.5kB

Both pkg-size and bundlejs outputs correct bundle size impact (5.7kB gzipped) when pulling just format from date-fns.
Moreover, both solutions add more insights and result-sharing capabilities for your Team.

Summary

Bundlephobia is still a great tool for the initial research, it load really fast, tells most important info about package health right away (tree-shakeable, side-effect, dependencies count).
The final decision should be made based on either: pkg-size or bundlejs
These tools allow for dynamic analysis based on actual imports, providing a more accurate picture of the real cost of adding a package to your project.
Pkg-size and Bundlejs can help in collaborative environments due to their sharing features. Since it is highly unlikely from my experience to leverage 100% of the functionality of the library.
I will still use Bundlephobia as a preliminary tool to check the initial package's health. Then I would use the pkg-size with its deep analysis to make the final decision.