Interface IPackageJson

Package author information. An author is one person.

• Shorthand expression

  your-name <account@your-domain> (http://your-url)

An executable file which will be installed into the PATH with a package install. npm will symlink that file into prefix/bin for global installs, or ./node_modules/.bin/ for local installs.

This is a hint to the module which is meant to be used "client-side" instead of "nodejs".

The url to your project's issue tracker and (or) the email address to which issues should be reported. These are helpful for people who encounter issues with your package.

Bundled dependencies are an array of package names that will be bundled together when publishing your package.

A "config" object can be used to set configuration parameters used in package scripts that persist across upgrades. For instance, if a package had the following:

{
  "config" : {
    "port" : "8080"
  }
}

and then had a "start" command that then referenced the npm_package_config_port environment variable, then the user could override that by doing npm config set foo:port 8001.

If there is an AUTHORS file in the root of your package, npm will treat each line as a Name (url) format, where email and url are optional. Lines which start with a # or are blank, will be ignored.

If your code only runs on certain cpu architectures, you can specify which ones. This checks against process.arch.

Dependencies are specified in a simple object that maps a package name to a version range. The version range is a string which has one or more space-separated descriptors. Dependencies can also be identified with a tarball or git URL.

A brief description of the package. By convention, the first sentence (up to the first ". ") should be usable as a package title in listings.

If someone is planning on downloading and using your module in their program, then they probably don't want or need to download and build the external test or documentation framework that you use. In this case, it's best to map these additional items in a devDependencies object.

You can specify exact locations to put binary files, man pages, documentation, examples, etc. Package manager tools must use these directory definitions to find various package components.

{
  "directories": {
    "lib": "path/to/lib/",
    "bin": "path/to/bin/",
    "man": "path/to/man/",
    "doc": "path/to/doc/",
    "example": "path/to/example/"
  }
}

You can specify the version of node that your stuff works on. You can also specify which versions of npm are capable of properly installing your program.

Files that are included in your project described as a glob pattern. Omitting the field will make it default to ["*"], as it will include all files.

If your package only allows one version of a given dependency, and you'd like to enforce the same behavior as yarn install --flat on the command line, set this to true.

The url to the project homepage.

An array of string keywords to assist users searching for the package in catalogs.

A license for your package so that people know how they are permitted to use it, and any restrictions you're placing on it. If you're using a common license such as BSD-2-Clause or MIT, add a current SPDX license identifier.

The main field is a module ID that is the primary entry point to your package. That is, if your package is named foo, and a user installs it, and then does require("foo"), then your main module's exports object will be returned. This should be a module ID relative to the root of your package folder. For most modules, it makes the most sense to have a main script and often not much else.

A single file (or an array of filenames) for the man program.

The name of your package. The name and version together should form a unique identifier accoss a project. The name and version fields are optional if you don't want to publish your package. A name can be optionally prefixed by a scope, e.g. @types/lodash.

If a dependency can be used, but you would like npm to proceed if it cannot be found or fails to install, then you may put it in the optionalDependencies object. This is a map of package name to version or url, just like the dependencies object. The difference is that build failures do not cause installation to fail. It is still your program's responsibility to handle the lack of the dependency.

You can specify which operating systems your module will run on

In some cases, you want to express the compatibility of your package with a host tool or library, while not necessarily doing a require of this host. This is usually referred to as a plugin. Notably, your module may be exposing a specific interface, expected and specified by the host documentation.

This option used to trigger an npm warning, but it will no longer warn. It is purely there for informational purposes. It is now recommended that you install any binaries as local devDependencies wherever possible.

If you set "private": true in your package.json, then npm will refuse to publish it. This is a way to prevent accidental publication of private repositories. If you would like to ensure that a given package is only ever published to a specific registry (for example, an internal registry), then use the publishConfig dictionary described below to override the registry config param at publish-time.

This is a set of config values that will be used at publish-time. It's especially handy if you want to set the tag, registry or access, so that you can ensure that a given package is not tagged with “latest”, published to the global public registry or that a scoped module is private by default. Any config values can be overridden, but only "tag", "registry" and "access" probably matter for the purposes of publishing. See npm-config to see the list of config options that can be overridden.

• Public Registry

Specify the place where your code lives. This is helpful for people who want to contribute.

Allows you to override a version of a particular nested dependency. See the Selective Versions Resolutions RFC for the full spec. Note that installing dependencies via [yarn install --flat] will automatically add a resolutions block to your package.json file.

The "scripts" property is a dictionary containing script commands that are run at various times in the lifecycle of your package. The key is the lifecycle event, and the value is the command to run at that point.

{
  "scripts": {
    "install": "install.js",
    "uninstall": "uninstall.js",
    "build": "build.js",
    "doc": "make-doc.js",
    "test": "test.js",
  }
}

Indicate the main declaration file in your package.json. Set the types property to point to your bundled declaration file.

{
  "name": "some-package",
  "version": "1.0.0",
  "main": "./lib/main.js",
  "types": "./lib/main.d.ts"
}

A version string conforming to the Semantic Versioning requirements.