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

I mostly agree. But NPM is special, in that the exposure is so much higher. The hypothetical python+htmx web app might have 10s of dependencies (including transitive) whereas your typical Javascript/React will have 1000s. All an attacker needs to do is find one of many packages like TinyColor or Leftpad or whatever and now loads of projects are compromised.

Stuff like Babel, React, Svelte, Axios, Redux, Jest… should be self contained and not depend on anything other than being a peer dependency. They are core technological choices that happens early in the project and is hard or impossible to replace afterwards.

Well, your typical Rust project has over 1000 dependencies, too. Zed has over 2000 in release mode.

> NPM is special, in that the exposure is so much higher.

NPM is special in the same way as Windows is special when it comes to malware: it's a more lucrative target.

However, the issue here is that - unlike Windows - targetting NPM alone does not incur significantly less overhead than targetting software registries more broadly. The trade-off between focusing purely on NPM & covering a lot of popular languages isn't high, & imo isn't a worthwhile trade-off.

Not saying this in defence of Rust or Cargo, but often times those dependencies are just different versions of the same thing. In a project at one of my previous companies, a colleague noticed we had LOADS of `regex` crate versions. Forgot the number but it was well over 100

- I feel that you are unlikely to need Babel in 2025, most things it historically transpiled are Baseline Widely Available now (and most of the things it polyfilled weren't actually Babel's but brought in from other dependencies like core-js, which you probably don't need either in 2025). For the rest of the things it still transpiles (pretty much just JSX) there are cheaper/faster transpilers with fewer external dependencies and runtime dependencies (Typescript, esbuild). It should not be hard to replace Babel in your stack: if you've got a complex webpack solution (say from CRA reasons) consider esbuild or similar.

- Axios and Jest have "native" options now (fetch and node --test). fetch is especially nice because it is the same API in the browser and in Node (and Deno and Bun).

- Redux is self-contained.

- React itself is sort of self-contained, it's the massive ecosystem that makes React the most appealing that starts to drive dependency bloat. I can't speak to Svelte.

That seems like a failure in workspace management. The most duplicates I've seen was 3, with crates like url or uuid, even in projects with 1000+ distinct deps.

Your typical Rust project does not have over 1000 dependencies.

Zed is not a typical Rust project; it's a full fledged editor that includes a significant array of features and its own homegrown UI framework.

What is a "typical Rust project", I wonder?

One famous example is ripgrep (https://github.com/BurntSushi/ripgrep). Its Cargo.lock (which contains all direct and indirect dependencies) lists 65 dependencies (it has 66 entries, but one of them is for itself).

Also, that lock file includes development dependencies and dependencies for opt-in features like PCRE2. A normal `cargo build` will use quite a bit fewer than 65 dependencies.

I would actually say ripgrep is not especially typical here. I put a lot of energy into keeping my dependency tree slim. Many Rust applications have hundreds of dependencies.

We aren't quite at thousands of dependencies yet though.

That doesn't make sense. The most it could be is 3: regex 0.1.x, regex 0.2.y and regex 1.a.b. You can't have more because Cargo unifies on semver compatible versions and regex only has 3 semver incompatible releases. Plus, regex 1.0 has been out for eons. Pretty much everyone has moved off of 0.1 and 0.2.

Last i checked react's new compiler still depends on babel! :(

> Zed is not a typical Rust project; it's a full fledged editor

Funny that text editor is being presented here as some kind of behemoth, not representative of typical software written in Rust. I guess typical would be 1234th JSON serialization library.

Jest alone adds 300 packages by the way.

The reason he went down this rabbit hole was because he was chronically running low on disk space, and his target dir was one of the largest contributors.

Not sure how he actually got the number; this was just a frustrated Slack message like 4 years ago

A sibling comment mentions we could have been using Cargo workspaces wrong... So, maybe?

He probably just needed to run `cargo clean` occasionally.

But you definitely aren't finding hundreds of versions of `regex` in the same dependency tree.

Not quite. He is a better developer than most who happen to minimize dependencies, but according to my experiences it is not as common as you would like to believe. Do I really need to make a list of all the Rust projects I have compiled that pulled in over 1000 dependencies? If I need to do it to convince you, I will do so, as my time allows.

> I would actually say ripgrep is not especially typical here. I put a lot of energy into keeping my dependency tree slim. Many Rust applications have hundreds of dependencies.

Thank you for your honesty, and like you and I said, you put a lot of energy into keeping the dependency tree slim. This is not as common as one would like to believe.

I agree it's not common. But neither are Rust applications with 1000+ dependencies. I don't think I've ever compiled a Rust project with over 1,000 dependencies.

Hundreds? Yes, absolutely. That's common.

Maybe I am just unlucky enough to always running into Rust projects that pull in over 1000 dependencies. :D

In retrospect, I should have kept a list of these projects. I probably have not deleted these directories though, so I probably still could make a list of some of these projects.

Yep, which is part of why it feels real good to delete Jest and switch to `node --test`. I realize for a lot of projects that is easier said than done because Jest isn't just the test harness but the assertions framework (`node:assert/strict` isn't terrible; Chai is still a good low-dependency option for fancier styles of assertions) and mocks/substitutes framework (I'm sure there are options there; I never liked Jest's style of mocks so I don't have a recommendation handy).

(ETA: Also, you may not need much for a mocks library because JS' Proxy meta-object isn't that hard to work with directly.)

Yeah, I still don't understand a lot of the architecture choices behind the new compiler, including why the new compiler isn't mostly just a set of eslint suggestions with auto-fixes. I've seen the blog posts trying to explain it, but they don't seem to answer my questions. But then I also haven't done enough direct React work recently enough to have need of or actually tried to use the new compiler, so maybe I am just asking the wrong questions.