@silvermoon82@tech.lgbt I have... strong feelings about this :) The main problem is that there's just currently no (credible) automated way to reliably assess the risk involved in dependencies, and it's unlikely that one can ever exist because of the nature of the problem. The best you can do there is pretty much "spotting known problems to look at", and that scope will be very limited.

*Ideally*, you would manually review every dependency. This is actually viable in practice in JS, *if* (and only if) you strictly stick to single-responsibility dependencies that have a very well-defined scope, but even then it's still a very time-consuming process, and there should really be good tooling for doing this collaboratively across the community, to spread the work.

But... there isn't. :|

I explicitly don't trust for-profit corporations to build such tooling, because "for-profit" and "public commons" don't go together and it'll invariably end in doing free labour for a commercial party rather than a genuine community project. But there's also very little ongoing work in this area in general.

The 'immediate' advice I generally give for JS nowadays is to stick strictly with single-responsibility dependencies regardless of how high it makes the dependency count go up. Because that way many of your dependencies will simply not *need* maintenance, and swapping out a dependency in the worst case is super cheap. It's also much easier to audit them manually because all code is 'local' instead of coupled to other parts of the stack.

(I wrote a bit more about the counterintuitive nature of JS deps over on the birdsite a while ago, if you're interested: https://twitter.com/joepie91/status/1065193459349446656)