←back to thread

NPM debug and chalk packages compromised

(www.aikido.dev)
1369 points universesquid | 1 comments | 08 Sep 25 15:37 UTC | HN request time: 0.253s | 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 #
nine_k ◴[08 Sep 25 16:07 UTC] No.45170008[source]▶
Having a module for every little trivial thing allows you to only bring these modules inside the JS bundle you serve to your client. If there's a problem in one trivial-thing function, other unrelated trivial things can still be used, because they are not bundled in the same package.

A comprehensive library might offer a more neat DX, but you'd have to ship library code you don't use. (Yes, tree-shaking exists, but still is tricky and not widespread.)

replies(3): >>45170169 #>>45171158 #>>45171236 #
palmfacehn ◴[08 Sep 25 17:31 UTC] No.45171158[source]▶
Things like this are good illustrations as to why many feel that the entire JS ecosystem is broken. Even if you have a standard lib included in a language, you wouldn't expect a bigger binary because of the standard lib. The JS solution is often more duct tape on top of a bad design. In this case tree shaking, which may or may not work as intended.
replies(2): >>45172102 #>>45174402 #
1. nine_k ◴[08 Sep 25 18:40 UTC] No.45172102[source]▶
This is because you cannot easily remove problematic stuff from the browser. It's actively being used by someone, so the vendors keep it, so it continues to be used. The process takes decades, literally.

On the server side, of course, you can do whatever you like, see Node / Deno / Bun. But the code bundle size plays a minor role there.