It’s all too easy to go crazy with the imports and end up with megabytes upon megabytes of JavaScript. It can be a problem as that weight burdens each and every visitor from our site, very possibly delaying or stopping them from doing what they came to do on the site. Bad for them, worse for you.
There is all sorts of ways to keep an eye on it.
You could have a peak on Bundlephobia
Bundlephobia will give you a look at the total size — both zipped and unzipped — along with download times, the number of required sub-dependencies it has, and whether or not it can be tree-shaked (tree-shook? tree-shaken?).
Speaking of “phobia,” there is also Package Phobia that shows the publish and install sizes of individual packages:
You could let VS Code tell you right in the editor
Your import and require statements can lett you know the size of that particular inclusion with the Import Cost extension.
You could look at a data visualization
The Webpack Bundle Analyzer does that.
You could check out the sizes with text output
Cost of modules is another analyzer, but it seems like it only looks at package.json rather than the final bundle, then outputs it as a table:
Webpack Bundle Size Analyzer will show you a nested list of dependency weights, including the size of the bundle code itself, which is interesting:
package size will show you the weight of a comma-separated list of packages
package size has a simple CLI syntax for that:
You have another favorite way to keep your project in check?
I use https://github.com/siddharthkp/bundlesize and continuous integration so build fails if bundle is too much
The best way is to learn native apis and learn how to actually program rather than using libraries for every single thing in your app. ;)
I know you got a little winky face there so this is probably slightly tounge-in-cheek. And I understand the sentiment that there is perthaps a little too much npm-installing our way out of problems to the cost to the user.
Butttt, I’d be careful with that “learn how to actually program” attitude. It comes across as a bit proud and might shame a beginner in a way they really don’t need.
Also – heads up on that SSL cert.
Strange thought, I was always thinking that you should never create your own bicycle when there’s already exists one.
Don’t reinvent bicycle, but choose appropriate travel method based on distance and time available: on foot (native code), bicycle (tiny dependency) or something larger – car, train, plane (big bundle)
Thanks, Chris. Bundle sizes and dependencies are overlooked way too often. Thanks for the reminder. I’ve used the visual bundle analyzer before, but didn’t know of the others. Thanks for sharing!
You can also automate this on pre-commit hook :
(
lint-stagedis used to filter commited files )In
package.json, you configure the pre-commit hook to launchlint-stagged:Then you configure lint-staged ( I use the
.lintstagedrcfile ):And finally, back in
package.json, you can configure your bundle size :This recipe only works if your commiting your
_distfolder.But you should be able to adapt it easily.