NPM 7: This Is What I Call An Update
NPM version 7 released two new features that really made a difference for me: workspaces and better peer dependency management.
It’s been a while since we’ve gotten a substantial update to our trusted NPM. But now, with Node’s latest release (version 15), we also got version 7 of NPM, which comes with a major overhaul of its internal architecture, as well as some very interesting new features.
In this article, I’m going to cover the two that caught my attention and sparked my imagination. With one of them, we’re going to change the way we handle dependencies for all projects and with the other one, we’re going to optimize a process that right now has to be done manually.
I’m of course talking about workspaces and the ability to auto-install peer dependencies. Are you excited yet? I know I am!
Workspaces
I recently shared an article that covered 2 different NPM clients that tried to fix one of the major issues with the current implementation of the official client: the disk space black hole that the npm_modules folder had become.
Each of these alternatives had their own version of a solution, but the gist of it was that they would save all modules inside a shared folder, which made it easier for all projects to share packages with each other. With the latest release of NPM and the creation of Arborist (the new project containing the logic responsible for traversing and analyzing the directory tree of the modules inside the npm_modules folder), we got an official response to this approach: Workspaces.
Mind you, this is not a brand new concept either, other package managers such as Yarn and pnpm had already provided their own versions. So you can say that this is just the official flavor of workspaces.
What are they?
You can think of them as a way to share packages between projects inside a pre-defined and common context. We’re not talking about fully generic packages and a single download location for everything. Because while that would indeed solve the problem of duplicating modules over and over again, this solution also gives you the ability to control which projects we’re sharing our modules with.
By creating workspaces, you specifically tell NPM where your packages will live, and because the new version 7 client is workspace-aware, it will properly install dependencies, without duplicating the common ones.
This feature is very useful when using other registries, as well. For example, a Bit component, (an independent component shared on Bit’s component hub), can be shared between multiple projects managed in a single NPM Workspace. This can be used to get immediate feedback (see if anything breaks) from multiple projects when a modification is made to a shared component.
Learn more about it here:
Is this backward compatible?
Heck no! Workspaces aren’t just about a configuration change, they require you to structure your projects differently. So no, you can’t just run an npm command and normalize 10 projects at once. You can, however, after some re-thinking of their all structure, and the correct configuration changes, re-install the dependencies of 10 (or more) projects into a single place, allowing you to de-duplicate everything. And if you ask me, this is truly a huge improvement!
By forcing you to consider the actual structure of your workspace and how different projects relate to each other, this change is also helping you improve the internal organization of your work.
Consider the following example
There are lots of articles out there covering what workspaces are, but the examples they provide were of no help to me, so here is one that hopefully, is more relatable to a Node.js developer.
Consider the following folder structure:
Essentially, we’re saying that we’re going to be working on a set of REST APIs, where the actual code for each of them will be inside the “apis” workspace, and the generic code and shared packages will be inside the “core” workspace.
How do we achieve this? Once you understand how it works, the configuration process is actually quite straightforward. The point here is that you need to define a package.json file at the root level (inside the REST-APIS folder) where you declare the workspaces. With that ready, all you have to do is create one package.json inside each individual project, and declare their required dependencies there.
You then run npm install from the root folder and let NPM do the rest. This is what the package.json file looks like inside the root folder:
That is all you need, you can, of course, define other properties, but for the purposes of this new feature, the “workspaces” key is all you need. Inside of it, you can define (as you can see in the example) a list of paths (with the included wildcard format as well) that reference the folders where your workspaces will live.
Inside these folders, you just declare your own package.json files, each of which declares its specific dependencies.
You can see how the JSON files for each API folder only really differ on their name and their dependencies. The same goes for the core folder, where we declare Express as their main shared dependency:
We can now run npm install from the root folder and what do you think will happen? It will install everything each of these workspaces requires inside a generic node_modules folder. And because of that, repeated dependencies will not be duplicated.
With the command and folder structure given so far, you’ll end up with all three modules (and their required dependencies) installed inside the node_modules folder located at the root level. However, any file inside its hierarchy will be able to access all three of them.
Look at this file, inside the apis/api2/ folder:
It is using all three dependencies when it shouldn’t be able to find them normally. This is awesome!
Are workspaces what you need?
Well, if you’re working on individual and unrelated projects, maybe workspaces aren’t really that useful to you. At any given point, the requirements for them could change, and that would render the benefits of the workspaces useless.
However, if you’re working as part of a team on several related projects (maybe you’re crafting a microservices-based architecture), then workspaces might actually be a very needed feature. Just think about the amount of disk space you’d be saving if you have an architecture of 100 microservices, all of them depending on the same set of modules. That’s where this feature really starts to shine!
PeerDependencies installed automatically
And the second big feature I wanted to cover today was this one. Up until now, peer dependencies had to be installed manually. That’s not the case anymore though. But first, what exactly are peer dependencies?
In case you’re not super familiar with the term (I know I wasn’t), peer dependencies are almost like normal dependencies, but instead of defining a strong requirement, they essentially state that:
- Your package is compatible with a specific version of another module.
- If this module is already installed and it is the correct version, then don’t do anything.
- If the module isn’t found, or there are conflicting versions, then don’t do anything but display a message to the developer warning them about this fact.
This is all good in theory, but the problem with automatically installing these dependencies was that when you added two packages which had the same dependency but with different versions, both versions would get installed (one of them at the regular node_modules folder and the other, as a sub dependency of the package that requires it).
This could potentially cause incompatibility issues, imagine adding module A which depends on module B which in turn, depends on React@15, into a project that, in turn, depends on React@16. Because A needs version 15, it would add it as a dependency as well, ending with a dependency tree like:
- React@15
- A
- B
+- React@16This would mean you end up installing React twice, with different versions. All because you needed module A . Now, however, thanks to Arborist, the full tree is analyzed and peer dependencies are taken into account, which means that if a conflict is going to be present, a proper error will be displayed and the process will be aborted.
Essentially, NPM will now do the developer’s job and help the latter decide whether they should install that peer dependency or not. This is definitely a very useful feature if you consider the amount of work dependency management can add to your day.
Have you had to deal with that in the past? How exciting is this change for you?!
Version 7 of NPM was released with several new features and improvements. These two particular ones were the ones that definitely caught my attention and got me really excited to try them. Workspaces have the potential to radically improve the developer’s experience when working on large, combined projects with multiple shared dependencies.
And the improvement in peer dependencies management will definitely affect React developers working with NPM based tools since that ecosystem has adopted the use of this feature extensively.
What about you? Are you excited about any of these features? Did I leave your favorite update out? Leave a comment down below and share your thoughts, I’d love to know what you think about version 7 of NPM.
