←back to thread

NPM debug and chalk packages compromised

(www.aikido.dev)
1369 points universesquid | 4 comments | 08 Sep 25 15:37 UTC | HN request time: 0.635s | source
Show context
stathibus ◴[08 Sep 25 16:00 UTC] No.45169926[source]▶
As an outsider to the npm ecosystem, reading this list of packages is astonishing. Why do js people import someone else's npm module for every little trivial thing?
replies(11): >>45169990 #>>45169999 #>>45170008 #>>45170014 #>>45170015 #>>45170016 #>>45170038 #>>45170063 #>>45170879 #>>45170926 #>>45170953 #
rglover ◴[08 Sep 25 16:05 UTC] No.45169990[source]▶
You typically don't. But a lot of packages that you do install depend on smaller stuff like this under the hood (not necessarily good and obviously better handled with bespoke code in the package, but is is what it is).
replies(1): >>45170047 #
1. grishka ◴[08 Sep 25 16:10 UTC] No.45170047[source]▶
Then the question becomes, why do developers of larger libraries import someone else's module for every little trivial thing?
replies(2): >>45170186 #>>45173011 #
2. rglover ◴[08 Sep 25 16:19 UTC] No.45170186[source]▶
Because they don't have the slightest clue what they're doing.
replies(1): >>45170847 #
3. jbreckmckye ◴[08 Sep 25 17:08 UTC] No.45170847[source]▶
It's not that either.

There are a handful of important packages that are controlled by people who have consulting / commercial interests in OSS activity. These people have an incentive to inflate download numbers.

There could be a collective push to move off these deps, but it takes effort and nobody has a strong incentive to be the first

4. SAI_Peregrinus ◴[08 Sep 25 19:47 UTC] No.45173011[source]▶
Sometimes it's not someone else's module, it's their own. They break up the big library into reusable components, and publish them all separately. Essentially taking DRY to an extreme: don't have private functions, make all your implementation details part of the public API & reuse them across projects.