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
PackageB_v2 would be referenced by whatever project that needs them. However, I see a lot of different problems with this approach.
PackageB_v2are extremely unstable. Anytime a library changes, the package would need to update.
- 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.
- I can't seem to access the libraries within the packages (in a simple C# test application), which was the original intent.
- The last problem I see is that libraries of different versions could be imported into the same project, possibly causing problems (ex.
LibraryB_v2would be in the same project, if
PackageB_v2are 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?