If you work with JS/TS then you are going to be very familiar with dependencies/devDependencies in your package.json.

As a quick reminder:

• "dependencies" are packages which are required by your application in production to run.
• "devDependencies" are other packages are only needed for local development (and testing)

But there are more than just dep/devDeps... In this page I'm going to quickly go over the less commonly used ones. They're not super obscure (especially peer dependencies), so you probably know about them. But anyway... here we go...

peerDependencies

Use peepDependencies when there are certain packages that your module requires, but aren't installed directly by your module.

Since npm v3, if they're not already installed (elsewhere in your app), it would give a warning message. Since v7 they're now automatically installed (in most cases)

{
  "name": "some-framework-plugin",
  "version": "2.3.4",
  "peerDependencies": {
    "some-framework": "2.x"
  }
}

This is useful if you have a plugin for a framework. Its going to assume the framework is installed, and you can add it as a peer dependency.

The benefit of this is that anything in peerDependencies don't need to be bundled in your package, but you can still specify a specific dependency (and version) that your module requires.

You can also use the peerDependenciesMeta option to mark some peer dependencies as optional.

optionalDependencies

This is like the name implies - its an optional dependency. If your package can use a dependency, but runs ok without it, then you can add it here.

If an optional dependency fails to install (e.g. if its just for certain operating systems), then the installation of the package will still continue without an error.

You can install packages in NPM without any of the optional deps with npm install --omit=optional

bundleDependencies

You can use this to list which packages are bundled with your package when you publish it.

A typical use case for bundleDependencies is if you are publishing a package that includes a package not available on the npm registry.

Then when a user installs your package, NPM does not need to go and download the packages included in the bundleDependencies list. You can also include packages in bundleDependencies that are only required for building (and its not needed in the published package)

You can also set the value of bundleDependencies to true, to bundle all dependencies, or false to bundle none.

Note: You can type it as bundledDependencies or bundleDependencies and it will work the same (in NPM)

versioning

• version Must match version exactly
• >version Must be greater than version
• >=version etc
• <version
• <=version
• ~version see section below on tilde ranges
• ^version See section below on carets 1.2.x 1.2.0, 1.2.1, etc., but not 1.3.0
• http://... pass in a url (not versioned)
• * Matches any version
• "" (just an empty string) Same as *
• version1 - version2 Same as >=version1 <=version2.
• range1 || range2 Passes if either range1 or range2 are satisfied.
• git... pass in a link to a git repo (not versioned like others)
• user/repo for github, similar to the git one above
• tag A specific version tagged and published as tag See npm dist-tag
• path/path/path local paths (not versioned)

tidle versions

These are versions such as ~1.2.3.

Allows patch-level changes, if a minor version is specified on the version. Allows minor-level changes if not.

• ~1.2.3 will match between >=1.2.3 and <1.3.0-0
• ~1.2 will match between >=1.2.0 and <1.3.0-0 (the same as 1.2.x)
• ~1 will match between >=1.0.0 and <2.0.0-0 (the same as 1.x)
• ~0.2.3 will match between >=0.2.3 and <0.3.0-0
• ~0.2 will match between >=0.2.0 and <0.3.0-0 (the same as 0.2.x)

caret versions

These are versions such as e.g. ^1.2.3

Allows patch and minor updates for versions 1.0.0 and above, patch updates for versions 0.X >=0.1.0, and no updates for versions 0.0.X.

Caret ranges are ideal when an author may make breaking changes between 0.2.4 and 0.3.0 releases, which is a common practice. However, it presumes that there will not be breaking changes between 0.2.4 and 0.2.5. It allows for changes that are presumed to be additive (but non-breaking), according to commonly observed practices.

Examples:

• ^1.2.3 will match verions between >=1.2.3 and <2.0.0-0
• ^0.2.3 will match verions between >=0.2.3 and <0.3.0-0
• ^0.0.3 will match verions between >=0.0.3 and <0.0.4-0
• ^1.x will match verions between >=1.0.0 and <2.0.0-0
• ^0.x will match verions between >=0.0.0 and <1.0.0-0