Show Bundlephobia or similar browser size stats on package pages

[markerikson]

The NPM package pages currently show the unzipped size of a package on disk. This is useful if you're targeting Node or want to get a sense of how big your node_modules will be in general, but it doesn't relate at all to how much size a library might add to a browser bundle.

Bundlephobia ( https://bundlephobia.com/ ) is an excellent tool that tries to estimate the size of packages when used in a browser. I would really like to see the Bundlephobia stats integrated into NPM package pages.

[MylesBorins]

Very interesting! There have been a number of great suggestions about surfacing more details about packages on the website, seems like it might be reasonable to think about this holistically and perhaps do a larger redesign.

https://github.com/pastelsky/bundlephobia

Turns out the bundlephobia is on Github with a permissive license.

[ljharb]

I would very strongly prefer not to include this information; bundlephobia is a very rough estimate that often gives an inflated size - bundle sizes can't effectively be estimated without the full context of the app, including deduped dependencies and various optimizations that the user's specific bundler choice might apply.

[markerikson]

I would argue that a rough size (with caveats, if necessary) is still a useful metric to have, and far more useful for front-end devs than the unzipped size on disk.

For me, it's one of the primary attributes I consider whenever I evaluate a package.

[ljharb]

What I have seen is that this information causes FUD, and causes people to avoid a dependency that they would otherwise use because the perceived bundle size estimate is "too large".

[bcoe]

One of the ways package maintainers are helping to bridge the gap between CJS and ESM libraries is to use rollup to create both an ESM and CJS entry point for their library. In my opinion, supporting both export types is a great way to ensure that ESM doesn't represent a split in the ecosystem... It also makes it possible to use more modules in the browser, without a build step.

Targeting both CJS and ESM significantly increases library size, even though I'd argue the practice is great for the frontend community.

I don't love the current metric displayed on package pages "Unpacked Size":

• because it doesn't take nuances (like a library having multiple exports) into account.
• because the gzipped size/dependency count is ultimately what's going to matter much more, for install time.

---

I don't know if Bundlephobia is the answer, but I'd love to see a metric that better than "Unpacked Size", one which:

• doesn't penalize library authors for having CJS/ESM exports.
• takes into account the dependency graph.

[MylesBorins]

hey @markerikson it looks like @bnb opened a discussion for a slightly higher level idea for "npm scores".

Would you be open to considering this specific discussion "answered" and move the discussion to https://github.com/npm/feedback/discussions/66 where we can discuss the variety of ways we can "score" an npm package

[markerikson]

Mmm... not entirely? I would see "scores" as a separate thing, that might take bundle size into account as an input metric.

Like, a package could have an "87% score", but for this particular question I just want to know it adds "27K min / 12.3K min+gz" as a starting idea of how much it's going to add to my bundle.

[MylesBorins]

Ok, no problem. We'll keep this one open for it's own discussion. I'll likely be bundling a few of these together as part of a broader discussion on what we display for repos on the website to discuss with the team.

[markerikson]

bump I'd still love to see some kind of "estimated FE bundle size" as a visible metric on package pages if possible.