[hu3]

My non-solution years ago was to use as little dependencies as possible. And vendor node_modules then review every line of code changed when I update dependencies.

Not every project and team can do that. But when feasible, it's a strong mitigation layer.

What worked was splitting dependency diff review among the team so it's less of a burden. We pin exact versions and update judiciously.

[user34283]

You can't realistically do that when for example you use Jest as your test runner, which alone would add 300 packages.

ESLint would be another culprit, adding 80 packages.

It quickly gets out of hand.

To me it seems like the fewest projects could use this approach you described.

[hu3]

You usually can. You just gotta be a bit adventurous.

https://github.com/lukeed/uvu is a testing library with almost no dependency.

https://github.com/biomejs/biome is a linter written in Rust which in theory has a smaller attack surface.

And as long as you stay some versions behind bleeding edge, you can use time in your favor to catch supply chain attacks before they reach your codebase.

[user34283]

Well, can you?

Maybe you can.

Or you're talking about an approach you utilized in some side projects rather than moderately sized commercial web applications? I don't imagine there's many out there that have less than hundreds of dependencies.

[hu3]

I'm talking about large, enterprise, projects.

Just because the project is large doesn't mean we should give up on reducing dependencies.

Hundreds is much better than thousands.

[preommr]

I've resorted to just running custom scripts with if statements instead of fancy assertions.

But occasionally I'll use vitest as well which has the same api as jest, and is much simpler. Especially if vite is already being used. It has a much smaller dependency tree.

[bee_rider]

That’s the solution. The whole theory of the many-eyes model is that lots of people will read the code.

You are doing the work. These automatic library installing services seem to have a massive free-rider problem.

[bapak]

Good luck debugging wasm and other bins that are now more and more frequent (see tsgo)