Giter VIP home page Giter VIP logo

weigh's Introduction

Weigh Build Status

A command line tool to check the bundle size of one or more browser compatible npm modules

Install

npm i -g weigh

Usage

Usage: weigh [<args>] <module1> [<module2>] [<moduleN>...]

Supports any module identifier on the format [@scope/]package[@version][/module.js]

  Options:
    --help, -h          Show this usage information

    --bundler -b        Which bundler to use. Can be one of
                          • `browserify` (default)
                          • `concat`

    --minifier, -m      Specify which JavaScript minifier to use. Can be either
                          • `uglify` for UglifyJS (default)
                          • `closure` for Closure Compiler
                          • `babili` for Babili
                          • `butternut` for Butternut

    --verbose, -v       Do a little more logging along the way

    --gzip-level, -g    Gzip compression level

    --no-minify         Don't minify

    --no-gzip           Don't gzip

    --uncompressed, -u  Shorthand for --no-minify --no-gzip

    --env               The value of process.env.NODE_ENV inside the bundle.
                        Defaults to `production`

    --output -o         Output final result to stdout. You may also want to
                        disable gzipping with --no-gzip
                        If browserify used for bundling, `fullpaths: true`
                        will be passed as an option to browserify, so that
                        e.g. `discify` can be used for further bundle
                        inspection

    --version           Output current version

    Examples:
      weigh lodash
      weigh lodash/map
      weigh lodash@latest/map
      weigh @myorg/mypkg
      weigh @myorg/mypkg@latest
      weigh @myorg/mypkg/foo/bar.js
      weigh @myorg/mypkg@latest/foo/bar.js
      weigh @myorg/[email protected]/foo/bar.js
      weigh ./path/to/foo/bar.js
      weigh /absolute/path/to/foo/bar.js
      weigh . (resolved module from cwd)

Example:

$ weigh lodash

Outputs:

Downloading lodash, this may take a little while…
Downloaded 1 package(s)

Weighing lodash…

Approximate weight of lodash:
  Uncompressed: ~412.11 kB
  Minified (uglify): 51.61 kB
  Minified and gzipped (level: default): ~18.82 kB

Note: By default weigh uses browserify under the hood to bundle the module, and adds envify as a global transform, with NODE_ENV set to production

This means weigh will report the size of a production build for modules that does code branching based on process.env.NODE_ENV

For example compare:

$ weigh redux
Approximate weight of redux:
  Uncompressed: 28.5 kB
  Minified (uglify): 7.82 kB
  Minified and gzipped (level: default): 2.73 kB

...with:

$ weigh redux --development
Approximate weight of redux:
  Uncompressed: 28.5 kB
  Minified (uglify): 9.23 kB
  Minified and gzipped (level: default): 3.36 kB

Inspecting the final result

You can output the compiled bundle for further inspection using --output (or -o) command line option. Note: By default this will output the gzipped result, so you'd probably want to use the --no-gzip flag

This will just pipe generated the bundle to stdout, which also enables further bundle size breakdown e.g. using hughsk/disc.

For example:

weigh --output rxjs --no-gzip | discify --open

Some more examples of supported module formats

  • weigh lodash
  • weigh lodash/collection/map
  • weigh lodash@latest/collection/map
  • weigh @myorg/mypkg
  • weigh @myorg/mypkg@latest
  • weigh @myorg/mypkg/foo/bar.js
  • weigh @myorg/mypkg@latest/foo/bar.js
  • weigh @myorg/[email protected]/foo/bar.js
  • weigh ./path/to/foo/bar.js
  • weigh /absolute/path/to/foo/bar.js
  • weigh . (module in cwd)

License

MIT

weigh's People

Contributors

bjoerge avatar craigbilner avatar jdeal avatar rexxars avatar typicode avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar

weigh's Issues

Production flag

According to the readme, you can pass NODE_ENV=production, to get pass this onto envify et al.

With the latest version of npm, this seems to fail - weigh crashes:

espenh@ambrose ~/webdev/weigh $ NODE_ENV=production weigh ascii-doge
⠏ Downloading ascii-doge, this may take a little while…/home/espenh/webdev/weigh/lib/installPackages.js:72
  return Object.keys(dependencies)
                ^

TypeError: Cannot convert undefined or null to object
    at packagesToArray (/home/espenh/webdev/weigh/lib/installPackages.js:72:17)
    at /home/espenh/webdev/weigh/lib/installPackages.js:64:16
    at ChildProcess.exithandler (child_process.js:198:7)
    at emitTwo (events.js:106:13)
    at ChildProcess.emit (events.js:191:7)
    at maybeClose (internal/child_process.js:852:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:215:5)

After some digging, it seems npm ls changes behavior when NODE_ENV is set to production - but I can't find any documentation stating why, or how. This might be related: npm/npm#12579

Regardless of this, I'm wondering if perhaps it would be a better option to pass a --production flag, or similar? In fact, I'd actually prefer if weigh always gave me the size of production bundles, since that is what I'm usually basing my decisions on. Thoughts?

Feature request: take already installed packages into account

I'm not sure if this is outside the scope of the project or not, but a nifty feature would be if running weigh from a directory that contains a package.json file would take the dependencies declared there into account.

For example, if I am in a directory that contains a package.json that looks like this:

{
  "name": "example",
  "dependencies": {
    "react": "^16.2.0",
    "react-dom": "^16.2.0"
  }
}

And I run weigh react-wysiwyg, the output could be:

$ weigh react-wysiwyg

Approximate weight of react-wysiwyg, excluding dependencies already installed in this project:
  Uncompressed: 679 kB
  Minified (uglify): 166 kB
  Minified and gzipped (level: default): 45 kB

This could alternatively be turned on via an option instead.

My main motivation for this would be determining how much extra filesize would a new dependency add to my project, excluding sub-dependencies that I already bundle.

Read source string from stdin

e.g. cat index.js | weigh.

With #6 in place this also makes it trivial to weigh a pre-built file from a remote address:

curl https://cdnjs.cloudflare.com/ajax/libs/jquery/2.2.1/jquery.js | weigh

Support weighing without bundling

It would be nice to be able to weigh a file without bundling it. Useful if you have a pre-bundled file:
weigh ./react-with-addons.js

Could be supported with a --no-bundle flag that skips browserify entirely

Should support package relative modules

Currently $ weigh error/typed fails because it tries to install the package error/typed. Instead it should install error, and then browserify error/typed.

Weighing any local path yields identical filesizes

Hey @bjoerge, thanks for a great module :-)

Maybe I'm doing something wrong, cause I can't get it to work correctly with local modules.

Weighing a local module like so:

$ weigh ./most-w3msg
Approximate weight of ./most-w3msg:
  Uncompressed: 454 B
  Minified (uglify): 448 B
  Minified and gzipped (level: default): 289 B

And weighing the same module via npm:

$ weigh most-w3msg
Approximate weight of most-w3msg:
  Uncompressed: 6.62 kB
  Minified (uglify): 1.64 kB
  Minified and gzipped (level: default): 681 B

Weighing any other local directory also yields 289 B. Am I doing something wrong?

This is Node v6.3.0 and npm v3.10.6.

Warns with empty peer list on extraneous package

npm ls errors on extraneous packages and triggers the peer missing message.

It seems to be the usage of --prefix that does it (reproduced by hand), but hopefully that doesn't mean prefix changes npm's installed tree structure-- well, I did a quick search and found npm/npm#20148, so maybe it does. I don't know what to do, otherwise I would try and go make a PR.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.