Javascript Node

Understanding dependencies inside your Package.json4 min read

In this blog post, you can find a list and description of dependencies and other host Specs inside package.json.

The dependencies in your project’s package.json allow the project to install the versions of the modules it depends on. By running an install command inside a project, you can install all of the dependencies listed in the project’s package.json, meaning they don’t have to be (and rarely should be) bundled with the project itself.

This is a series, based on one of the most featured whitepapers we have done by developers in the Node.js ecosystem. If you are interested in the complete guide, you can get it through this link.

The 2022 guide includes this, which we will be releasing by units of knowledge every Tuesday in the following weeks. Today you are in part 3 of the guide:

The Essential npm Commands

Using npm init to initialize a project
Using npm init –yes to instantly initialize a project
Install modules with npm install
Install modules and save them to your package.json as a dependency
Install modules and save them to your package.json as a developer dependency
Install modules globally on your system

The Basics of package.json

2.1. Identifying Metadata Inside package.json

The name property
The version property
The license property
The description property
The keywords property

2.2. functional metadata inside package.json

The main property
The repository property
The script property
The dependencies property
The devdependencies property

Understanding the different types of dependencies and other host Specs inside package.json


Dependencies in yourpackage.json

The separation of dependencies needed for production and dependencies needed for development is one of the majorly important aspects of package.json. You’re likely not going to need a tool to watch your CSS files for changes in production and refresh the app when they change. But in both production and development, you’ll want to have the modules that enable what you’re trying to accomplish with your project – things like your web framework, API tools, and code utilities.

Furthermore, there are other lesser-known types of dependencies and specifications that help you to customize your package for specific host environments, namely:


Used to express compatibility with a host tool or library while not requiring them inside the project. As of npm v7, they are installed by default.


Allows peer dependencies to be marked as optional so that integration and interaction with other packages don’t warn you about requiring all of them to be installed.


As its name suggests, it is used to avoid build failures when the dependency cannot be found or fails to install. However, it would be best to handle the absence of the dependency inside your code.


Useful for cases when some special packages need to be preserved locally by means of including them inside the tarball file generated after publishing your project.


Can be used for specifying the node and/or npm versions your stuff works on.


An array of allowed and/or blocked (if prepended with a bang “!” sign) operating systems your module will run on.


Similar to the previous one. An array of allowed or blocked CPU architectures the code was designed for.

What would a project’s package.json look like with dependencies and devDependencies?

Let’s expand on the previous example of a package.json to include some.

“name”: “metaverse”,
“version”: “0.92.12”,
“description”: “The Metaverse virtual reality. The final
outcome of all virtual worlds, augmented reality, and the
“main”: “index.js”,
“license”: “MIT”,
“devDependencies”: {
“mocha”: “~3.1”,
“native-hello-world”: “^1.0.0”,
“should”: “~3.3”,
“sinon”: “~1.9”
“dependencies”: {
“fill-keys”: “^1.0.2”,
“module-not-found-error”: “^1.0.0”,
“resolve”: “~1.1.7”

One key difference between the dependencies and the other common parts of package.json is that they’re both objects with multiple key/value pairs. Every key in dependencies, devDependencies, and peerDependencies is a name of a package, and every value is the version range that’s acceptable to install (according to semver*).

*Semver is a specification outlining a method of encoding the nature of change between releases of a “public interface”. You can read more about “Semver” here You also may find useful “ABC’s of JavaScript and Node.js”.

Connect with NodeSource

Remember that you can now monitor your applications and take your node.js journey to a professional level with N|Solid.

To get the best out of Node.js and low-cost observability, start a free trial of N|Solid.

If you have any questions, please feel free to contact us at [email protected] or in this form.

And if you want to find out about our latest content and product releases, these are the channels to keep up to date with NodeSource:

Nodesource’s Twitter
Nodesource’s LinkedIn

Leave a Reply

Your email address will not be published.

Pin It on Pinterest