Skip to content
This repository has been archived by the owner on Mar 27, 2019. It is now read-only.

component-size #520

Open
jonathanong opened this issue Apr 5, 2014 · 10 comments
Open

component-size #520

jonathanong opened this issue Apr 5, 2014 · 10 comments

Comments

@jonathanong
Copy link
Contributor

to view the total size of bundles unminified, minified, and minified + gzipped.

there's already https://github.com/ianstormtaylor/component-size, but it shows sizes on a per-file basis. not sure how useful that is since there's minification and gzip you don't take into account. maybe there's a better name for this command.

@jonathanong jonathanong added this to the 1.1.0 milestone Apr 5, 2014
@jb55
Copy link

jb55 commented Apr 5, 2014

It's useful in the sense it gives you a rough idea of relative sizes of packages that your using, if you're ocd about sizes of things. If I want to see the size of the compiled package I can just type <build/build.js gzip -c | wc -c on our dev and release builds.

A shortcut for doing this would be handy, but I imagine would have to make an opinionated choice wrt. minimization. For example we use closure compiler to get much better minimization than what uglify seems to produce.

Just some thoughts...

@jonathanong
Copy link
Contributor Author

My only problem with closure compiler is that it's a pain in the ass to install

I'm thinking of only showing the minimized sized of files.

@jb55
Copy link

jb55 commented Apr 5, 2014

Yeah it's a pain, I made it slightly easier in the sense you can type npm install --save-dev closure-compiler-jar and it'll be in your npm bin path: https://github.com/jb55/node-closure-compiler-jar, still requires java to be installed though.

I think the canonical uglify minifier would make sense for this command though, I would still find it useful as a rough estimate of minimized and gzipped sizes.

@tj
Copy link
Contributor

tj commented Apr 5, 2014

it's super easy to delegate compression/minification outside component, not sure if it's really worth adding a command for when you can use du -h

@jonathanong
Copy link
Contributor Author

but not on a per-component basis, both remote and local. plus, it's easy for you, but not most web developers (i didn't even know if this du -h command!). then people are going to complain about windows support, blah blah blah

@jb55
Copy link

jb55 commented Apr 5, 2014

Could this not just be added as a feature to the existing component-size?

@jonathanong
Copy link
Contributor Author

yeah it could, but i'm thinking about how to improve its usefulness before refactoring it.

@jb55
Copy link

jb55 commented Apr 5, 2014

So yeah it could just have a summary section and then individual component breakdown

@chemzqm
Copy link
Contributor

chemzqm commented Apr 6, 2014

The biggest use case of this command for me is to check how many the bytes would be bring in with one component. Imagine one component takes of 1k of itself but brings in 5k other components, the other one component takes of 2k of itself but no other components, then the other one looks better on the size aspect. But if the 5k taken by other components was reused by other components within the app, the first one component looks better.

If the component-size(or something else) command could show the total minified size of build.js file and minified js size of each component would be good enough for me. And I prefer uglifyjs as it's probably most widely used and easy enough to use and install.

@tj
Copy link
Contributor

tj commented Apr 6, 2014

it could always be part of component-ls, but minus gzipping etc, but then again that's not useful because in reality you're going to gain a ton of from gzip

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants