It's indeed surprising that this compromised npm account didn't lead to more damage. It's a good reminder that you better regularly audit what happens in your ecosystem.

Sometimes, it's indeed better to not pull an extra dependency.

Interesting approach for a project to collect such traps in there dependencies like this.

Definitely this, as projects scale, keeping an eye on dependencies between teams is key to efficient allocation. This will happen by trying to eliminate said dependencies, reallocating between teams.

Not strictly about Rust, still is shows how to approach the conversation about your dependencies. It also gives good ideas on how to try to reduce them.

It's written and illustrated in a C++ context, but the advice is widely applicable. You should know well the libraries you use on your projects.

Dependency resolution is harder than people generally expect. This is a difficult problem and is very sensitive to the context.

Indeed there is a tension between both approaches in package ecosystems.

This is a worthy questioning... We try to reuse, but maybe we do it too much? For sure some ecosystems quickly lead to hundreds of dependencies even for small features.

There is some good advice in this piece. If you want to maintain something for a long time, some aspects need to be thought out from the beginning.

Good tour of all the way dependencies might get compromised in your supply chain. Getting this easy to detect is needed.

Looks like a nice tool to explore dependencies in JS based projects.

Neat little tool. Since I had to do this kind of work a few times, this is indeed a good idea to have a public and maintained script for it.

Definitely this, the software bloat directly impacts the attack surface of what gets shipped. Even though this is far from a panacea in terms of security, it's time for people to critically examine their dependencies also for other reasons.

Clearly I can understand the feeling. That's yet another attempt at a solution for this... it's young, will it get traction? Has the benefit of being kind of simple, too simplistic maybe?

Nice ode to simplifying web projects, to great effects. You can go a long way serving millions of requests if you choose your tools properly.

This is an interesting metaphor. I'll try to keep it in mind.

Mind how you pick your dependencies and how they fare over time. You might need to reevaluate and let go some of them.

Maybe you don't need to pull even more dependencies. Think of the operational costs and the complexity.

Very interesting study on dependencies. This is specific to the Maven ecosystem so too early to generalize the findings to other similar ecosystems. This indicates at least the difficulties of managing dependencies, especially the transitive ones. Also tries to define the "dependencies bloat" problem.