Bundlephobia Versions Save

Use npm for resolving package versions

Earlier, we used the Yarn Algolia Index to resolve package strings like react or react@next or [email protected] into a particular package name and version. While this gave us fast access, there were several issues with the index lagging behind the registry.

We now query the npm registry directly using pacote.

Updated similar suggestions

Added categories for excel-parsers, split request libraries into node-http-request and browser-http-request , refreshed others .(https://github.com/pastelsky/bundlephobia/commit/246fdbbda5669483fc16d0273ea82a60ad524237)

Updated blacklist error to be more helpful, and less blameful (2c34d45578362c6aee4d7d34ed43cd2feb457fd8)

🎉 Launching export analysis

Until now, bundlephobia only indicated the complete size of packages its composition. However, as more packages begin to ship with potentially tree shakeable ESM exports, the total size of the packages becomes less important compared to the size of exports actually used in a project.

Now, for any package that exports ESM and declares itself to be side-effect free (partially or completely), bundlephobia will give a best-effort breakup of exports if they were imported into a project individually. eg -

@material/core

True tree-shakeability

What's also interesting to see is that there are some packages export ESM and appear to be either partially or completely side-effect free, but each of their exports weighs as much as the complete package themselves – i.e. they aren't really tree-shakeable. For eg –

[email protected]

@shopify/[email protected]

In the future, the idea is to draw a distinction between packages that are tree shakeable "in real" to the ones that appear to be but might need more work from the package author.

While this is an interesting feature that I'm sure a lot of people were looking forward to, its still early days and bug reports are welcome.

Improved side-effect visibility

• Packages with partial side-effects are now marked so –

Annotated historical graphs

Historical package graphs are now annotated with icons so it becomes easier to correlate big changes in package sizes with addition of ESM exports or marking of side effects.

Example: In the case of date-fns: https://bundlephobia.com/[email protected]

Correct multipliers in similar package suggestions

The size multipliers in these cards are now accurate thanks to – (https://github.com/pastelsky/bundlephobia/commit/bd7fcc55bd512023fbd8a5b17ccdf5d86e08640b)

Error for unsupported packages

Added better errors for packages that are unsupported (now and in the future) – possibly because package size isn't a useful metric for them. For eg–

https://bundlephobia.com/result?p=@types/node

Support for building CLI Tools

Added support for a new class of packages – CLI tools. Such tools usually have an entry point that begins with a #!/usr/bin/node or something similar, and these are stripped out now.

Changes

• 🎊 cost-of-modules is now bundlephobia.com 🎊 (credits to @thekitze for the name)
• Extracted out the bundling logic into a separate reusable package - package-build-stats

Features / Improvements

• Switched from rollup -> webpack. A lot of packages that used to fail to bundle with the pervious engine should work now, thanks to webpack's liberal resolution mechanism.
• Support for reporting sizes of CSS Packages published to NPM. Try animate.css
• Experimental support for SCSS packages. Try bulma
• You can now see historical size trends for a package.

• We now detect presence of module or jsnext:main fields in the package's package.json, and show tree-shaking suggestions.

Improvements

• The bundling is much faster than before. Timeouts should reduce drastically.
• Use uglify-es to minify packages. Works with ES6 packages.
• Errors are less frequent, and when they do occur, they are a little more descriptive.
• Errors don't come up in annoying alerts 😅
• Added error reporting and perf monitoring on the backend.