3 ms·

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 dependenci

by hu3 1y ago

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.

bee_rider 1y ago
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.
user34283 1y ago
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 1y ago
  You usually can. You just gotta be a bit adventurous. https://github.com/lukeed/uvu https://github.com/lukeed/uvu is a testing library with almost no dependency. https://github.com/biomejs/biome 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 1y ago
    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 1y ago
      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 1y ago
  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.
bapak 1y ago
Good luck debugging wasm and other bins that are now more and more frequent (see tsgo)

by hu3 1y ago

bee_rider 1y ago

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.

user34283 1y ago

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 1y ago
You usually can. You just gotta be a bit adventurous. https://github.com/lukeed/uvu https://github.com/lukeed/uvu is a testing library with almost no dependency. https://github.com/biomejs/biome 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 1y ago
  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 1y ago
    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 1y ago
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.

bapak 1y ago

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