Choosing a Package Manager

So far, we have learned a bit about Node.js and its internal modules. We also started to write our own modules, but we have either avoided or worked around using third-party packages.

One of the big advantages of Node.js is that using other people’s code is actually quite easy. The path to doing so leads us directly to package managers. A package manager helps us to handle the life cycle of packages containing modules that can be used in Node.js.

In this chapter, we’ll learn how Node.js’s de facto standard package manager npm works. We will then go on to learn about other package managers, such as Yarn and pnpm. They all promise some advantages in terms of usability, performance, or reliability. We will take a deeper look at them to understand these advantages and who might benefit from using each of the different package managers. Finally, we’ll also look at alternatives.

This chapter will help you to use third-party...

Technical Requirements

Some code examples for this chapter are available at https://github.com/PacktPublishing/Modern-Frontend-Development-with-Node.js/tree/main/Chapter03.

The CiA videos for this chapter can be accessed at http://bit.ly/3TmZr22.

Using npm

When you install Node.js from the official sources, you get a bit more than just Node.js. For convenience, Node.js will also add a few more programs and settings to your system. One of the most important additions is a tool called npm. Originally, npm was intended to stand for Node.js Package Manager, but today, it is essentially its own standalone name.

The goal of npm is to allow developers to manage third-party dependencies. This includes installing and updating packages, as well as handling their versioning and transitive dependencies. A transitive dependency is established when dependencies that are installed also include dependencies, which therefore need to be installed, too.

For npm to know what dependencies exist and what their dependencies are, the npm registry was created. It is a web service that hosts all packages on a file server.

Changing the used npm registry

Today, many npm registries exist – but only the official one located at https:...

Using Yarn

The issue with the original npm package resolution algorithm was that it was created in a resilient but naïve way. This does not mean that the algorithm was simple. Rather, here, we refer to the fact that no exotic tricks or experience optimizations have been considered. Instead of trying to optimize (that is, lower) the number of packages available on the local disk, it was designed to put the packages into the same hierarchy as they were declared in. This results in a filesystem view as shown in Figure 3.1:

Figure 3.1 – Example filesystem snapshot after installing packages using npm

The naïve way of handling package installations is certainly a great way to ensure that everything is installed correctly, but not ideal in terms of performance. Looking at Figure 3.1, there may be some optimizations possible.

Let’s add some example package names and versions to Figure 3.1 to see the opportunities for optimization. In Figure...

Using pnpm

The approach of pnpm feels a bit like the original package resolution of npm. Here, each package is essentially isolated and puts its own dependencies into a local node_modules subfolder.

There is, however, one crucial difference: instead of having a hard copy of each dependency, the different dependencies are made available through symbolic links. The advantage of this approach is that every dependency only needs to be resolved once per system.

The other advantage is that for most packages everything is as it should be. There is nothing hiding behind an archive or via some custom mapping defined by a module that would run in the beginning. The whole package resolution just works. The exception to this rule is packages that use their path to find other packages or work against a root directory. Since the physical location of the packages is global, and therefore different from the project’s location, these approaches do not work with pnpm.

Installing packages...

More alternatives

There is no strict requirement when using a package manager. Theoretically, it does not matter where the code comes from. You could, for instance, download the packages directly, extract them, and refer to them via their local path.

Alternatively, a system such as Deno could be interesting. On the surface, Deno is quite similar to Node.js. However, there are a few crucial differences under the hood. The most striking one is that there is no package manager for Deno. Instead, packages are just URLs that are resolved once needed. This way, the package installation is just a download – which happens to run when needed.

Deno in a nutshell

Deno was created by Ryan Dahl – the creator of Node.js. As such, Deno shares many features with Node.js but deviates in some aspects. Deno aims to be a lot more compatible with JavaScript running in the browser than Node.js. Deno also tries to be secure by default. When running a script with Deno, the provided...

Summary

In this chapter, you learned how to use a package manager to handle everything related to packages. You’ve leveraged the default npm command-line utility. You got in touch with the most important alternatives, Yarn and pnpm. You should know what Yarn brings to the table – after all, PnP and zero-installs are neat features. Furthermore, you checked out some alternatives and learned about custom registries and repository task runners such as Turborepo.

At this point, you have everything to clone and run existing Node.js projects. You can install new dependencies, check for outdated dependencies, and update them. This gives you the power to integrate all of the over-a-million packages that have been published over the years in the npm registry.

In the next chapter, we will discuss how different flavors of JavaScript, such as more modern specifications or languages that use JavaScript as a compilation target, can be used in Node.js.