4 ms·
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
by 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 agoYou 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 agoWell, 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 agoI'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 agoI'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.