This. But the problem seems to go way deeper than npm or whatever package manager is used. I mean, why is anyone consuming a package like colors or tinycolors? Do projects really need to drag in a random dependency to handle these usecases?

replies(2): >>45260930 #>>45261400 #

diggan ◴[16 Sep 25 11:47 UTC] No.45260930[source]▶

>>45260898 #

So rather than focusing on how Microsoft/npm et al can prevent similar situations in the future, you chose to think about what relevance/importance each individual package has?

There will always be packages that for some people are "but why?" but for others are "thank god I don't have to deal with that myself". Sure, colors and whatnot are tiny packages we probably could do without, but what are you really suggesting here? Someone sits and reviews every published package and rejects it if the package doesn't fit your ideal?

replies(2): >>45261253 #>>45262805 #

1. freakynit ◴[16 Sep 25 12:20 UTC] No.45261253{3}[source]▶

>>45260930 #

You're partly right.

But the issue isn't just about the “thank god I don't have to deal with that myself” perspective. It's more about asking: do you actually need a dependency, or do you simply want it?

A lot of developers, especially newer ones, tend to blur that distinction. The result is an inflated dependency tree that unnecessarily increases the attack surface for malware.

The "ship fast at all costs" mindset that dominates many startups only makes this worse, since it encourages pulling in packages without much thought to long-term risk.

↑

Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised