True, but in general, the more code, the more bugs. Now there are a number of qualifications to that statement:
- More dependencies doesn't necessarily mean more code. Each dependency could be small (and well tested).
- "More code" doesn't necessarily imply a higher percentage of bugs per amount of code.
- Having more dependencies doesn't necessarily mean I'm calling more functions or hitting more code paths.
However, a larger codebase will tend to have more "pieces" of code that can interact, which will tend toward combinatorial growth in the number of ways to (mis)use those bits of code. If I have more dependencies, there are more pieces of code interacting and exponentially higher potential for bugs. So, while I listed out those qualifications, I don't believe they are the norm.
On the other hand, if I need some functionality, then either I use a dependency the provides the functionality, or I implement whatever it is myself. In that case, I'm taking a bet that my code will be better tested and more correct than the library author's code. In most cases, I think I would lose that bet.
Agree. As long as your dependencies are good so you don't need to open the hood then don't worry about it.
I just accept it: I'm not an artist or an F1 driver, elegance and unparalleled performance in the code shouldn't be my concern as long as it is solid and works. I'm in the business of solving business problems, not at scale, not in realtime but on a shoestring budget.
If you have success with a toolkit and it has good testing and community support, don't walk away because the graph looks weird.
Take all those frameworks and inline them directly into your main package...now your graph collapses....are you better off?