NPM and The Anatomy of package.json: Part One

As developers, there is any number of benefits to having provided to us these amazing technologies that handle large amounts of the setup and execution stages of our code. But with those conveniences comes also a large potential for gaps in knowledge — especially in a learning environment (whether through a program or in teaching yourself) where you are often supplied the starter shells of projects, that come equipped with libraries, frameworks, and lines of pseudocode that without explanation instruct you to // Run ‘npm install’

You could make it through several complete projects without ever really needing to know where certain files are coming from or all that they’re doing. Ask someone in that position to show you how they start their server or run their test suite and they can probably produce the right answer, having memorized the command from typing it so many times — asking them to explain how that command works or where it comes from may give them a harder time.

Looking at just two of the bigger examples of this, first in NPM and what comes along with it and second (in Part Two of this post (link) at any sense of mystery surrounding the package.json file, let’s clear away some of that confusion…

The Relationship Between NPM and Node.js

What is npm? Npm is Node JavaScript platform’s default package manager; it was the first package manager and registry for Node and remains the most widely used.

— If you’re wishing here that we were also defining packages, package managers, and some other base terms, let’s take a second to do so:

• Package: A file or directory that the package.json describes. They can be Node modules themselves or simply contain Node modules.
• Package Managers: Software tools that exist to automate the processes that relate to not only installing these packages, but maintaining, updating, configuring, and removing them.
• Package Registry: The database where all of these packages that are then published, are stored. (Npm actually has an API that allows developers access to the registry from inside their program, making it possible for package managers other than npm (like yarn and pnpm) to download from the npm registry.
• Dependencies: Anything that is required for your program to “work”. There is a section in the package.json devoted to these that we will talk about later, but for now, just understand a dependency can refer to anything that a package can be. (It can also be used to refer to a module that is imported by a file, but only if that imported module is then utilized within the file.)

That being said, we can acknowledge that npm is part of the deal with Node (meaning it is installed also, when you download Node). It is there to make your life easier, or at least the parts of it that you spend working with JavaScript in a Node environment.

Most commonly, it is used to publish, discover, install, and develop node programs. — The NPM Documentation

There are 3 individual but related components of NPM itself:

1. The Actual NPM site: The website where a user can create an account for npm, set up profiles, manage access to private and public packages, and more.
2. The NPM CLI (Command Line Interface): The CLI runs in the developer’s terminal and allows interaction with npm from inside of the project.
3. The NPM Registry: The largest part of the operation, the registry is the open database of packages and projects. Think of it like a marketplace or even JavaScript software App Store of sorts.

It would be ambitious to try and cover the list of commands available to you through npm but the next time that you can, run `npm help` in your terminal and check out what all you have to choose from. For the purposes of staying in the general scope of npm we’ll mostly cover the basics of package and dependency installation specifics.

NPM — LOCAL vs GLOBAL INSTALLATION

When the time arrives to start installing dependencies, npm provides you with two mode of operation options: Local and Global.

Npm install will default to local mode, so if you want to globally install a dependency you must specify in the command line (one way to achieve this is with the -g or--gflag).

Local::

Local packages will be installed into whatever directory you are currently inside of when you run npm install __, this is also the directory where the associated node_modules folder will be added.

Installing locally makes it possible to maintain however many applications you house on your computer, with some (or all) of them running different versions of the same packages (if necessary).

If the package provides an executable command (meant to be run from the CLI) it will be reused across all projects, that is a package that should be installed globally. Examples would be create-react-app, vue-cl, grunt-cl, mocha, and of course npm.

Global::

Global packages, on the other hand, are not installed by relative positioning — they will all be added to one single location inside of your system. That single location will depend on how your setup is configured.

To start, only one package will be installed globally (the npm package itself). When any other package is installed globally after that, and you are not using a version manager, the package will be saved in the folder owned by the root directory ({some prefix}/lib/node_modules/).

In this situation, it is important to:

• Identify the current global location (which should be the prefix of the node bin location path).
• Change the global location to something like the Home directory. In redirecting, we ensure that globally installed packages will be added to whatever new, user-owned directory you’ve added to Home (which allows you to global install without having to usesudo).

Once you have more than only the npm package installed globally, it can start to be harder to discern which dependencies are installed where. npm list -g --depth=0in the terminal can answer this question — npm list -gcan be run on its own but adding the depth option cleans up the format in which the results are returned.

CONCLUSION::

Hopefully, this first half of the post has served to give a little more information on what npm truly is and how some of the installation specifics work.

It should have set up a foundation of understanding, upon which we can continue to build with Part Two (link) where we will look closely at the package.json file in particular.

Thank you for reading!