NAME¶

.npmrc

Description¶

npm gets its config settings from the command line, environment variables, and npmrc files.

The npm config command can be used to update and edit the contents of the user and global npmrc files.

For a list of available configuration options, see config.

Files¶

The four relevant files are:

All npm config files are an ini-formatted list of key = value parameters.
Environment variables can be replaced using ${VARIABLE_NAME}.
By default if the variable is not defined, it is left unreplaced.
By adding ? after variable name they can be forced to evaluate to an empty string instead.
For example:

cache = ${HOME}/.npm-packages
node-options = "${NODE_OPTIONS?} --use-system-ca"

Each of these files is loaded, and config options are resolved in priority order.
For example, a setting in the userconfig file would override the setting in the globalconfig file.

Array values are specified by adding "[]" after the key name.
For example:

key[] = "first value"
key[] = "second value"

# last modified: 01 Jan 2016
; Set a new registry for a scoped package
@myscope:registry=https://mycustomregistry.example.org

Auth related configuration¶

The settings _auth, _authToken, username, _password, certfile, and keyfile must all be scoped to a specific registry.
This ensures that npm will never send credentials to the wrong host.

The full list is:

In order to scope these values, they must be prefixed by a URI fragment.
If the credential is meant for any request to a registry on a single host, the scope may look like //registry.npmjs.org/:.
If it must be scoped to a specific path on the host that path may also be provided, such as
//my-custom-registry.org/unique/path:.

Unsupported Custom Configuration Keys¶

Starting in npm v11.2.0, npm warns when unknown configuration keys are defined in .npmrc. In a future major version of npm, these unknown keys may no longer be accepted.

Only configuration keys that npm officially supports are recognized. Custom keys intended for third-party tools (for example, electron-builder) should not be placed in .npmrc.

If you need package-level configuration for use in scripts, use the config field in your package.json instead:

{


  "name": "my-package",


  "config": {


    "mirror": "https://example.com/"


  }
}

Values defined in package.json#config are exposed to scripts as environment variables prefixed with npm_package_config_. For example:

npm_package_config_mirror

If you need to pass arguments to a script command, use -- to separate npm arguments from script arguments:

npm run build -- --customFlag

Using environment variables is also recommended for cross-platform configuration instead of defining unsupported keys in .npmrc.

; bad config
_authToken=MYTOKEN
; good config
@myorg:registry=https://somewhere-else.com/myorg
@another:registry=https://somewhere-else.com/another
//registry.npmjs.org/:_authToken=MYTOKEN
; would apply to both @myorg and @another
//somewhere-else.com/:_authToken=MYTOKEN
; would apply only to @myorg
//somewhere-else.com/myorg/:_authToken=MYTOKEN1
; would apply only to @another
//somewhere-else.com/another/:_authToken=MYTOKEN2

Custom / third-party config keys¶

npm only recognizes its own configuration options.
If your .npmrc contains keys that are not part of npm's config definitions
(for example, electron_mirror or sass_binary_site), npm will emit a
warning:

warn Unknown user config "electron_mirror".
This will stop working in the next major version of npm.

These keys were historically tolerated but are not officially supported.
A future major version of npm will treat unknown top-level keys as errors.

Some tools (such as @electron/get or node-sass) read their own
configuration from environment variables or from .npmrc by convention.
You can set these values as environment variables instead:

export ELECTRON_MIRROR="https://mirrorexample.npmjs.org/mirrors/electron/"
export ELECTRON_CUSTOM_DIR="{{ version }}"

Environment variables are the most portable approach and work regardless
of .npmrc format.

See also¶