3 ms·

This post describes several potential "problems" with NPM packages, but not _why_ they are problems in the first place. The author doesn't say why they consider

This post describes several potential "problems" with NPM packages, but not _why_ they are problems in the first place. The author doesn't say why they consider circular dependencies bad, or why dependency depth should be low, or even why their categorization of packages is the way it is (and leaves out large categories like tools and CLIs). I don't think that a high number of dependencies is necessarily bad, or a low number is necessarily good. A dependency can often have factored out common functionality into a shared and higher-quality project than the same bespoke implementation re-implemented in several packages. I think we'd need some more complicated metrics, possibly looking a bit like a web of trust analysis, to determine quality and health of packages. Depending on a well-maintained, popular, and highly-trusted package like lodash or express shouldn't be an indicator of low-quality or low-trust. We also have deprecation and security notices provided by NPM. So I'd be much more interested in questions like "how many unique, low-trust packages are included in this package graph?" or "how out of date are the dependencies?" to try to estimate package health. From there I'd be curious to know how healthy the ecosystem is in aggregate, weighted for usage.

notJim 6y ago
This whole comment is spot on. To take the lodash example, you can easily hand-roll a bunch of methods to do things like group-by, index-by, etc. If you're not careful though, it's very easy to introduce a prototype pollution vulnerability in this, as lodash the themselves have done. The difference between your code and lodash is that this vulnerability is much more likely to be caught in lodash. And when lodash fixes the vulnerability, all you have to do is update the package, rather than writing a bunch of code (hopefully correctly this time). One of the real issues with the JS ecosystem is that we don't have a way of capturing that information about degree of trust. People tend to use number of downloads as a metric, which is better than nothing I guess. But what if there a way to capture whether the library has a bug bounty, or information about governance practices?
diiq 6y ago
You're absolutely right that I am doing a certain amount of "searching under the spotlight", here. The metrics I measured were the ones I had the information and computational power to measure. You want to see how many "low trust" packages there are -- me too! But what does that mean? How do I find them? That is, in essence, the problem I'm describing. If I could solve it, believe me, the post would have been about that, instead :) I do propose, towards the end, a network-of-trust score -- but I don't think that's something a single person can implement today; it requires social work. (I am sorry you feel I didn't explain why deep dependency trees are a problem -- my premise is based on the desire to assess packages for if they are appropriate to include in a project, and I do mention why deep and broad trees make that harder. Circular dependencies I specifically say aren't a problem; they're just disconcerting to me.)
- chrisweekly 6y ago
  +1 for "searching under the spotlight", such a great (and IMHO underused) turn of phrase

notJim 6y ago

This whole comment is spot on. To take the lodash example, you can easily hand-roll a bunch of methods to do things like group-by, index-by, etc. If you're not careful though, it's very easy to introduce a prototype pollution vulnerability in this, as lodash the themselves have done. The difference between your code and lodash is that this vulnerability is much more likely to be caught in lodash. And when lodash fixes the vulnerability, all you have to do is update the package, rather than writing a bunch of code (hopefully correctly this time). One of the real issues with the JS ecosystem is that we don't have a way of capturing that information about degree of trust. People tend to use number of downloads as a metric, which is better than nothing I guess. But what if there a way to capture whether the library has a bug bounty, or information about governance practices?

diiq 6y ago

You're absolutely right that I am doing a certain amount of "searching under the spotlight", here. The metrics I measured were the ones I had the information and computational power to measure. You want to see how many "low trust" packages there are -- me too! But what does that mean? How do I find them? That is, in essence, the problem I'm describing. If I could solve it, believe me, the post would have been about that, instead :) I do propose, towards the end, a network-of-trust score -- but I don't think that's something a single person can implement today; it requires social work. (I am sorry you feel I didn't explain why deep dependency trees are a problem -- my premise is based on the desire to assess packages for if they are appropriate to include in a project, and I do mention why deep and broad trees make that harder. Circular dependencies I specifically say aren't a problem; they're just disconcerting to me.)

chrisweekly 6y ago
+1 for "searching under the spotlight", such a great (and IMHO underused) turn of phrase