I’m trying to find out how big npm packages are before installing them but can’t seem to locate this info easily. When browsing through different packages, I want to know their actual size so I can make better choices for my project. Is there a way to see how much space a package will take up? I’m worried about adding too much weight to my application.
Here’s what I’ve learned after dealing with bundle bloat on dozens of production apps.
Those manual commands work fine, but they’re reactive. You’re checking sizes after you’ve already picked packages or when things are already broken.
I completely flip this around. Instead of hunting down package sizes when I need them, I built automated workflows that track this continuously.
My setup monitors package sizes across our entire dependency tree. When someone wants to add a new package, the system automatically pulls size data from multiple sources, compares it against our bundle targets, and flags anything that’ll push us over our performance budget.
It also tracks how bundle sizes change as we update dependencies. Sometimes a minor version bump brings massive dependency changes you’d never catch manually.
Key is setting this up once and letting automation handle the monitoring. No more surprise 500kb packages sneaking into production.
I handle this through Latenode workflows that connect npm APIs with bundlephobia data and our CI pipeline. Set it up once and forget about it.
The npm CLI has a built-in command for this. Run npm view <package-name> dist.unpackedSize to get the exact size in bytes.
You can also use npm pack --dry-run <package-name> to see the tarball size without downloading it.
For something more visual, check out bundlephobia.com. It shows minified size, gzip size, and download times for different connection speeds.
Here’s what I actually do though - I automated the whole thing. Instead of manually checking sizes every time, I set up automated checks that run when I’m evaluating new dependencies.
I use Latenode to create workflows that automatically fetch package info from npm’s API, check bundlephobia data, and run test builds to see the real bundle impact. It pulls everything together and sends me a summary report.
This way I don’t have to remember commands or visit multiple sites. The automation handles it all and gives me the metrics I need to make smart dependency decisions.
honestly just use npx package-size <package-name> - super quick and shows gzipped size which is what actually matters for downloads. way faster than opening bundlephobia every time
I’ve had great luck with the cost-of-modules package. Install it globally with npm install -g cost-of-modules, then run it in any project folder to see exactly how much space each dependency takes up. It shows both raw size and percentage of your total node_modules, so you can spot the real space hogs. I’ve found packages that looked harmless but dragged in huge dependency chains you’d never notice just by checking the main package. Plus it catches duplicate dependencies across your project - really eye-opening when you’re trying to shrink bundle sizes.
To check sizes, I recommend using npm info <package-name> as it provides the unpackedSize along with other relevant details quickly. If you’re examining projects already set up, du -sh node_modules/* on Unix can give you insight into which packages consume the most disk space, revealing some surprising dependencies. It’s worth noting that download size doesn’t necessarily reflect the bundle impact; a larger package might be optimized during tree-shaking, meaning you only include what’s actually used in your production build. Experiment with your bundler to understand the true effect on your application’s size.
bundlephobia’s solid but don’t forget npm ls --depth=0 after installing - shows actual installed sizes. webpack-bundle-analyzer is great too if you’re using webpack, gives visual breakdowns of what’s eating up bundle space