privatenumber/pkg-size.dev is tracked by TopGit as a backend project, with 914 stars on GitHub. π¦π Find the true size of an npm package
Snapshot summary built from the project's own GitHub metadata β there's no written TopGit review yet. The page will update automatically when a full review is published.
WHY NO REVIEW YET
TopGit writes full reviews for the most-starred, most-requested repositories. This page is a snapshot until then β see the READ ME tab for the original README in full.
This repository serves as a place to file bug reports and feature requests for pkg-size.dev.
Currently, the project is in early stages of development and closed-source. But it may be open-sourced here in the future.
About
The goal of pkg-size.dev is to make it easier for curious developers like you to explore the npm ecosystem. It allows you to browse projects in your dependency tree, discover new packages, and learn about their creators. Ultimately, it aims to foster a greater appreciation for the npm ecosystem.
For package users, pkg-size helps you:
Uncover hidden dependencies and understand why they're installed.
Maintain control over your node_modules by being mindful of what you're installing and its impact on size.
Optimize web app performance by choosing smaller and optimized ESM packages.
Compare and evaluate similar packages to identify the best fit for your specific needs.
Discover the authors, developlment, and funding behind packages.
For package authors, pkg-size helps you:
Evaluate installation bottlenecks to improve speed. Particularly important for CLI tools loaded with npx.
Ensure seamless downloads even in unideal conditions such as slow internet or low storage.
Minimize dependencies to reduce risks like breaking changes or malicious code.
FAQ
Why care about package sizes?
Because they take up a lot of space on your disk. Even small packages can add up quickly. Try calculating the total size of all the node_modules on your disk.
When analyzing them, you may find some packages include unnecessary code and impact your app's performance.
Protip: If you're interested in minimizing how much space node_modules consumes, check out pnpm. Not only do you regain a ton of disk space, it's also a huge DX improvement!
What was this project inspired by?
This project draws inspiration from two amazing services: Package Phobia and Bundlephobia.
pkg-size aims to improve upon these services in the following ways:
Consolidation: pkg-size combines insights from both services on one platform for a more cohesive analysis.
Dependency insights: pkg-size shows what was installed and why, providing valuable information for understanding the result, and helps with identifying large or duplicate dependencies. It also helps devs discover new packages.
Latest data: pkg-size does a fresh npm install each time, fetching the latest data and even reflecting updates in nested dependencies. In contrast, Package Phobia and Bundlephobia cache their results. For example, when calculating the installation size of express, if a nested dependency had a minor release that increased its size by 100MB, neither service would reflect the change in size because there's no version bump in express.
Peer Dependencies: pkg-size allows for the inclusion of peer dependencies in the size calculation, recognizing that they're essential for running packages.
How does the website work?
This website operates entirely in your browser, from installing npm packages to bundling them!
At its core, the tool is built on WebContainersβa technology by StackBlitz that allows Node.js to run in-browserβ, to run npm and install packages directly in your browser. It then analyzes the node_modules directory to gain insights into the installed packages and their stats. esbuild WASM is used to bundle the package.
The website is static (doesn't require a backend) and hosted on Vercel.
Is it possible to show the import cost (tree shaking gains) of each named export?
In most cases, no.
In simple cases where each export is independent, you can easily see the cost of importing each one. For example:
export const A = () => <10kb string>;
export const B = () => <20kb string>;
export const C = () => <30kb string>;
However, in real-life examples, it's not always straightforward.
For instance, in this slightly complex example:
const data = [
<10kb string>,
<20kb string>,
];
export const A = () => data[0];
export const B = () => data[1];
export const C = () => <30kb string>;
Both A and B depend on data, so either importing A or B alone will pull in the 30kb data. To tree shake it, you need to remove both A and B. That's to say, neither A or B have individual import costs.
Determining whether an export has a clear import cost becomes more complex as the number of exports and code size increases.
TopGit's metadata for privatenumber/pkg-size.dev does not record a license. Most public repositories on GitHub ARE open source, but the exact terms vary β verify by opening the LICENSE file directly.
What else is in the Backend space?
privatenumber/pkg-size.dev is tracked by TopGit under the Backend category, alongside 5 GitHub-tagged topics. Trending and Topics pages list peer repositories of comparable stars and language.
What is privatenumber/pkg-size.dev?
privatenumber/pkg-size.dev (privatenumber/pkg-size.dev) is a multi-language project on GitHub. From the project's own README: π¦π Find the true size of an npm package
Where can I see privatenumber/pkg-size.dev in action?
The project maintains a homepage at https://pkg-size.dev. The README tab on this page also usually contains screenshots and a quickstart.
Where do I read more about privatenumber/pkg-size.dev?
This TopGit page is a snapshot β the READ ME tab shows the project's own README content (links stripped, images preserved). The GitHub repository at github.com/privatenumber/pkg-size.dev is the definitive source.
Why is privatenumber/pkg-size.dev categorized under Backend?
TopGit places privatenumber/pkg-size.dev in the Backend category based on its GitHub topics and description (tagged: "analyzer", "node", "npm"). Categories are assigned from real repository metadata, not editorial guesswork.
