package.json

The name of the package.

Version must be parsable by node-semver, which is bundled with npm as a dependency.

This helps people discover your package, as it's listed in 'npm search'.

This helps people discover your package as it's listed in 'npm search'.

The url to the project homepage.

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.

DEPRECATED: Instead, use SPDX expressions, like this: { "license": "ISC" } or { "license": "(MIT OR Apache-2.0)" } see: 'https://docs.npmjs.com/files/package.json#license'.

A person who has been involved in creating or maintaining this package.

A list of people who contributed to this package.

A list of people who maintains this package.

The 'files' field is an array of files to include in your project. If you name a folder in the array, then it will also include the files inside that folder.

The main field is a module ID that is the primary entry point to your program.

The "exports" field is used to restrict external access to non-exported module files, also enables a module to import itself using "name".

The "imports" field is used to create private mappings that only apply to import specifiers from within the package itself.

When set to "module", the type field allows a package to specify all .js files within are ES modules. If the "type" field is omitted or set to "commonjs", all .js files are treated as CommonJS.

Set the types property to point to your bundled declaration file.

Note that the "typings" field is synonymous with "types", and could be used as well.

The "typesVersions" field is used since TypeScript 3.1 to support features that were only made available in newer TypeScript versions.

Specify either a single file or an array of filenames to put in place for the man program to find.

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

The 'scripts' member is an object hash of 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.

A 'config' hash can be used to set configuration parameters used in package scripts that persist across upgrades.

Dependencies are specified with a simple hash of package name to 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.

Specifies dependencies that are required for the development and testing of the project. These dependencies are not needed in the production environment.

Specifies dependencies that are optional for your project. These dependencies are attempted to be installed during the npm install process, but if they fail to install, the installation process will not fail.

Specifies dependencies that are required by the package but are expected to be provided by the consumer of the package.

When a user installs your package, warnings are emitted if packages specified in "peerDependencies" are not already installed. The "peerDependenciesMeta" field serves to provide more information on how your peer dependencies are utilized. Most commonly, it allows peer dependencies to be marked as optional. Metadata for this field is specified with a simple hash of the package name to a metadata object.

Array of package names that will be bundled when publishing the package.

DEPRECATED: This field is honored, but "bundleDependencies" is the correct field name.

Resolutions is used to support selective version resolutions using yarn, which lets you define custom package versions or ranges inside your dependencies. For npm, use overrides instead. See: https://yarnpkg.com/configuration/manifest#resolutions

Overrides is used to support selective version overrides using npm, which lets you define custom package versions or ranges inside your dependencies. For yarn, use resolutions instead. See: https://docs.npmjs.com/cli/v9/configuring-npm/package-json#overrides

Defines which package manager is expected to be used when working on the current project. This field is currently experimental and needs to be opted-in; see https://nodejs.org/api/corepack.html

Defines which tools and versions are expected to be used when Volta is installed.

Specify which operating systems your module will run on.

Specify that your code only runs on certain cpu architectures.

Define the runtime and package manager for developing the current project.

DEPRECATED: 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 set to true, then npm will refuse to publish it.

An ECMAScript module ID that is the primary entry point to your program.

A module ID with untranspiled code that is the primary entry point to your program.

Allows packages within a directory to depend on one another using direct linking of local files. Additionally, dependencies within a workspace are hoisted to the workspace root when possible to reduce duplication. Note: It's also a good idea to set "private" to true when using this feature.

Defines pnpm specific configuration.

Defines the StackBlitz configuration for the project.