Properties Breakdown
Let's examine the attributes that can be used in detail now:
1. name
Used to set the package name, the name must be less than 214 characters, not have spaces, and contain only lowercase letters, hyphens, or underscores.
Example;
"name": "test-project",
The name being so restrictive is when a package is published on npm; a URL is assigned to it on this property.
2. author
It is used to list the author names of the package.
{
"author": "Joe <joe@whatever.com> (https://whatever.com)"
}
It can be simplified by destructuring in the following format.
{
"author": {
"name": "Joe",
"email": "joe@whatever.com",
"url": "https://whatever.com"
}
}
3. contributors
A project can have more than one contributor. An array of lists is used to specify the contributors list.
Consider the following example.
{
"contributors": ["Joe <joe@whatever.com> (https://whatever.com)"]
}
This again can be destructured in the following format:
{
"contributors": [
{
"name": "Joe",
"email": "joe@whatever.com",
"url": "https://whatever.com"
}
]
}
4. bugs
This is typically used to link to the package issue tracker, most likely a GitHub issue page.
{
"bugs": "https://github.com/whatever/package/issues"
}
5. homepage
It is used to set the homepage of the package. An example is:
{
"homepage": "https://whatever.com/package"
}
6. version
This indicates the current version of the package. Note that the package version follows the semver notation for versions; the version number is always expressed in the following format, x.x.x.
The first x is used to denote the major version; the second is used to denote the minor version and the third one for the patch version.
A change in patch represents a bugfix that does not break anything; a change in a minor version represents a new functionality that does not break anything. A change in a major version represents a large change that breaks the compatibility.
An example is:
"version": "1.0.0"
It is important to note that In package.json, you can set which versions you want to upgrade to (patch or minor), using the semver notation, for example:
- if you write ~0.13.0, you want only to update patch releases: 0.13.1 is ok, but 0.14.0 is not.
- If you write ^0.13.0, you want to get updates that do not change the leftmost non-zero number: 0.13.1, 0.13.2, and so on. If you write ^1.13.0, you will get the patch and minor releases: 1.13.1, 1.14.0, and so on up to 2.0.0 but not 2.0.0.
- if you write 0.13.0, that is the exact version that will be used, always
7. repository
This property specifies the place where the package repository is located.
The prefix github specifies that the repository is located in Github.
"repository": "github:whatever/testing",
If the repository is located in bitbucket,
"repository": "bitbucket:whatever/testing",
What if the repository is located in gitlab?
The answer is simply to replace the prefix with gitlab.
The above declaration can be destructured in the following format:
"repository": {
"type": "git",
"url": "https://github.com/whatever/testing.git"
}
8. scripts:
This property takes an object with as many key/value pairs as desired; each of the key is the name of the command that can be run, the corresponding value is the actual command that is run.
"scripts": {
"dev": "webpack-dev-server --inline --progress --config build/webpack.dev.conf.js",
"start": "npm run dev",
"unit": "jest --config test/unit/jest.conf.js --coverage",
"test": "npm run unit",
"lint": "eslint --ext .js,.vue src test/unit",
"build": "node build/build.js"
}
You can run these commands by calling npm run xxxx or yarn xxxx, where xxxx is the command name.
For example, npm run unit.
9. dependencies
The dependencies property is where the dependencies that the module uses are defined. Note that the package is automatically inserted in this list whenever a package is installed using npm or yarn.
"dependencies": {
"vue": "^2.5.2"
}
10. devDependencies
The property is almost identical to the dependencies property, with a key difference specifies the dependencies that the module needs to run in development.
"devDependencies": {
"escape-html": "^1.0.3",
"lucene-query-parser": "^1.0.1"
}
Some other useful properties are:
- main -> It sets the entry point for the package; whenever a package is imported in an application, that's where the application searches for the module exports.
- engines -> This is used to set which version of Node.js and other commands that the application/package works on.
- browserslist -> It is used to tell which browsers the application supports.
Yet another important file, called the package-lock.json, is automatically created when the node package manager you are using in your application is v5.x.x.
At first sight, the dependencies look quite similar to the package.json file, but it's more verbose.
The Package-lock.json file
As per the official documentation, The goal of the package-lock.json file is to keep track of the exact version of every package that is installed so that a product is 100% reproducible in the same way even if packages are updated their maintainers.
To understand the need of a package-lock.json file, it is crucial to understand a scenario. Consider that you are implementing a project in express, at the time of the creation of the project, the latest version of express was 4.15.4, so inside the package.json file, "express": "^4.15.4" will be added as the dependency.
(^4.15.4 signifies that at a minimum version 4.15.4 should be used, but any higher version is also fine to use)
Now let's consider that maintainers of express released a bug fix; the latest version now is 4.15.5.
Now another person who was contributing to your project along with you had a new feature to add. The person cloned the repository, and as you might have figured out, he would run "npm install".
Version 4.15.5 is a higher version with the same major version that is installed for both of them.
Now the situation is, You in your system has 4.15.4 version of express and the other person has 4.15.5. There might not be major differences but what if the bug fix affected the functionality that we are using our application will then produce different results with the two versions.
If it does not make sense to you in one go, it is recommended that you read out the version dependence of the package.json file once again. The concept is clearly explained there.
The goal of the package-lock.json file is to avoid the confusions likely to occur in the situation described above, where installing modules from the same package.json files results in two different installs. The package-lock.json sets your currently installed version of each package in stone, and npm will use those exact versions when running npm ci. The package-lock.json file needs to be committed to your Git repository, so it can be fetched by other people, if the project is public or you have collaborators, or if you use Git as a source for deployments.
What better way to understand than an example, run npm install cowsay in an empty folder.
The package-lock.json will look like this
{
"requires": true,
"lockfileVersion": 1,
"dependencies": {
"ansi-regex": {
"version": "3.0.0",
"resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-3.
0.0.tgz",
"integrity": "sha1-7QMXwyIGT3lGbAKWa922Bas32Zg="
},
"cowsay": {
"version": "1.3.1",
"resolved": "https://registry.npmjs.org/cowsay/-/cowsay-1.3.1.tgz"
,
"integrity": "sha512-3PVFe6FePVtPj1HTeLin9v8WyLl+VmM1l1H/5P+BTTDkM
Ajufp+0F9eLjzRnOHzVAYeIYFF5po5NjRrgefnRMQ==",
"requires": {
"get-stdin": "^5.0.1",
"optimist": "~0.6.1",
"string-width": "~2.1.1",
"strip-eof": "^1.0.0"
}
},
"get-stdin": {
"version": "5.0.1",
"resolved": "https://registry.npmjs.org/get-stdin/-/get-stdin-5.0.
1.tgz",
"integrity": "sha1-Ei4WFZHiH/TFJTAwVpPyDmOTo5g="
},
"is-fullwidth-code-point": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/
is-fullwidth-code-point-2.0.0.tgz",
"integrity": "sha1-o7MKXE8ZkYMWeqq5O+764937ZU8="
},
"minimist": {
"version": "0.0.10",
"resolved": "https://registry.npmjs.org/minimist/-/minimist-0.0.10
.tgz",
"integrity": "sha1-3j+YVD2/lggr5IrRoMfNqDYwHc8="
},
"optimist": {
"version": "0.6.1",
"resolved": "https://registry.npmjs.org/optimist/-/optimist-0.6.1.tgz",
"integrity": "sha1-2j6nRob6IaGaERwybpDrFaAZZoY=",
"requires": {
"minimist": "~0.0.1",
"wordwrap": "~0.0.2"
}
},
"string-width": {
"version": "2.1.1",
"resolved": "https://registry.npmjs.org/string-width/-/string-width-2.1.1.tgz",
"integrity": "sha512-nOqH59deCq9SRHlxq1Aw85Jnt4w6KvLKqWVik6oA9ZklXLNIOlqg4F2yrT1MVaTjAqvVwdfeZ7w7aCvJD7ugkw==",
"requires": {
"is-fullwidth-code-point": "^2.0.0",
"strip-ansi": "^4.0.0"
}
},
"strip-ansi": {
"version": "4.0.0",
"resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-4.0.0.tgz",
"integrity": "sha1-qEeQIusaw2iocTibY1JixQXuNo8=",
"requires": {
"ansi-regex": "^3.0.0"
}
},
"strip-eof": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/strip-eof/-/strip-eof-1.0.0.tgz",
"integrity": "sha1-u0P/VZim6wXYm1n80SnJgzE2Br8="
},
"wordwrap": {
"version": "0.0.3",
"resolved": "https://registry.npmjs.org/wordwrap/-/wordwrap-0.0.3.tgz",
"integrity": "sha1-o9XabNXAvAAI03I0u68b7WMFkQc="
}
}
}
It can be easily observed that cowsay depends on get-stdin, optimist, string-width and strip-eof, these packages in turn depends on other packages as can be seen from the requires property that some have, ansi-regex, is-fullwidth-code-point, minimist, wordwrap, strip-eof.
These dependencies are added in alphabetical order into the file. Each has a version field, a resolved field that points to the package location and integrity string that can be used to verify the package.
Frequently Asked Questions
-
What is Package.json?
The package.json is actually a central repository for tool configuration. The file exists at the root of the JavaScript project and is used for managing the project dependencies, scripts, versions and a lot more.
-
What do you mean by semver notation for version number?
The package version follows the semver notation for versions, the version number is always expressed in the following format, x.x.x.
The first x is used to denote the major version, the second is used to denote the minor version and third one for the patch version.
Key Takeaways
The blog discussed the package.json file in detail. With this done you may now switch to explore web technologies from our blogs.
A common problem faced by all of us is that we prepare well, but during online assessments, we cannot solve the questions on time. To overcome this, Coding Ninjas have come up with an online mock test series. The mock tests for leading companies like Amazon, Microsoft, Google, Adobe, Flipkart, TCS, Wipro, and Accenture are free. Our team of experts has curated and designed these online mock test series to help you prepare better for your coding interview rounds. In this online test series, you will get multiple tests that include the latest coding interview questions. . Start preparing for the 2021 Amazon, Microsoft, etc., tech interviews now.
8+ registered 