> Having Thousands of dependencies is fundamentally more 'risky' than have a few. Period. End Of Story. No, this is misrepresenting the issue. The amount of de

> Having Thousands of dependencies is fundamentally more 'risky' than have a few. Period. End Of Story. No, this is misrepresenting the issue. The amount of dependencies you have is just as irrelevant as the amount of lines they contain. What actually matters here are the following things: 1. How many different entities am I trusting? 2. How hard is it to audit this code? 3. How easy is it to 'lock in' a dependency version without missing out on updates I need? 4. How much work is it to review updates? There's no significant difference between small and large dependencies for point 1. You can choose how many entities you trust, regardless of whether the functionality you are using is split up into many small packages from the same author, or combined into one big one. There will usually be no difference for point 4, because the amount of updates generally relates to the amount of functionality that is being updated. This means that larger modules means less CHANGELOG files to track down, but smaller modules means less chance of an upgrade affecting something you're not using to begin with. It evens out nicely. However, for points 2 and 3, there is a difference - in favour of small modules. A much smaller, more well-defined surface with less implicit dependencies and coupling. These are the metrics that actually matter. EDIT: To clarify, 'smaller' and 'larger' here refers to complexity, not line count.