You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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, butnpm
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.
The text was updated successfully, but these errors were encountered: