4 ms·
I think it only counts direct dependencies.
by d-k-bo 2y ago
I think it only counts direct dependencies.
- falcor84 2y agoSo that means that the way to game this would be to create a wrapper project (e.g. called "external_deps") for all of my dependencies, and then have my actual project depend on that one. So I'm externalizing all of my tech debt onto external_deps and as long as I never make a new release of that, my main project will always be 0 libyears old.
- riffraff 2y agoEven if you could, why would you? It'd be the same to, say, fork a projectX to myprojectX and say you're at the latest version. You are the one that has an advantage to know you're behind, not someone else.
- PokestarFan 2y agoLook up Goodhart's Law.
- alanbernstein 2y agoWouldn't it be easier to "game" the tool by just not using it?
- gwbas1c 2y ago> So that means that the way to game this would be to create a wrapper project (e.g. called "external_deps") for all of my dependencies, and then have my actual project depend on that one No, you can't resort to chicanery to manipulate your metric. In this case, the libraries you want to use become transitive dependencies, but if your code uses those transitive dependencies, then your project still depends on them.
- IanCal 2y agoThen the rails example on the main page is wrong.
- WorldMaker 2y agoPeople already do that with vendorizing, too. It was noted the other week on HN of someone "collateralizing" their tech debt by vendorizing a dependency to remove CVE/deprecation/obsolescence warnings for a Rust dependency with no update path: https://news.ycombinator.com/item?id=39827645 https://news.ycombinator.com/item?id=39827645 A metric like this can't keep you honest (just about no matter how you design it, people will find loopholes), but it can help honest people document their needs.