[wcedmisten]

It would be nice if there were a way to quantify the value of your dependencies.

If you have a dependency with 1,000 LoC and your application is utilizing 800 of them, that seems like a good reason to use the dependency.

You're (hopefully) getting unit tests, documentation, and public exposure of the code (bugfix opportunities) for "free"

If you have a dependency with 1,000,000 LoC and you only need 1,000, that indicates the dependency isn't a good fit for your project.

This is only a heuristic, but are there any tools that examine metrics like that?

[koblas]

This makes me think about the quality of the dependancy. If you could evaluate packages for things like:

* Test coverage -- that's not a metric on NPM * Code practices -- what's the review history * Issue velocity -- hard metric, lots of features vs fixes * Hygiene -- for many languages is typing enforced / validated

I'm sure there are lots of other metrics, but so many times you're just evaluating two packages based on "star count" or "npm installs".

[thephyber]

Agree that this is the largest issue with code quality.

Knowing when and which package to import, given the incomplete data points we have now.

Stars/downloads are a popularity contest. At some point, people mostly vote for the candidate who is most likely to win (causing this to be self-reinforcing) , not the one with the best ideas.

The stability+sustainability of the development team, the signals of consistent quality (eg. Code linting, code quality audits, bug bounty program participation, public security audits, good design documents, automation of builds, testing methodology and test coverage).

[dosethree]

Factors for me are: 1. how hard will it be to remove/replace this package in the future? how much coupling does it introduce? 2. how likely will it be that this is deprecated/unmaintained in the future

[eatonphil]

You're also exposing yourself to potentially needless breaking changes and many libraries that aren't well tested or don't have static types. Or growing in size because of optional dependencies but build tools and languages without builtin support for keeping unneeded optional dependencies out of the imported code.

[nerdponx]

This seems like an ecosystem cultural problem. In Python, I can't think of a single time I have experienced an "uncontrolled" breaking change (i.e. without an announcement and long deprecation period) in any important library that wasn't in some kind of alpha state, and I've never needed to rely on an alpha-quality library for anything in production.

[woojoo666]

It's not a way of detecting it but what about dead code elimination, like Javascript's tree shaking [1]?

Of course if your dependency is a spaghetti, tree shaking wouldn't do much but neither would an analysis tool. Poorly architected code with no separation of concerns, will cause every entrypoint to touch every LOC

[1]: https://developer.mozilla.org/en-US/docs/Glossary/Tree_shaki...

[ratww]

Tree shaking could help, but an issue is that in bigger libraries there will often be shared abstractions that wouldn't be present in a more targeted implementation. Even libraries that are well architected and have good separation of concerns.

Unless the library is a collection of independent functions like lodash, there will be some interdependency (in the name of code quality!).

Of course, (ab)using "more targeted implementations" can cause other problems, like using too many libraries for example. No silver bullet.

[pitched]

How much time would it take to replace those thousand lines? A week (assuming well tested and production-ready is a requirement)? If keeping it costs a couple hours of debugging once a month, the return on that week would take years to turn positive.

[jjav]

> This is only a heuristic, but are there any tools that examine metrics like that?

Use a code coverage tool to see what call paths are getting exercised.

[soco]

Wow okay I'd be highly interested in such an analyzer as well.