The first alternative we’re going to be covering is pnpm or also known as Performant NPM.
Although taking the packages from the same place as regular npm, this package manager has two major differences:
- On one side, it saves modules inside a common folder, so if you have 100 projects depending on lodash for instance, you will only have one folder where that dependency is actually installed. The actual projects will have their npm_modules folders filled with hard-links. Which means no extra disk space is required.
- On the other, the content of the common folder will actually be flattened. Meaning that instead of saving the intricate hierarchy of folders that a normal dependency tree generates, pnpm will save individual folders based on the content of the module (using a sort of hashing function to generate the ID, instead of simply using the module’s name).
The main benefit of pnpm is right there its name: performance.
According to its creator, it is much faster than Yarn and NPM, check out the results of this benchmark done by him:
As you can see in almost every case pnpm manages to outrun the other alternatives.
Of course, these numbers might change a bit with the latest version of npm, released recently.
The other, less evident-but-equally-important benefit, is that it provides quite a range of commands, such as
test and the list goes on. Please review their documentation for the full details.
Installation and usage
In order to install it, you can simply use NPM like shown below and download it as a global package:
npm install -g pnpm
Once that is done, you can use it with the
add command, as shown in the below screenshot. You get the following output (quite fast too, by the way):
And with that, your content-addressable-store was added and a virtual content store got created as well. All in a centralized place, meaning that all your projects will share them and you won’t have to re-download them every time.
Using different versions of the same package
This might sound like a crazy idea, but sometimes crazy times require crazy solutions. This is why with pnpm this can be done simply by declaring aliases. This is perfect because you can even create an alias that overwrites an existing name.
pnpm add lodash1@npm:lodash@1
pnpm add lodash2@npm:lodash@2
The above two lines installed two versions of lodash (1 and 2) aliasing them as
lodash2 so you can now reference them using
require("lodash1"); for example.
However, you can also install your modified version of an existing package (maybe due to a last-minute fix that hasn’t been merged into the official repo yet) like this:
pnpm add lodash@npm:awesome-lodash
This essentially overwrites all references to
lodash to start referencing your own installation and modified version of it. The main benefit is that you don’t have to change your code if you were requiring
lodash you can keep doing it and use the new version.
Much like the previous alternative, ied attempts to solve the main problem with npm, which is: the disk space sinkhole that the npm_modules folder is.
And the solution is actually the same as it was for pnpm, using a CAS (Content Addressable Storage) this module hashes the content of the modules to determine the best folder name and stores the downloaded code into a flat, shared folder where all dependencies can coexist.
The main benefit of this, of course, is the fact that you only need to download the same dependency once, even if you have 100 projects using it on your local computer. The amount of space saved by this is monumental.
Content is accessed then, again like before, through a set of symlinks put in place by ied.
The second major benefit of this module is that it performs the concurrent installation of dependencies. Meaning that instead of downloading one by one, it’ll attempt to download as many dependencies as possible at the same time, in fact, the dependency download would finish before having the main packages downloaded.
Installation and usage
Installing ied is just as simple as doing:
npm install ied -g
With that out of the way, you can then use it just like you would npm since it attempts to reproduce roughly 80% of the commands supported by the other.
As an example, you can try and install the
underscore package by using the following line:
ied install firstname.lastname@example.org
The version part is not officially required, but I was not able to make it work without it, so take that into consideration.
The truth is, that although I’m not able to give you a screenshot of the output for this command because there is none, the package gets installed almost immediately.
This package manager provides the fastest installation experience I’ve seen for Node.js.
This alternative provides a different spin on the situation. You see, npmd was designed to be network-efficient, by reducing the number of round-trips it required to install a dependency.
This is especially useful when used in situations where the network connection is either limited or too expensive. Of course, it will also work for you in a normal scenario, but know that it was designed for use in 3g networks or from similarly limited places.
Installation and usage
In order to install it, you can simply use npm like before:
npm install npmd@1 -g --carefully
Now, when it comes to using it,you don’t have as many options as you do with the original npm, but you do have your main
resolve option will do everything but download and install the package. Instead, it will output a JSON file, listing the dependency tree. Its structure is compatible with npm-shrinkwrap so it can be used to lock dependency versions.
And finally, thanks to the global cache hat it keeps, although it will not save you disk space by avoiding the duplication of the node_modules folder content. It will save you the network connection required to install a dependency that you have already installed.
So pay special attention to this module if you’re working with Node.js in a network-limited scenario.
NPM has been doing an amazing job as the main package manager for Node.js, and although it may or may not have a lot of defects, the truth is no piece of software will please all users. This is a fact.
Thankfully though, our community is dynamic enough that if there is a pain point, someone (or as the actual case has proven, multiple someones) will step up to the challenge and will try to provide a solution that works for those unhappy.
Are any of these alternatives to npm better than the original? I wouldn’t say 100% yes, but they do solve a very specific pain point, and who knows, maybe in the future NPM will take a cue from them and incorporate their logic into the main package!
Have you tried any of these utilities? What about others? Leave a comment down below sharing your thoughts! Just bear in mind I left out solutions that don’t use the npm registry as their repository on purpose, so alternatives such as Yarn that at out the discussion.