Should libraries be packaged together based on similar traits?

Question

I just started a new job and one of my first tasks is to create local nuget packages from the existing libraries, to help with versioning, maintenance, etc. This task had already been started by another engineer. However, he chose to grab many libraries that relate, create a project holding all these libraries, and publish it as one package (specifically a nuget package).

Example:
LibraryA_v1 + LibraryB_v2 + LibraryC_v3 = PackageA_v1
LibraryB_v1 + LibraryC_v3 = PackageB_v2

Then, PackageA_v1 and/or PackageB_v2 would be referenced by whatever project that needs them. However, I see a lot of different problems with this approach.

1. PackageA_v1 and PackageB_v2 are extremely unstable. Anytime a library changes, the package would need to update.
2. Since the packages are unstable, it is highly likely that the principle "Depend upon packages whose I metric is lower than yours" would be broken.
3. I can't seem to access the libraries within the packages (in a simple C# test application), which was the original intent.
4. The last problem I see is that libraries of different versions could be imported into the same project, possibly causing problems (ex. LibraryB_v1 and LibraryB_v2 would be in the same project, if PackageA_v1 and PackageB_v2 are both referenced)

From my studies in software engineering and the principle previously mentioned, I think each library should be kept separate in their own nuget packages. However, my co-worker had obviously thought differently. So, should libraries be packaged together based on similar traits?

Answer 1

You shouldnt bundle libraries together into packages at all.

Put each library in its own package and use the nuspec dependencies to indicate if one relies on another