Share

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:

1. 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

2. 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

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

• PeerDependencies
• PeerDependenciesMeta
• OptionalDependencies
• BundledDependencies
• engines
• os
• cpu

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:

peerDependencies

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.

peerDependenciesMeta

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.

optionalDependencies

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.

bundledDependencies

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.

engines

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

os

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

cpu

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
	Internet.",
	"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 info@nodesource.com 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