Building a project upon a library is never free, including a library also means including that library's bugs and download size.
Sometimes one may be able to consider the library an independent piece of code that need no maintaining and doesn't really count towards the complexity of the project, but often that is not the case. As a professional developer the only way I can really justify using some small found-on-the-internet library is if I take care of that code as if it were my own. Maybe the original develop will fix a bug if I find one, maybe he won't and I'd have to do it.
Ultimately an included library is part of the codebase, and as such count in every negative way like any other code. It may be good relatively bug-free code with a clean interface that thus doesn't weigh much relative to its size, but the weight is never zero.
A depend on library
B then including library
A in my project implicitly adds the weight of both libraries.
You always want a library to be as lightweight as possible, including another library will almost always work against this goal. In some cases this will be a small extra weight added for a large benefit in saved work, in other cases it is a lot of weight for very little benefit.
Usually you should avoid library dependencies in libraries, but there are cases where the cost to gain ratio is low and it is acceptable. The following conditions in general make the use of a sub-library more acceptable:
- The library used is a widespread one that generally has few bugs and is well supported.
- All or most of the functionality of the library is being used, if the needed functionality were to be re-implemented the combined code-size would not be a lot smaller for it.
- The library deals with issues that would be hard to solve without it.