Package management systems have existed for a very long time. They help users of systems automate the installation of software packages, as well as their configuration, updates, and other operations related to managing them. We can encounter them while working with operating systems or different programming languages.

The JavaScript world also has its own package manager, and it is npm. The first release of this system was published at the beginning of 2010. Since then, several more versions have already been released. Online I came across information that there are almost 500,000 public repositories in npm. Is this exact information? Hard to say, but there are certainly a lot of them.

Why Do We Need npm?

As a programmer, I often encounter the problem of availability of certain tools or libraries that I would like to use in my projects. The truth is also that sometimes I would not know where to look for already written and verified libraries available on the market. The package manager that npm is certainly solves these problems. There is even a high probability that if I cannot find something in npm repositories, I probably will not find it anywhere else.

Today in npm we can also find CLI tools (Command Line Interface) that help us develop projects based on frameworks such as Angular or the React environment. npm definitely speeds up work, and through the set of tools it offers, it makes managing the data packages we use in our projects much easier.

npm ... and What Next?

Working with npm is primarily working with the command line. npm is delivered by default together with Node.js. So when installing Node.js, npm will be installed by default. Initializing a project that uses npm comes down to preparing the package.json configuration file or running the npm init command. Adding the -y flag to the initialization command answers all wizard questions with "yes".

Packages are installed using the npm install <package name> command. npm installs packages for us in 2 ways. Globally, using the -g or --global flag, in which case they are available across our whole environment, and locally, if we want to use packages only within our project. By default, packages are installed locally in the dependencies collection.

All local packages are installed into the node_modules directory, but more on that in a moment.

Locally in Two Ways

Locally, we have two package collections available for installation: the previously mentioned dependencies, by adding the -S or --save flag to the install command, and devDependencies, by adding the -D or --save-dev flag. devDependencies is a list of packages that will be installed during development. If the NODE_ENV environment variable is set to production, or if we add the --production flag during installation, only packages from the dependencies collection will be installed. It is worth knowing this and understanding the difference. Especially if we plan to publish our application one day and do not want it to contain everything that was used during the programming process.

What Does npm Install?

Many jokes have already been created around what npm installs. More than once you may encounter a comparison of the node_modules directory to a black hole. Of course, a black hole is an insignificant little hole compared with the power of the installation directory.

Why Does This Happen?

npm is based on dependencies between individual packages. Very often, 3 other packages were used to prepare one package. When installing any package, we also install its dependencies - which can sometimes lead to paradoxes, like the one where a package that does practically nothing specific is installed tens of thousands of times per week because it is a dependency of some frequently used tool. Just a paradox... :)

In the node_modules directory, therefore, we will find all packages installed by us, but also all their dependencies and their dependencies - divided into subdirectories. There is a lot of it.

In addition, inside the node_modules directory we have the .bin subdirectory, where we will find all executable files of the packages we have installed. This is useful when we want to run some locally installed package while bypassing npm scripts. Running such a package could look like this: ./node_modules/.bin/<package name>.

npx

For some time now, npm has included the npx command, which lets us run a package that has not been installed. After running the npx <package name> command, npm first checks whether the package has been installed earlier, in the .bin directory, or whether it is in the main cache. If the package is not found there, only then will npm install it, and only then run the invoked package.

package-lock.json

What kind of file is this? It is a file generated during the first run of the npm install command. Every subsequent call of this command will update the package-lock.json file. This file contains information about all installed dependencies and their versions. This is useful when working in a team, to ensure that everyone works on the same package versions. Imagine a situation where we work on one project while having different versions of key packages. Different versions may contain different methods: they may have been removed or added depending on the package version. It is easy to imagine the problems this can generate.

npm ci

If our project already contains a package-lock.json file, let us remember not to install packages using npm install. Doing so means we will not use the valuable information contained in the lock file. If we want to have the same versions as the rest of the team, we should install packages using npm ci.

Much, Much More

The few words above are only an introduction to the secrets that npm hides from us. A lot can be written about preparing repositories and using scripts. I think discussing the configuration file alone would take us quite some time. That is why I leave the topic open. I promise I will return to it in the near future.

Summary

npm changed the JavaScript world, even though it is not the only package manager. It is also worth mentioning Bower, released in 2012. In my opinion, the Open Source world is what we know today largely thanks to Isaac Schlueter, who initiated the npm project. It is worth knowing npm well, just as it is worth knowing Git well - without a doubt, it is one of the basic tools in the hands of a modern JavaScript programmer.