17 ms·

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

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?

eatonphil 4y ago
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 4y ago
  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.
soco 4y ago
Wow okay I'd be highly interested in such an analyzer as well.
koblas 4y ago
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".
- dosethree 4y ago
  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
- thephyber 4y ago
  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).
pitched 4y ago
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 4y ago
> 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.
woojoo666 4y ago
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_shaking https://developer.mozilla.org/en-US/docs/Glossary/Tree_shaki...
- ratww 4y ago
  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.

eatonphil 4y ago

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 4y ago
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.

soco 4y ago

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

koblas 4y ago

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".

dosethree 4y ago
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
thephyber 4y ago
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).

pitched 4y ago

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 4y ago

> 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.

woojoo666 4y ago

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_shaking https://developer.mozilla.org/en-US/docs/Glossary/Tree_shaki...

ratww 4y ago
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.