Looking forward to the day that an actual, genuine discussion can be had about "minimizing dependencies" and what that entails, instead of the horde of "just make number low, problem solved" arguments that always happen in practice and completely ignore important things like internal complexity and peer review
"you"
@joepie91 Impossible to even answer the question of "too many" without knowing what they are and what they're doing. And there's definitely such thing as "too few". Including those parts you should have split into its own package because they're generically useful and someone else would need to reinvent the same thing.
@joepie91 people will rail against projects with “too many dependencies” and “not invented here syndrome” in the same paragraph
@marlies Bingo, that is exactly the sort of thing I'm thinking of.
I can count on none hands the amount of "zero dependencies!" projects I've audited or reviewed that had correct and reliable implementations of the wheels they reinvented.
(And often their internal complexity was *worse* than the dependency they were avoiding...)
"you"
Or to phrase it differently: we'll talk about "minimizing dependencies" when you show you understand how to minimize your *project complexity* first