Dependency package management design - Single big package or atomic single responsible packages

Introduction

When our applications or the system (set of connected applications) grow, we would require separating the code into components and distribute it to the application developers. This post is discussing how to design dependencies. Big dependencies or smaller dependencies

Importance of dependency management system

Though our system is not big, it is good to adopt a dependency management system. Also good to channel the public dependencies too the same repository of packages. Some reasons, not a complete list below

• It helps to have a central repo. Easy to control what versions of dependencies are allowed to use. Otherwise, later it will be difficult to understand what all dependencies are used in our organization.
• It increases code reuse
• Less compile time as all the dependencies don't need to be compiled with the application change. This is arguable as the application compilation requires dependency download time.
• Easy to track usage of code by package download and decommission.

Dependency design

Now coming to the main point. When we split our code how should we split it? Should we create a single package named cross-cutting and include everything there such as logging, caching, etc... or create single responsible packages.

Criteria	Big package	Smaller single responsible packages	Comments
Package selection	Lessor one package to refer to. Consumers just refer it.	There may be packages doing similar things. The difference may be very less and difficulty in choosing
Change management	Consuming developers may require only one class change. But they get full changes. This adds regression testing efforts	Consumer developers need to make sure every package is up to date.  But easy to test package version upgrade
Package release agility	High chance that it may follow the release of the monolith application where developers of individual classes or components in the package have to wait for green signal from other teams to release package version.	Each package dev team can release at high speed.
Package support	Only one big team to reach out. Consumer life would be easy.	Based on organization structure the package authoring teams may scatter causing consumers difficulty to get support

What industry follows?

The leading dependency management system NPM for Node.JS generally follows the second approach of smaller packages. Every package does one thing and does it well. Often using other packages to achieve something and expose that Facade kind of API.

The .Net Nuget system was not atomic like the NPM. But with .Net Core or Future .Net it is also following the Node.JS path of separating bigger packages into small atomic.

Answer

My answer is

atomic package model where one package does one thing and does it well.

Below are the rationale

• The industry is going agile. ie shorter release times.
• Microservices would be the main consumers of packages. They are small and why should they carry bigger package foot prints?

If we look at one of my nuget library DotNet.Helpers, that is not following this design. It has different components even from different technologies. That package has created to store my knowledge and reusable code than evolved from large projects.

My prediction is that software industry will converge to one technology and Node.JS or its successor Deno will replace .Net for desktop and web programming. So before I am stopping .Net, I am just storing my knowledge. Its just my prediction similar to I predicted death of Silverlight and WPF.

Things may change as Blazor is emerging and it may (very less chance) get popular and .Net will survive.