package.json File – Explained with Examples
A package.json file is a JSON document that package managers—like NPM and Yarn—use to store information about a specific project.
In other words, a package.json
file is a project’s metadata file.
Advantages of a package.json
File
A package.json
file:
- makes it possible to publish your project to the NPM registry
- makes it easy for others to manage and install your package
- helps NPM to manage a module’s dependencies easily
- makes your package reproducible and shareable with other developers
How to Create a package.json
File
Go to your project’s root directory and initialize the creation of a package.json
file by running:
Or, if your package manager is Yarn, run:
Once you’ve executed the initialization command above, your package manager will walk you through creating the package.json
file by asking a few questions about your project.
If you wish to skip the questionnaire, you can create a default package.json file. Let’s see how.
How to Create a Default package.json
File
Suppose you prefer to skip the questionnaire prompted by the npm init
(or yarn init
) command. In such a case, go to your project’s root directory and run:
Or, if your package manager is Yarn, run:
The command above will use default values extracted from the current directory to create your project’s package.json
file.
Once your package manager finishes its initialization process, your project’s package.json
file will contain an object with a set of properties.
Here’s an example:
You can see that the package.json
file above contains the name
, version
, and main
fields. Let’s learn more about these properties below.
The package.json
’s Fields
The package.json
’s properties make your project usable to package managers and end-users.
Suppose you wish to publish your package to the NPM registry. In that case, your package.json
file must have the "name"
and "version"
fields.
However, if you do not intend to publish your package, in that case, all fields—including the "name"
and "version"
properties—are optional.
Let’s learn more about the commonly used fields in a package.json
file.
name
The "name"
field is a property used to record a project’s name.
The "name"
property’s value must be:
- a single word
- lowercase lettering
- and less than or equal to 214 characters
Note that you can join words together with hyphens and underscores.
Here’s an example:
version
The "version"
field indicates a project’s current version number.
The "version"
property must be in the form of a major.minor.patch
format. It must also follow the semantic versioning guidelines.
Here’s an example:
description
The "description"
field is a property containing a brief description of a project’s purpose.
NPM recommends having a "description"
property to make your package easier to find on the NPM website.
Your description will be one of the information shown when people run the npm search
command.
Here’s an example:
main
The "main"
field indicates a project’s entry point.
In other words, when someone runs the require(<package-name>)
function, Node will resolve the invocation to require(<package.json:main>)
.
Here’s an example:
private
The "private"
field lets package managers know whether they should publish your project to the NPM registry.
Here’s an example:
If you set your package.json’s "private"
property to true
, package managers will not publish your project.
Therefore, setting the property is an excellent way to prevent accidental publication of your package.
scripts
The "scripts"
field defines the script commands you want to run at various times in your project’s lifecycle.
Here’s an example:
The "scripts"
field above contains five properties whose values are the commands we want our package manager to run whenever we invoke the property’s key.
So, for instance, running npm run dev
will execute the "webpack --mode development"
command.
keywords
The "keywords"
field specifies an array of keywords that can help people discover your package.
Here’s an example:
The "keywords"
property is part of the information shown when people run the npm search
command.
Create NPM Package like a pro
author
The "author"
field lists a project’s author’s details.
Here’s an example:
You can also write the snippet above as:
Note that the "email"
and "url"
properties are optional.
dependencies
The "dependencies"
field lists all the packages a project depends on in production (when your app is running on a live server).
Here’s an example:
So, whenever a user installs your project from the NPM registry, the dependencies property ensures package managers can automatically find and install the packages listed.
You can add a package to the "dependencies"
field through either of the following ways:
- Manually add the name and the semantic version of each package your project depends on in production.
- Run the
npm install package-name --save-prod
command on your terminal. Oryarn add package-name
if Yarn is your package manager.
devDependencies
The "devDependencies"
field lists all the packages a project does not need in production—but requires for its local development and testing purposes.
Here’s an example:
The packages listed in the "devDependencies"
field will be available in the project’s development environment but not on its production server.
You can add a package to the "devDependencies"
field through either of the following ways:
- Manually add the name and the semantic version of each package on which your project depends for its development and testing purposes.
- Run the
npm install package-name --save-dev
command on your terminal. Oryarn add package-name --dev
if Yarn is your package manager.
peerDependencies
The "peerDependencies"
field lists all the packages a project expects its host application to have in its node_modules
directory.
Here’s an example:
Suppose you install a project containing a peerDependencies
field from the NPM registry to your application (the host app). In that case, your package manager will check whether your app contains the packages listed in the peerDependencies
.
If so, it means your application (the host app) has the dependencies the installed package needs to work.
But suppose the package manager could not find the installed project’s peerDependencies
in your app. In that case, some NPM versions (like versions 7 and 8) will install them automatically. But other versions (like versions 3 to 6) will display a warning saying that the package you are installing requires some peer dependencies, which you must install yourself.
Note the following:
- Not all developers need to specify peer dependencies. Consider listing
peerDependencies
only if you are publishing your own NPM package. - You need to list peer dependencies manually in your package.json’s
"peerDependencies"
field. Do so by specifying the name and the semantic version of each package your project expects its host application to have in itsnode_modules
directory. - It is best to make your peer dependencies lenient to diverse minor and patch versions. So, suppose the package you wish to publish depends on a React version 17.3.1. In that case, specify
"react": "^17.3.1"
(or"react": ">= 17.3.1 < 18"
) in yourpeerDependencies
’ field. Doing so will make your package broadly compatible with host applications having other React versions that may be greater or equal to v17.3.1 but less than v18.
homepage
The "homepage"
field specifies the URL to your project’s homepage.
Here’s an example: