In this article, I’ll try to cover the basics of NPM, giving you a good idea of what you can eventually achieve by using it, other than the basic package management you’re most likely already using it for.
Given Node.js’ module ecosystem, one could argue that NPM is literally the bread and butter of any Node project. In fact, one could even go as far as to say that NPM is one of the most important tools the Node.js developer have under their communal belts. After all, they use it everyday to manage the packages their projects use.
Having said that, one could also say that it’s quite sad how little developers actually know about NPM, other than it can, indeed, install packages.
We all know you can install packages with NPM, but what exactly does that mean? A package is basically a folder containing the code you need and you can either install it locally or globally.
A local install means you’re literally downloading the files into your project’s folder. Inside it, you’ll find a directory you didn’t create, called “node_modules”. Because of this simple mechanics, this local folder can potentially grow quite big.
There is a good reason why this meme was born after all:
No wonder this meme was created!
That being said, normally you can just ignore the folder, and let Node.js take care of it for you.
To perform a local install all you have to do is:
$ npm install [package-name]
You can even add the
--save flag, so the package name and version is saved into your
package.json file. And this is important (crucial even), because when working as part of a team, you do not distribute, nor add the node_modules folder into version control system (be it GIT, SVN or whatever you’re using), instead you simply share the
package.json file and let your teammates run
$npm install by themselves. This is much faster and easier to maintain than sharing a whole folder which can grow to contain Gigabytes of data.
Here is how a simple
package.json file looks like:
Yours might change a bit, depending on which packages you’ve installed, or which fields of the file (there are many others I didn’t use in the sample above) you need.
You can also install packages globally, which means Node.js will be able to access them from any project you might need them. The problem? Global packages aren’t added to the
package.json file, which makes sense. So why would you install global packages?
One of the many great things you can do with Node.js and NPM, is build what people usually call “binaries”, which are simply scripts that can be installed globally and thus, be accessible from anywhere on your box. That means you can create command line tools and use NPM to install them!
Without having to go too far, packages such as ExpressJS (one of the most popular Web frameworks for Node.js) or mocha (a very popular testing library) also come with executable binaries you can use. For example, mocha requires you to install it both, globally and locally in order to have a CLI tool available called “mocha” and the ability to run tests on your local project.
Global packages create a symlink (or shortcut) inside a general path that you need to add to your PATH environment variable.
install command is but one of the many you can use with NPM. In fact, leaving aside the almost 60 different commands (yeap, you read that right!) that I’m going to briefly cover in a second, NPM also allows you to create your own custom commands in case the built-in ones aren’t enough for you.
Here is the list of the most common commands, taken from the official documentation:
$ npm access public
$ npm addUserand the user credentials (username and password) as well as their email will be entered when prompted to.
fixto automatically fix any problems you might find during this audit.
npm installbut meant to be used in automated environments (such as a Continuous Integration process). This command is more strict than
installand makes sure the installation is always clean (it automatically deletes the node_modules folder if it’s present).
npm install [email protected]and NPM will understand which version of the library to download.
gitcommands are accessible and executable, the
node_modulesfolders (both local and global) are writable by NPM, the registry or any custom version of it is accessible and finally, that the NPM cache exists and it’s working.
$npm hook add express http://your-url.com/new-express-version-endpointand in turn, you can do anything you like with that information (such as auto-updating your dependencies).
package.jsonfile is created with that information. You also have the ability to provide a custom initializer to customize the processed to your particular stack.
package.jsonfile, but it will also list their dependencies and their versions.
package.jsonfile is expecting and the latest version published in the main registry.
package.jsonfile inside it. You can use the
-gflag and you’ll get the actual place where the global packages are installed.
These are the either the most common or most useful NPM commands available to you, but there are still more than 10 extra commands for you to review so I’d recommend you bookmark their documentation and make a note to go back and double check it!
The last bit of NPM knowledge I wanted to impart on you was how easy it is to actually share your work with others. In the previous list, the very last command was the publish one, which basically allows you to do just that, but here I want to give you a bit more detail.
Preparing your project’s metadata
NPM’s registry is essentially a huge packages search engine, capable of both, hosting everything so you don’t have to and at the same time, index every bit of metadata it can get on your work, in order to help others find your modules as quickly as possible.
In other words, make sure your
package.json is properly setup. These are the main points of interest for you (and others!) to start looking into sharing packages with them.
package.jsonfile to keep track of your dependencies. Just be mindful of it and add it in you haven’t already.
package.jsonprevents developers from finding your work through navigation.
falseas soon as you can, otherwise no one will be able to find your modules through keyword search.
package.jsonfile. You can also just mention it on your readme.md, but adding it here will provide extra knowledge about your project to NPM.
By providing the metadata I mentioned above, NPM is able to showcase that data and highlight it for developers to see. Take the following example, the package page for Winston, a fantastic logging library:
Notice how many links and extra bits and details have been added thanks to the metadata added by its team.
Writing a nice documentation
This step shouldn’t, but it’s completely optional. I say shouldn’t, of course, because if you’re trying to publish a module that is meant to be used by other developers, you need to provide good documentation.
You can’t really expect your tool to be “trivial to use”, or “easy to understand and figure out”. The point of NPM’s registry, is to provide others with pre-made tools that’ll help them solve problems they don’t want nor have the time to solve by themselves. So avoiding to provide a simple set of instructions and explanations prevents them from actually wanting to try and use your tool.
With that being said, NPM’s main site takes a cue from Github in the sense that they also look for a file called
readme.md in the root of your project’s directory. If present, they’ll turn your markdown documentation into a nice homepage as you can see in the above screenshot.
So there isn’t really any excuse when it comes to writing the basic documentation others will need, so just do it in the
readme.md and you’ll have it available in two places at once.
Actually publishing your package
After coding, setting up the right amount of data into your
package.json and writing a useful
readme.md file, you’re ready to publish.
To perform this, you’ll have to do two things:
That’s it, 2 steps, and you’re done. To log-in simply type:
$ npm login
That’ll prompt you to enter your credentials, and once you’ve successfully logged in, you can type:
$ npm publish
Remember to do this from within your project’s folder, otherwise the second command will fail.
Also, remember that the name of your package will be given by the name property from your
package.json file and not from the folder’s name (which usually tends to coincide, but doesn’t mean a thing). So if you’re having a repeated name error (which could happen given the amount of packages available in NPM), that is where you’ll have to make the change.
Thanks for reading and I hope that by now, you’ve manged to understand the complexity and beauty of NPM. It is not just a simple tool for you to install package, but you can do a lot more with it if you take the time to check their documentation.
Let me know down in the comments if you were aware of everything I just mentioned and if I missed something else you’re currently using NPM for, I’d love to know!
Thanks for reading ❤
If you liked this post, share it with all of your programming buddies!
A thoroughly researched list of top NodeJS development companies with ratings & reviews to help hire the best Node.JS developers who provide development services and solutions across the world. List of Leading Node.js development Service Providers...
NodeJS Development Company-Hire Node JS developer from the most prominent NodeJS development company, Mobiweb and get remarkable Node.js app development services.
You have to hire Node JS developer from prestigious and expert Node JS development company Mobiweb Technologies. They are tech enthusiasts with new and latest programming ideas, web development technologies and industry trends.