Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show total number of dependencies #32

Open
mclark-newvistas opened this issue Jun 17, 2019 · 0 comments
Open

Show total number of dependencies #32

mclark-newvistas opened this issue Jun 17, 2019 · 0 comments

Comments

@mclark-newvistas
Copy link

Similar to #20 - when searching for an npm package, one of my top considerations is how many total other packages will be installed along with it. Essentially - I want to install as little code as possible to minimize bug surface area, and have as few non-essential features as possible (optional features are fine, but npm has no way to indicate optional dependencies). Less code means less to audit and inspect when something goes wrong, and minimizes the changes of a crippling bug in code I care about. It also means fewer packages to audit to decide if they are worth adding as dependencies.

As an illustrative example - say I'd like to use a web request library. This library also has a feature to act as a CLI client - like curl. It parses arguments using an argument parser, which itself wishes to colorize it's own error output to terminals, as it manages errors internally. This then relies on a complete dictionary of color mappings, only 2 of which are ever used. All I want and need is an HTTP request library which gives me back a string instead of a chunked stream and follows redirects, but I'm getting bundled a bunch of features I neither want nor need. While bugs in code that never executes won't hit me - I can't know which code executes without a manual review of the code, which takes up far too much developer time to justify vs picking a library with fewer features and without dependencies.

Showing (and possibly sorting, once supported) by total dependencies (recursive, non-devDependencies) would save me substantial time when making a new library decision, as I have to click on each, check dependencies, then for each of those, check dependencies, etc. For each dependency I have to consider where and how it's used and if I care about the features it provides, etc.

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

No branches or pull requests

2 participants