Over the weekend I wrote about the Bootstrap grid system and the Bootstrap Snippet Pack for Visual Studio, both extracts from Chapter 4 of my upcoming book "Front-end Development with ASP.NET Core, Angular, and Bootstrap".

Today I'm going to cross halfway point in my book, taking a extract from chapter 5, which is about package managers and Nuget, NPM, Bower. And I'm going to introduce package managers and why we need them.

Why we need package managers

Modern software development, both front-end and server-side, is based on small and very focused components that can be composed as needed.

While it is good to avoid the monolithic frameworks of the past, this new approach introduces a problem: how do you manage all these components? Components usually depend on other components, which depend on yet other components, which depend... well, you got the idea. To make things more difficult, there might be a component, let's call it A, that depends on component B, but also another component, C, that also depends on B, but a different version of it. And on top of this, all components must be kept up-to-date. Finally, in some cases, to correctly install a component, additional operations might be needed, like compiling some native library or changing some configuration files.

Fortunately, all these tasks are automated by specific tools that are called package managers.

What package managers do

All package managers, apart from the obvious differences given by the different technologies or languages they target, are practically identical. Here are their common concepts:

• They all rely on a public registry that contains all published packages. The registry might also store the actual package or just provide the URL where the package can be downloaded.
• Packages are downloaded and stored in a local folder (usually within the current user folder) that acts as a local cache. This way when a project needs a package that has been already downloaded, it's directly copied from the cache instead of being downloaded again (providing that it is the latest version). This saves bandwidth and time (especially if packages are restored every time a project is built). It also allows some kind of offline development experience that would be otherwise impossible.
• Projects declare which third-party libraries they depend on. This is usually done by specifying in a JSON file the names of the packages and their versions.
• Package managers take care of downloading not only the projects’ dependencies but also the libraries they depend on, descending the entire tree of packages.

There are still lots of interesting topics coming up from my book. If you are interested in knowing more, come back tomorrow and also remember to follow me on Twitter @simonech and like the Facebook page for my book.