NPM and The Anatomy of package.json: Part Two

In Part One of the post (link) we talked about NPM — What it is and How it’s used. Now we shift the focus onto the package.json and the role that it plays in relation to NPM.

If there is any uncertainty as to what a particular element in the package.json is responsible for, there shouldn’t be by the end of this post.

WHAT IS THE PACKAGE.JSON FILE?…

(And Who Let It Into My Project?)

Package.json is essentially npm’s config file for your modules/projects. This is where you can easily see the project’s key information, manage the dependencies, affect the places that the project can appear, and determine how files can be run inside of the testing and development environments

It should be noted that your project must have a package.json file before you will be able to install any packages from npm or be able to publish your package to npm. The file itself is made up of a few (by npm’s standards) necessary, and a number of optional, properties. As for where package.json comes from, there are two ways to add one to your project:

1. Running npm init -y will initiate a new project with the npm package manager and write a package.json file to the current directory. The -y answers yes to the series of questions npm asks you regarding the default values to appear in the file, which you can change at any point.
2. If for some reason, you wanted to write directly to a file you can do that also. Creating the custom package.json, with the correct configurations, and then making sure to include it in the right directory in your Node project.

PIECE BY PIECE — — — — PACKAGE.JSON

For the sake of our anatomy lesson let’s reference this sample package.json from a project that uses Mysql, Express, and React.

The file is written in the JSON format so that it can be read programmatically by sources trying to access its properties, and the contents of the file can be divided into two categories of metadata:

• Identifying- Where the property presents information about the project itself (who created it, what purpose it serves, etc). We’ll mark these properties with an -I- for identifying.
• Functional- Where the property presents some functional value of the module/project. We’ll mark these properties with an -F- for functional.

NAME & VERSION:: -I-

In the case where the package is going to be published, it is mandatory for these two properties to be defined and given a value inside of the package.json.

• The value of the name property is exactly what you would expect it to be.

Know that if you decide to publish to the NPM directory, this is the name that your package will be listed under.

Limitations on naming include:

— A maximum of 214 char (If you plan to publish, the name must be unique from any other published package in the registry)
— Only lowercase letters
— Hyphens & Underscores are acceptable. No other special char. or spaces allowed.

• The version is the current version of whatever software the package.json is describing. It follows typical version semantics and should be kept up to date so that any other developers can be properly informed on what version of the package the project is designed to run with.

DEPENDENCIES:: -F-

Running the command npm install ___ with some package name, will install that package as a dependency and will automatically place that new dependency inside of this dependencies key’s object in the package.json file.

This is also where you will keep track of the versions of each dependency that the program relies on to run.

If you add --save-dev, or the-D flag, you effectively install it as a development dependency, described below. (This, of course, adds it to the devDependencies list instead of dependencies.)

DEV-DEPENDENCIES:: -F-

Development dependencies are dependencies that are intended as development-only packages. They are supposed to be unneeded in production (like webpack, Babel, or testing packages).

When someone runs npm install, without the — production flag, on a package that has devDependencies specified in the package.json, all of the dependencies and devDependencies will be installed (without the production flag to tell it otherwise, npm assumes it is a development deploy).

CONCLUSION::

Hopefully, these posts together have shed further light on some familiar technologies and helped to plainly define some vague terms we use on a daily basis.

Go forward and look into some of the extremely useful things you can do with tools like the scripts section of the package.json, and the next time you catch yourself about to run a command or pass up a file and you aren’t sure what it’s doing, take a second to stop and figure it out.

Thank you for reading!