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

When the left-pad debacle happened, one commenter here said of a well known npm maintainer something to the effect of that he's an "author of 600 npm packages, and 1200 lines of JavaScript".

Not much has changed since then. The best counter-example I know is esbuild, which is a fully featured bundler/minifier/etc that has zero external dependencies except for the Go stdlib + one package maintained by the Go project itself:

https://www.npmjs.com/package/esbuild?activeTab=dependencies

https://github.com/evanw/esbuild/blob/755da31752d759f1ea70b8...

Other "next generation" projects are trading one problematic ecosystem for another. When you study dependency chains of e.g. biomejs and swc, it looks pretty good:

https://www.npmjs.com/package/@biomejs/biome/v/latest?active...

https://www.npmjs.com/package/@swc/types?activeTab=dependenc...

Replacing the tire fire of eslint (and its hundreds to low thousands of dependencies) with zero of them! Very encouraging, until you find the Rust source:

https://github.com/biomejs/biome/blob/a0039fd5457d0df18242fe...

https://github.com/swc-project/swc/blob/6c54969d69551f516032...

I think as these projects gain more momentum, we will see similar things cropping up in the cargo ecosystem.

Does anyone know of other major projects written in as strict a style as esbuild?

The answer is to not draw in dependencies for things you are easily able to write yourself. That would probably reduce dependencies by 2/3 or so in many projects. Especially, left-pad things. If you write properly self contained small parts and a few tests, you probably don't have to touch them much, and the maintenance burden is not that high. Compare that with having to check every little dependency like left pad and all its code and its dependencies. If a dependency is not strictly necessary, then don't do it.

That's not an answer at all. Jest alone adds 300 packages.

Why don't you share with us what your project does and how many packages are present?

My current project? Not sure what that has to do with the discussion, but my current project uses only a tiny bit of JS and has a fallback for users who don't run JS. It is a few pages taking a file to upload and the all the actual sauce is in the backend, and it is rendering templates.

So I simply avoid the whole problem altogether in my current project. But aside from the JS stuff, the backend is in Python and I avoid adding dependencies from PyPI wherever possible. For example I had the choice of going with Pydantic and dataclasses and whatnot, but I resisted that, and came up with a quite minimalistic way to type check JSON documents, that is contained in one short module and easily extensible. Does it go to the same length as pydantic? No, it doesn't. If it did, I would be a genious. But it is quite sufficient for type safety in my project.

Keeping things simple is possible, if we set our minds to it. Sometimes one cannot avoid a big dependency, sure, but in many cases we actually can! We just need to beat that beast of habit of quickly adding a familiar dependency without thinking about the cost.

So you're not using the npm ecosystem at all.

Surely you see how that might be relevant to the discussion where you appeared to give advice on how to solve the npm dependency graph problem.

That you're not using npm or other node package managers at all is the key information here. Not that it's invalid, but it's a very different setup.