server/sa-charts
14
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 1 Wiki Activity

swarm

Browse Source
This commit is contained in:
marsal wang
2023-07-26 10:07:34 +08:00
parent f884cb1020
commit 1e5a703cce
5384 changed files with 618283 additions and 4002 deletions
Download Patch File Download Diff File Expand all files Collapse all files

93
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-access.md generated vendored Normal file
View File

@ -0,0 +1,93 @@
---
section: cli-commands
title: npm-access
description: Set access level on published packages
---
# npm-access(1)
## Set access level on published packages
### Synopsis
```bash
npm access public [<package>]
npm access restricted [<package>]
npm access grant <read-only|read-write> <scope:team> [<package>]
npm access revoke <scope:team> [<package>]
npm access 2fa-required [<package>]
npm access 2fa-not-required [<package>]
npm access ls-packages [<user>|<scope>|<scope:team>]
npm access ls-collaborators [<package> [<user>]]
npm access edit [<package>]
```
### Description
Used to set access controls on private packages.
For all of the subcommands, `npm access` will perform actions on the packages
in the current working directory if no package name is passed to the
subcommand.
* public / restricted:
Set a package to be either publicly accessible or restricted.
* grant / revoke:
Add or remove the ability of users and teams to have read-only or read-write
access to a package.
* 2fa-required / 2fa-not-required:
Configure whether a package requires that anyone publishing it have two-factor
authentication enabled on their account.
* ls-packages:
Show all of the packages a user or a team is able to access, along with the
access level, except for read-only public packages (it won't print the whole
registry listing)
* ls-collaborators:
Show all of the access privileges for a package. Will only show permissions
for packages to which you have at least read access. If `<user>` is passed in,
the list is filtered only to teams _that_ user happens to belong to.
* edit:
Set the access privileges for a package at once using `$EDITOR`.
### Details
`npm access` always operates directly on the current registry, configurable
from the command line using `--registry=<registry url>`.
Unscoped packages are *always public*.
Scoped packages *default to restricted*, but you can either publish them as
public using `npm publish --access=public`, or set their access as public using
`npm access public` after the initial publish.
You must have privileges to set the access of a package:
* You are an owner of an unscoped or scoped package.
* You are a member of the team that owns a scope.
* You have been given read-write privileges for a package, either as a member
of a team or directly as an owner.
If you have two-factor authentication enabled then you'll have to pass in an
otp with `--otp` when making access changes.
If your account is not paid, then attempts to publish scoped packages will fail
with an HTTP 402 status code (logically enough), unless you use
`--access=public`.
Management of teams and team memberships is done with the `npm team` command.
### See Also
* [`libnpmaccess`](https://npm.im/libnpmaccess)
* [npm team](/cli-commands/npm-team)
* [npm publish](/cli-commands/npm-publish)
* [npm config](/cli-commands/npm-config)
* [npm registry](/using-npm/registry)

95
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-adduser.md generated vendored Normal file
View File

@ -0,0 +1,95 @@
---
section: cli-commands
title: npm-adduser
description: Set access level on published packages
---
# npm-adduser(1)
## Add a registry user account
### Synopsis
```bash
npm adduser [--registry=url] [--scope=@orgname] [--always-auth] [--auth-type=legacy]
aliases: login, add-user
```
### Description
Create or verify a user named `<username>` in the specified registry, and
save the credentials to the `.npmrc` file. If no registry is specified,
the default registry will be used (see [`config`](/using-npm/config)).
The username, password, and email are read in from prompts.
To reset your password, go to <https://www.npmjs.com/forgot>
To change your email address, go to <https://www.npmjs.com/email-edit>
You may use this command multiple times with the same user account to
authorize on a new machine. When authenticating on a new machine,
the username, password and email address must all match with
your existing record.
`npm login` is an alias to `adduser` and behaves exactly the same way.
### Configuration
#### registry
Default: https://registry.npmjs.org/
The base URL of the npm package registry. If `scope` is also specified,
this registry will only be used for packages with that scope. `scope` defaults
to the scope of the project directory you're currently in, if any. See [`scope`](/using-npm/scope).
#### scope
Default: none
If specified, the user and login credentials given will be associated
with the specified scope. See [`scope`](/using-npm/scope). You can use both at the same time,
e.g.
```bash
npm adduser --registry=http://myregistry.example.com --scope=@myco
```
This will set a registry for the given scope and login or create a user for
that registry at the same time.
#### always-auth
Default: false
If specified, save configuration indicating that all requests to the given
registry should include authorization information. Useful for private
registries. Can be used with `--registry` and / or `--scope`, e.g.
```bash
npm adduser --registry=http://private-registry.example.com --always-auth
```
This will ensure that all requests to that registry (including for tarballs)
include an authorization header. This setting may be necessary for use with
private registries where metadata and package tarballs are stored on hosts with
different hostnames. See `always-auth` in [`config`](/using-npm/config) for more details on always-auth. Registry-specific configuration of `always-auth` takes precedence over any global configuration.
#### auth-type
* Default: `'legacy'`
* Type: `'legacy'`, `'sso'`, `'saml'`, `'oauth'`
What authentication strategy to use with `adduser`/`login`. Some npm registries
(for example, npmE) might support alternative auth strategies besides classic
username/password entry in legacy npm.
### See Also
* [npm registry](/using-npm/registry)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [npm owner](/cli-commands/npm-owner)
* [npm whoami](/cli-commands/npm-whoami)

136
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-audit.md generated vendored Normal file
View File

@ -0,0 +1,136 @@
---
section: cli-commands
title: npm-audit
description: Run a security audit
---
# npm-audit(1)
## Run a security audit
### Synopsis
```bash
npm audit [--json|--parseable|--audit-level=(low|moderate|high|critical)]
npm audit fix [--force|--package-lock-only|--dry-run]
common options: [--production] [--only=(dev|prod)]
```
### Examples
Scan your project for vulnerabilities and automatically install any compatible
updates to vulnerable dependencies:
```bash
$ npm audit fix
```
Run `audit fix` without modifying `node_modules`, but still updating the
pkglock:
```bash
$ npm audit fix --package-lock-only
```
Skip updating `devDependencies`:
```bash
$ npm audit fix --only=prod
```
Have `audit fix` install semver-major updates to toplevel dependencies, not just
semver-compatible ones:
```bash
$ npm audit fix --force
```
Do a dry run to get an idea of what `audit fix` will do, and _also_ output
install information in JSON format:
```bash
$ npm audit fix --dry-run --json
```
Scan your project for vulnerabilities and just show the details, without fixing
anything:
```bash
$ npm audit
```
Get the detailed audit report in JSON format:
```bash
$ npm audit --json
```
Get the detailed audit report in plain text result, separated by tab characters, allowing for
future reuse in scripting or command line post processing, like for example, selecting
some of the columns printed:
```bash
$ npm audit --parseable
```
To parse columns, you can use for example `awk`, and just print some of them:
```bash
$ npm audit --parseable | awk -F $'\t' '{print $1,$4}'
```
Fail an audit only if the results include a vulnerability with a level of moderate or higher:
```bash
$ npm audit --audit-level=moderate
```
### Description
The audit command submits a description of the dependencies configured in
your project to your default registry and asks for a report of known
vulnerabilities. The report returned includes instructions on how to act on
this information. The command will exit with a 0 exit code if no
vulnerabilities were found.
You can also have npm automatically fix the vulnerabilities by running `npm
audit fix`. Note that some vulnerabilities cannot be fixed automatically and
will require manual intervention or review. Also note that since `npm audit fix`
runs a full-fledged `npm install` under the hood, all configs that apply to the
installer will also apply to `npm install` -- so things like `npm audit fix
--package-lock-only` will work as expected.
By default, the audit command will exit with a non-zero code if any vulnerability
is found. It may be useful in CI environments to include the `--audit-level` parameter
to specify the minimum vulnerability level that will cause the command to fail. This
option does not filter the report output, it simply changes the command's failure
threshold.
### Content Submitted
* npm_version
* node_version
* platform
* node_env
* A scrubbed version of your package-lock.json or npm-shrinkwrap.json
#### Scrubbing
In order to ensure that potentially sensitive information is not included in
the audit data bundle, some dependencies may have their names (and sometimes
versions) replaced with opaque non-reversible identifiers. It is done for
the following dependency types:
* Any module referencing a scope that is configured for a non-default
registry has its name scrubbed. (That is, a scope you did a `npm login --scope=@ourscope` for.)
* All git dependencies have their names and specifiers scrubbed.
* All remote tarball dependencies have their names and specifiers scrubbed.
* All local directory and tarball dependencies have their names and specifiers scrubbed.
The non-reversible identifiers are a sha256 of a session-specific UUID and the
value being replaced, ensuring a consistent value within the payload that is
different between runs.
### Exit Code
The `npm audit` command will exit with a 0 exit code if no vulnerabilities were found.
If vulnerabilities were found the exit code will depend on the `audit-level`
configuration setting.
### See Also
* [npm install](/cli-commands/npm-install)
* [package-locks](/configuring-npm/package-locks)
* [config](/using-npm/config)

26
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-bin.md generated vendored Normal file
View File

@ -0,0 +1,26 @@
---
section: cli-commands
title: npm-bin
description: Display npm bin folder
---
# npm-bin(1)
## Display npm bin folder
### Synopsis
```bash
npm bin [-g|--global]
```
### Description
Print the folder where npm will install executables.
### See Also
* [npm prefix](/cli-commands/npm-prefix)
* [npm root](/cli-commands/npm-root)
* [npm folders](/configuring-npm/folders)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)

50
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-bugs.md generated vendored Normal file
View File

@ -0,0 +1,50 @@
---
section: cli-commands
title: npm-bugs
description: Bugs for a package in a web browser maybe
---
# npm-bugs(1)
## Bugs for a package in a web browser maybe
### Synopsis
```bash
npm bugs [<pkgname>]
aliases: issues
```
### Description
This command tries to guess at the likely location of a package's
bug tracker URL, and then tries to open it using the `--browser`
config param. If no package name is provided, it will search for
a `package.json` in the current folder and use the `name` property.
### Configuration
#### browser
* Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
* Type: String
The browser that is called by the `npm bugs` command to open websites.
#### registry
* Default: https://registry.npmjs.org/
* Type: url
The base URL of the npm package registry.
### See Also
* [npm docs](/cli-commands/npm-docs)
* [npm view](/cli-commands/npm-view)
* [npm publish](/cli-commands/npm-publish)
* [npm registry](/using-npm/registry)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [package.json](/configuring-npm/package-json)

34
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-build.md generated vendored Normal file
View File

@ -0,0 +1,34 @@
---
section: cli-commands
title: npm-build
description: Build a package
---
# npm-build(1)
## Build a package
### Synopsis
```shell
npm build [<package-folder>]
```
* `<package-folder>`:
A folder containing a `package.json` file in its root.
### Description
This is the plumbing command called by `npm link` and `npm install`.
It should generally be called during installation, but if you need to run it
directly, run:
```bash
npm run-script build
```
### See Also
* [npm install](/cli-commands/npm-install)
* [npm link](/cli-commands/npm-link)
* [npm scripts](/using-npm/scripts)
* [package.json](/configuring-npm/package-json)

21
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-bundle.md generated vendored Normal file
View File

@ -0,0 +1,21 @@
---
section: cli-commands
title: npm-bundle
description: REMOVED
---
# npm-bundle(1)
## REMOVED
### Description
The `npm bundle` command has been removed in 1.0, for the simple reason
that it is no longer necessary, as the default behavior is now to
install packages into the local space.
Just use `npm install` now to do what `npm bundle` used to do.
### See Also
* [npm install](/cli-commands/npm-install)

91
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-cache.md generated vendored Normal file
View File

@ -0,0 +1,91 @@
---
section: cli-commands
title: npm-cache
description: Manipulates packages cache
---
# npm-cache(1)
## Manipulates packages cache
### Synopsis
```bash
npm cache add <tarball file>
npm cache add <folder>
npm cache add <tarball url>
npm cache add <name>@<version>
npm cache clean [<path>]
aliases: npm cache clear, npm cache rm
npm cache verify
```
### Description
Used to add, list, or clean the npm cache folder.
* add:
Add the specified package to the local cache. This command is primarily
intended to be used internally by npm, but it can provide a way to
add data to the local installation cache explicitly.
* clean:
Delete all data out of the cache folder.
* verify:
Verify the contents of the cache folder, garbage collecting any unneeded data,
and verifying the integrity of the cache index and all cached data.
### Details
npm stores cache data in an opaque directory within the configured `cache`,
named `_cacache`. This directory is a `cacache`-based content-addressable cache
that stores all http request data as well as other package-related data. This
directory is primarily accessed through `pacote`, the library responsible for
all package fetching as of npm@5.
All data that passes through the cache is fully verified for integrity on both
insertion and extraction. Cache corruption will either trigger an error, or
signal to `pacote` that the data must be refetched, which it will do
automatically. For this reason, it should never be necessary to clear the cache
for any reason other than reclaiming disk space, thus why `clean` now requires
`--force` to run.
There is currently no method exposed through npm to inspect or directly manage
the contents of this cache. In order to access it, `cacache` must be used
directly.
npm will not remove data by itself: the cache will grow as new packages are
installed.
### A note about the cache's design
The npm cache is strictly a cache: it should not be relied upon as a persistent
and reliable data store for package data. npm makes no guarantee that a
previously-cached piece of data will be available later, and will automatically
delete corrupted contents. The primary guarantee that the cache makes is that,
if it does return data, that data will be exactly the data that was inserted.
To run an offline verification of existing cache contents, use `npm cache
verify`.
### Configuration
#### cache
Default: `~/.npm` on Posix, or `%AppData%/npm-cache` on Windows.
The root cache folder.
### See Also
* [npm folders](/configuring-npm/folders)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [npm install](/cli-commands/npm-install)
* [npm publish](/cli-commands/npm-publish)
* [npm pack](/cli-commands/npm-pack)
* https://npm.im/cacache
* https://npm.im/pacote

67
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-ci.md generated vendored Normal file
View File

@ -0,0 +1,67 @@
---
section: cli-commands
title: npm-ci
description: Install a project with a clean slate
---
# npm-ci(1)
## Install a project with a clean slate
### Synopsis
```bash
npm ci
```
### Example
Make sure you have a package-lock and an up-to-date install:
```bash
$ cd ./my/npm/project
$ npm install
added 154 packages in 10s
$ ls | grep package-lock
```
Run `npm ci` in that project
```bash
$ npm ci
added 154 packages in 5s
```
Configure Travis to build using `npm ci` instead of `npm install`:
```bash
# .travis.yml
install:
- npm ci
# keep the npm cache around to speed up installs
cache:
directories:
- "$HOME/.npm"
```
### Description
This command is similar to [`npm install`](/cli-commands/npm-install), except it's meant to be used in
automated environments such as test platforms, continuous integration, and
deployment -- or any situation where you want to make sure you're doing a clean
install of your dependencies. It can be significantly faster than a regular npm
install by skipping certain user-oriented features. It is also more strict than
a regular install, which can help catch errors or inconsistencies caused by the
incrementally-installed local environments of most npm users.
In short, the main differences between using `npm install` and `npm ci` are:
* The project **must** have an existing `package-lock.json` or `npm-shrinkwrap.json`.
* If dependencies in the package lock do not match those in `package.json`, `npm ci` will exit with an error, instead of updating the package lock.
* `npm ci` can only install entire projects at a time: individual dependencies cannot be added with this command.
* If a `node_modules` is already present, it will be automatically removed before `npm ci` begins its install.
* It will never write to `package.json` or any of the package-locks: installs are essentially frozen.
### See Also
* [npm install](/cli-commands/npm-install)
* [package-locks](/configuring-npm/package-locks)

42
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-completion.md generated vendored Normal file
View File

@ -0,0 +1,42 @@
---
section: cli-commands
title: npm-completion
description: Tab Completion for npm
---
# npm-completion(1)
## Tab Completion for npm
### Synopsis
```bash
source <(npm completion)
```
### Description
Enables tab-completion in all npm commands.
The synopsis above
loads the completions into your current shell. Adding it to
your ~/.bashrc or ~/.zshrc will make the completions available
everywhere:
```bash
npm completion >> ~/.bashrc
npm completion >> ~/.zshrc
```
You may of course also pipe the output of `npm completion` to a file
such as `/usr/local/etc/bash_completion.d/npm` or
`/etc/bash_completion.d/npm` if you have a system that will read
that file for you.
When `COMP_CWORD`, `COMP_LINE`, and `COMP_POINT` are defined in the
environment, `npm completion` acts in "plumbing mode", and outputs
completions based on the arguments.
### See Also
* [npm developers](/using-npm/developers)
* [npm](/cli-commands/npm)

85
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-config.md generated vendored Normal file
View File

@ -0,0 +1,85 @@
---
section: cli-commands
title: npm-config
description: Manage the npm configuration files
---
# npm-config(1)
## Manage the npm configuration files
### Synopsis
```bash
npm config set <key> <value> [-g|--global]
npm config get <key>
npm config delete <key>
npm config list [-l] [--json]
npm config edit
npm get <key>
npm set <key> <value> [-g|--global]
aliases: c
```
### Description
npm gets its config settings from the command line, environment
variables, `npmrc` files, and in some cases, the `package.json` file.
See [npmrc](/configuring-npm/npmrc) for more information about the npmrc files.
See [config](/using-npm/config) for a more thorough discussion of the mechanisms
involved.
The `npm config` command can be used to update and edit the contents
of the user and global npmrc files.
### Sub-commands
Config supports the following sub-commands:
#### set
```bash
npm config set key value
```
Sets the config key to the value.
If value is omitted, then it sets it to "true".
#### get
```bash
npm config get key
```
Echo the config value to stdout.
#### list
```bash
npm config list
```
Show all the config settings. Use `-l` to also show defaults. Use `--json`
to show the settings in json format.
#### delete
```bash
npm config delete key
```
Deletes the key from all configuration files.
#### edit
```bash
npm config edit
```
Opens the config file in an editor. Use the `--global` flag to edit the
global config.
### See Also
* [npm folders](/configuring-npm/folders)
* [npm config](/cli-commands/npm-config)
* [package.json](/configuring-npm/package-json)
* [npmrc](/configuring-npm/npmrc)
* [npm](/cli-commands/npm)

67
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-dedupe.md generated vendored Normal file
View File

@ -0,0 +1,67 @@
---
section: cli-commands
title: npm-dedupe
description: Reduce duplication
---
# npm-dedupe(1)
## Reduce duplication
### Synopsis
```bash
npm dedupe
npm ddp
aliases: find-dupes, ddp
```
### Description
Searches the local package tree and attempts to simplify the overall
structure by moving dependencies further up the tree, where they can
be more effectively shared by multiple dependent packages.
For example, consider this dependency graph:
```bash
a
+-- b <-- depends on c@1.0.x
| `-- c@1.0.3
`-- d <-- depends on c@~1.0.9
`-- c@1.0.10
```
In this case, `npm dedupe` will transform the tree to:
```bash
a
+-- b
+-- d
`-- c@1.0.10
```
Because of the hierarchical nature of node's module lookup, b and d
will both get their dependency met by the single c package at the root
level of the tree.
The deduplication algorithm walks the tree, moving each dependency as far
up in the tree as possible, even if duplicates are not found. This will
result in both a flat and deduplicated tree.
If a suitable version exists at the target location in the tree
already, then it will be left untouched, but the other duplicates will
be deleted.
Arguments are ignored. Dedupe always acts on the entire tree.
Modules
Note that this operation transforms the dependency tree, but will never
result in new modules being installed.
### See Also
* [npm ls](/cli-commands/npm-ls)
* [npm update](/cli-commands/npm-update)
* [npm install](/cli-commands/npm-install)

36
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-deprecate.md generated vendored Normal file
View File

@ -0,0 +1,36 @@
---
section: cli-commands
title: npm-deprecate
description: Deprecate a version of a package
---
# npm-deprecate(1)
## Deprecate a version of a package
### Synopsis
```bash
npm deprecate <pkg>[@<version>] <message>
```
### Description
This command will update the npm registry entry for a package, providing
a deprecation warning to all who attempt to install it.
It works on [version ranges](https://semver.npmjs.com/) as well as specific
versions, so you can do something like this:
```bash
npm deprecate my-thing@"< 0.2.3" "critical bug fixed in v0.2.3"
```
Note that you must be the package owner to deprecate something. See the
`owner` and `adduser` help topics.
To un-deprecate a package, specify an empty string (`""`) for the `message`
argument. Note that you must use double quotes with no space between them to
format an empty string.
### See Also
* [npm publish](/cli-commands/npm-publish)
* [npm registry](/using-npm/registry)

100
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-dist-tag.md generated vendored Normal file
View File

@ -0,0 +1,100 @@
---
section: cli-commands
title: npm-dist-tag
description: Modify package distribution tags
---
# npm-dist-tag(1)
## Modify package distribution tags
### Synopsis
```bash
npm dist-tag add <pkg>@<version> [<tag>]
npm dist-tag rm <pkg> <tag>
npm dist-tag ls [<pkg>]
aliases: dist-tags
```
### Description
Add, remove, and enumerate distribution tags on a package:
* add:
Tags the specified version of the package with the specified tag, or the
`--tag` config if not specified. If you have two-factor authentication on
auth-and-writes then you’ll need to include a one-time password on the
command line with `--otp <one-time password>`.
* rm:
Clear a tag that is no longer in use from the package.
* ls:
Show all of the dist-tags for a package, defaulting to the package in
the current prefix. This is the default action if none is specified.
A tag can be used when installing packages as a reference to a version instead
of using a specific version number:
```bash
npm install <name>@<tag>
```
When installing dependencies, a preferred tagged version may be specified:
```bash
npm install --tag <tag>
```
This also applies to `npm dedupe`.
Publishing a package sets the `latest` tag to the published version unless the
`--tag` option is used. For example, `npm publish --tag=beta`.
By default, `npm install <pkg>` (without any `@<version>` or `@<tag>`
specifier) installs the `latest` tag.
### Purpose
Tags can be used to provide an alias instead of version numbers.
For example, a project might choose to have multiple streams of development
and use a different tag for each stream,
e.g., `stable`, `beta`, `dev`, `canary`.
By default, the `latest` tag is used by npm to identify the current version of
a package, and `npm install <pkg>` (without any `@<version>` or `@<tag>`
specifier) installs the `latest` tag. Typically, projects only use the `latest`
tag for stable release versions, and use other tags for unstable versions such
as prereleases.
The `next` tag is used by some projects to identify the upcoming version.
By default, other than `latest`, no tag has any special significance to npm
itself.
### Caveats
This command used to be known as `npm tag`, which only created new tags, and so
had a different syntax.
Tags must share a namespace with version numbers, because they are specified in
the same slot: `npm install <pkg>@<version>` vs `npm install <pkg>@<tag>`.
Tags that can be interpreted as valid semver ranges will be rejected. For
example, `v1.4` cannot be used as a tag, because it is interpreted by semver as
`>=1.4.0 <1.5.0`. See <https://github.com/npm/npm/issues/6082>.
The simplest way to avoid semver problems with tags is to use tags that do not
begin with a number or the letter `v`.
### See Also
* [npm publish](/cli-commands/npm-publish)
* [npm install](/cli-commands/npm-install)
* [npm dedupe](/cli-commands/npm-dedupe)
* [npm registry](/using-npm/registry)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)

52
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-docs.md generated vendored Normal file
View File

@ -0,0 +1,52 @@
---
section: cli-commands
title: npm-docs
description: Docs for a package in a web browser maybe
---
# npm-docs(1)
## Docs for a package in a web browser maybe
### Synopsis
```bash
npm docs [<pkgname> [<pkgname> ...]]
npm docs .
npm home [<pkgname> [<pkgname> ...]]
npm home .
```
### Description
This command tries to guess at the likely location of a package's
documentation URL, and then tries to open it using the `--browser`
config param. You can pass multiple package names at once. If no
package name is provided, it will search for a `package.json` in
the current folder and use the `name` property.
### Configuration
#### browser
* Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
* Type: String
The browser that is called by the `npm docs` command to open websites.
#### registry
* Default: https://registry.npmjs.org/
* Type: url
The base URL of the npm package registry.
### See Also
* [npm view](/cli-commands/npm-view)
* [npm publish](/cli-commands/npm-publish)
* [npm registry](/using-npm/registry)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [package.json](/configuring-npm/package-json)

111
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-doctor.md generated vendored Normal file
View File

@ -0,0 +1,111 @@
---
section: cli-commands
title: npm-doctor
description: Check your environments
---
# npm-doctor(1)
## Check your environments
### Synopsis
```bash
npm doctor
```
### Description
`npm doctor` runs a set of checks to ensure that your npm installation has
what it needs to manage your JavaScript packages. npm is mostly a standalone tool, but it does
have some basic requirements that must be met:
+ Node.js and git must be executable by npm.
+ The primary npm registry, `registry.npmjs.com`, or another service that uses
the registry API, is available.
+ The directories that npm uses, `node_modules` (both locally and globally),
exist and can be written by the current user.
+ The npm cache exists, and the package tarballs within it aren't corrupt.
Without all of these working properly, npm may not work properly. Many issues
are often attributable to things that are outside npm's code base, so `npm
doctor` confirms that the npm installation is in a good state.
Also, in addition to this, there are also very many issue reports due to using
old versions of npm. Since npm is constantly improving, running `npm@latest` is
better than an old version.
`npm doctor` verifies the following items in your environment, and if there are
any recommended changes, it will display them.
#### `npm ping`
By default, npm installs from the primary npm registry, `registry.npmjs.org`.
`npm doctor` hits a special ping endpoint within the registry. This can also be
checked with `npm ping`. If this check fails, you may be using a proxy that
needs to be configured, or may need to talk to your IT staff to get access over
HTTPS to `registry.npmjs.org`.
This check is done against whichever registry you've configured (you can see
what that is by running `npm config get registry`), and if you're using a
private registry that doesn't support the `/whoami` endpoint supported by the
primary registry, this check may fail.
#### `npm -v`
While Node.js may come bundled with a particular version of npm, it's the
policy of the CLI team that we recommend all users run `npm@latest` if they
can. As the CLI is maintained by a small team of contributors, there are only
resources for a single line of development, so npm's own long-term support
releases typically only receive critical security and regression fixes. The
team believes that the latest tested version of npm is almost always likely to
be the most functional and defect-free version of npm.
#### `node -v`
For most users, in most circumstances, the best version of Node will be the
latest long-term support (LTS) release. Those of you who want access to new
ECMAscript features or bleeding-edge changes to Node's standard library may be
running a newer version, and some of you may be required to run an older
version of Node because of enterprise change control policies. That's OK! But
in general, the npm team recommends that most users run Node.js LTS.
#### `npm config get registry`
Some of you may be installing from private package registries for your project
or company. That's great! Others of you may be following tutorials or
StackOverflow questions in an effort to troubleshoot problems you may be
having. Sometimes, this may entail changing the registry you're pointing at.
This part of `npm doctor` just lets you, and maybe whoever's helping you with
support, know that you're not using the default registry.
#### `which git`
While it's documented in the README, it may not be obvious that npm needs Git
installed to do many of the things that it does. Also, in some cases
– especially on Windows – you may have Git set up in such a way that it's not
accessible via your `PATH` so that npm can find it. This check ensures that Git
is available.
#### Permissions checks
* Your cache must be readable and writable by the user running npm.
* Global package binaries must be writable by the user running npm.
* Your local `node_modules` path, if you're running `npm doctor` with a project
directory, must be readable and writable by the user running npm.
#### Validate the checksums of cached packages
When an npm package is published, the publishing process generates a checksum
that npm uses at install time to verify that the package didn't get corrupted
in transit. `npm doctor` uses these checksums to validate the package tarballs
in your local cache (you can see where that cache is located with `npm config
get cache`, and see what's in that cache with `npm cache ls` – probably more
than you were expecting!). In the event that there are corrupt packages in your
cache, you should probably run `npm cache clean` and reset the cache.
### See Also
* [npm bugs](/cli-commands/npm-bugs)
* [npm help](/cli-commands/npm-help)
* [npm ping](/cli-commands/npm-ping)

47
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-edit.md generated vendored Normal file
View File

@ -0,0 +1,47 @@
---
section: cli-commands
title: npm-edit
description: Edit an installed package
---
# npm-edit(1)
## Edit an installed package
### Synopsis
```bash
npm edit <pkg>[/<subpkg>...]
```
### Description
Selects a (sub)dependency in the current
working directory and opens the package folder in the default editor
(or whatever you've configured as the npm `editor` config -- see
[`npm-config`](npm-config).)
After it has been edited, the package is rebuilt so as to pick up any
changes in compiled packages.
For instance, you can do `npm install connect` to install connect
into your package, and then `npm edit connect` to make a few
changes to your locally installed copy.
### Configuration
#### editor
* Default: `EDITOR` environment variable if set, or `"vi"` on Posix,
or `"notepad"` on Windows.
* Type: path
The command to run for `npm edit` or `npm config edit`.
### See Also
* [npm folders](/configuring-npm/folders)
* [npm explore](/cli-commands/npm-explore)
* [npm install](/cli-commands/npm-install)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)

50
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-explore.md generated vendored Normal file
View File

@ -0,0 +1,50 @@
---
section: cli-commands
title: npm-explore
description: Browse an installed package
---
# npm-explore(1)
## Browse an installed package
### Synopsis
```bash
npm explore <pkg> [ -- <command>]
```
### Description
Spawn a subshell in the directory of the installed package specified.
If a command is specified, then it is run in the subshell, which then
immediately terminates.
This is particularly handy in the case of git submodules in the
`node_modules` folder:
```bash
npm explore some-dependency -- git pull origin master
```
Note that the package is *not* automatically rebuilt afterwards, so be
sure to use `npm rebuild <pkg>` if you make any changes.
### Configuration
#### shell
* Default: SHELL environment variable, or "bash" on Posix, or "cmd" on
Windows
* Type: path
The shell to run for the `npm explore` command.
### See Also
* [npm folders](/configuring-npm/folders)
* [npm edit](/cli-commands/npm-edit)
* [npm rebuild](/cli-commands/npm-rebuild)
* [npm build](/cli-commands/npm-build)
* [npm install](/cli-commands/npm-install)

68
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-fund.md generated vendored Normal file
View File

@ -0,0 +1,68 @@
---
section: cli-commands
title: npm-fund
description: Retrieve funding information
---
# npm-fund(1)
## Retrieve funding information
### Synopsis
```bash
npm fund [<pkg>]
```
### Description
This command retrieves information on how to fund the dependencies of
a given project. If no package name is provided, it will list all
dependencies that are looking for funding in a tree-structure in which
are listed the type of funding and the url to visit. If a package name
is provided then it tries to open its funding url using the `--browser`
config param; if there are multiple funding sources for the package, the
user will be instructed to pass the `--which` command to disambiguate.
The list will avoid duplicated entries and will stack all packages
that share the same type/url as a single entry. Given this nature the
list is not going to have the same shape of the output from `npm ls`.
### Configuration
#### browser
* Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
* Type: String
The browser that is called by the `npm fund` command to open websites.
#### json
* Type: Boolean
* Default: false
Show information in JSON format.
#### unicode
* Type: Boolean
* Default: true
Whether to represent the tree structure using unicode characters.
Set it to `false` in order to use all-ansi output.
#### which
* Type: Number
* Default: undefined
If there are multiple funding sources, which 1-indexed source URL to open.
## See Also
* [npm docs](/cli-commands/npm-docs)
* [npm config](/cli-commands/npm-config)
* [npm install](/cli-commands/npm-install)
* [npm ls](/cli-commands/npm-ls)

43
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-help-search.md generated vendored Normal file
View File

@ -0,0 +1,43 @@
---
section: cli-commands
title: npm-help-search
description: Search npm help documentation
---
# npm-help-search(1)
## Search npm help documentation
### Synopsis
```bash
npm help-search <text>
```
### Description
This command will search the npm markdown documentation files for the
terms provided, and then list the results, sorted by relevance.
If only one result is found, then it will show that help topic.
If the argument to `npm help` is not a known help topic, then it will
call `help-search`. It is rarely if ever necessary to call this
command directly.
### Configuration
#### long
* Type: Boolean
* Default: false
If true, the "long" flag will cause help-search to output context around
where the terms were found in the documentation.
If false, then help-search will just list out the help topics found.
### See Also
* [npm](/cli-commands/npm)
* [npm help](/cli-commands/npm-help)

44
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-help.md generated vendored Normal file
View File

@ -0,0 +1,44 @@
---
section: cli-commands
title: npm-help
description: Get help on npm
---
# npm-help(1)
## Get help on npm
### Synopsis
```bash
npm help <term> [<terms..>]
```
### Description
If supplied a topic, then show the appropriate documentation page.
If the topic does not exist, or if multiple terms are provided, then run
the `help-search` command to find a match. Note that, if `help-search`
finds a single subject, then it will run `help` on that topic, so unique
matches are equivalent to specifying a topic name.
### Configuration
#### viewer
* Default: "man" on Posix, "browser" on Windows
* Type: path
The program to use to view help content.
Set to `"browser"` to view html help content in the default web browser.
### See Also
* [npm](/cli-commands/npm)
* [npm folders](/configuring-npm/folders)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [package.json](/configuring-npm/package-json)
* [npm help-search](/cli-commands/npm-help-search)

80
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-hook.md generated vendored Normal file
View File

@ -0,0 +1,80 @@
---
section: cli-commands
title: npm-hook
description: Manage registry hooks
---
# npm-hook(1)
## Manage registry hooks
### Synopsis
```bash
npm hook ls [pkg]
npm hook add <entity> <url> <secret>
npm hook update <id> <url> [secret]
npm hook rm <id>
```
### Example
Add a hook to watch a package for changes:
```bash
$ npm hook add lodash https://example.com/ my-shared-secret
```
Add a hook to watch packages belonging to the user `substack`:
```bash
$ npm hook add ~substack https://example.com/ my-shared-secret
```
Add a hook to watch packages in the scope `@npm`
```bash
$ npm hook add @npm https://example.com/ my-shared-secret
```
List all your active hooks:
```bash
$ npm hook ls
```
List your active hooks for the `lodash` package:
```bash
$ npm hook ls lodash
```
Update an existing hook's url:
```bash
$ npm hook update id-deadbeef https://my-new-website.here/
```
Remove a hook:
```bash
$ npm hook rm id-deadbeef
```
### Description
Allows you to manage [npm hooks](https://blog.npmjs.org/post/145260155635/introducing-hooks-get-notifications-of-npm),
including adding, removing, listing, and updating.
Hooks allow you to configure URL endpoints that will be notified whenever a
change happens to any of the supported entity types. Three different types of
entities can be watched by hooks: packages, owners, and scopes.
To create a package hook, simply reference the package name.
To create an owner hook, prefix the owner name with `~` (as in, `~youruser`).
To create a scope hook, prefix the scope name with `@` (as in, `@yourscope`).
The hook `id` used by `update` and `rm` are the IDs listed in `npm hook ls` for
that particular hook.
The shared secret will be sent along to the URL endpoint so you can verify the
request came from your own configured hook.
### See Also
* ["Introducing Hooks" blog post](https://blog.npmjs.org/post/145260155635/introducing-hooks-get-notifications-of-npm)

74
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-init.md generated vendored Normal file
View File

@ -0,0 +1,74 @@
---
section: cli-commands
title: npm-init
description: create a package.json file
---
# npm-init(1)
## create a package.json file
### Synopsis
```bash
npm init [--force|-f|--yes|-y|--scope]
npm init <@scope> (same as `npx <@scope>/create`)
npm init [<@scope>/]<name> (same as `npx [<@scope>/]create-<name>`)
```
### Examples
Create a new React-based project using [`create-react-app`](https://npm.im/create-react-app):
```bash
$ npm init react-app ./my-react-app
```
Create a new `esm`-compatible package using [`create-esm`](https://npm.im/create-esm):
```bash
$ mkdir my-esm-lib && cd my-esm-lib
$ npm init esm --yes
```
Generate a plain old package.json using legacy init:
```bash
$ mkdir my-npm-pkg && cd my-npm-pkg
$ git init
$ npm init
```
Generate it without having it ask any questions:
```bash
$ npm init -y
```
### Description
`npm init <initializer>` can be used to set up a new or existing npm package.
`initializer` in this case is an npm package named `create-<initializer>`, which
will be installed by [`npx`](https://npm.im/npx), and then have its main bin
executed -- presumably creating or updating `package.json` and running any other
initialization-related operations.
The init command is transformed to a corresponding `npx` operation as follows:
* `npm init foo` -> `npx create-foo`
* `npm init @usr/foo` -> `npx @usr/create-foo`
* `npm init @usr` -> `npx @usr/create`
Any additional options will be passed directly to the command, so `npm init foo
--hello` will map to `npx create-foo --hello`.
If the initializer is omitted (by just calling `npm init`), init will fall back
to legacy init behavior. It will ask you a bunch of questions, and then write a
package.json for you. It will attempt to make reasonable guesses based on
existing fields, dependencies, and options selected. It is strictly additive, so
it will keep any fields and values that were already set. You can also use
`-y`/`--yes` to skip the questionnaire altogether. If you pass `--scope`, it
will create a scoped package.
### See Also
* <https://github.com/isaacs/init-package-json>
* [package.json](/configuring-npm/package-json)
* [npm version](/cli-commands/npm-version)
* [npm scope](/using-npm/scope)

26
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-install-ci-test.md generated vendored Normal file
View File

@ -0,0 +1,26 @@
---
section: cli-commands
title: npm-install-ci-test
description: Install a project with a clean slate and run tests
---
# npm install-ci-test(1)
## Install a project with a clean slate and run tests
### Synopsis
```bash
npm install-ci-test
alias: npm cit
```
### Description
This command runs an `npm ci` followed immediately by an `npm test`.
### See Also
* [npm ci](/cli-commands/npm-ci)
* [npm test](/cli-commands/npm-test)

35
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-install-test.md generated vendored Normal file
View File

@ -0,0 +1,35 @@
---
section: cli-commands
title: npm-install-test
description: Install package(s) and run tests
---
# npm install-test(1)
## Install package(s) and run tests
### Synopsis
```bash
npm install-test (with no args, in package dir)
npm install-test [<@scope>/]<name>
npm install-test [<@scope>/]<name>@<tag>
npm install-test [<@scope>/]<name>@<version>
npm install-test [<@scope>/]<name>@<version range>
npm install-test <tarball file>
npm install-test <tarball url>
npm install-test <folder>
alias: npm it
common options: [--save|--save-dev|--save-optional] [--save-exact] [--dry-run]
```
### Description
This command runs an `npm install` followed immediately by an `npm test`. It
takes exactly the same arguments as `npm install`.
### See Also
* [npm install](/cli-commands/npm-install)
* [npm test](/cli-commands/npm-test)

519
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-install.md generated vendored Normal file
View File

@ -0,0 +1,519 @@
---
section: cli-commands
title: npm-install
description: Install a package
---
# npm-install(1)
## Install a package
### Synopsis
```bash
npm install (with no args, in package dir)
npm install [<@scope>/]<name>
npm install [<@scope>/]<name>@<tag>
npm install [<@scope>/]<name>@<version>
npm install [<@scope>/]<name>@<version range>
npm install <alias>@npm:<name>
npm install <git-host>:<git-user>/<repo-name>
npm install <git repo url>
npm install <tarball file>
npm install <tarball url>
npm install <folder>
aliases: npm i, npm add
common options: [-P|--save-prod|-D|--save-dev|-O|--save-optional] [-E|--save-exact] [-B|--save-bundle] [--no-save] [--dry-run]
```
### Description
This command installs a package, and any packages that it depends on. If the
package has a package-lock or shrinkwrap file, the installation of dependencies
will be driven by that, with an `npm-shrinkwrap.json` taking precedence if both
files exist. See [package-lock.json](/configuring-npm/package-lock-json) and [`npm shrinkwrap`](/cli-commands/npm-shrinkwrap).
A `package` is:
* a) a folder containing a program described by a [`package.json`](/configuring-npm/package-json) file
* b) a gzipped tarball containing (a)
* c) a url that resolves to (b)
* d) a `<name>@<version>` that is published on the registry (see [`registry`](/using-npm/registry)) with (c)
* e) a `<name>@<tag>` (see [`npm dist-tag`](/cli-commands/npm-dist-tag)) that points to (d)
* f) a `<name>` that has a "latest" tag satisfying (e)
* g) a `<git remote url>` that resolves to (a)
Even if you never publish your package, you can still get a lot of
benefits of using npm if you just want to write a node program (a), and
perhaps if you also want to be able to easily install it elsewhere
after packing it up into a tarball (b).
* `npm install` (in package directory, no arguments):
Install the dependencies in the local node_modules folder.
In global mode (ie, with `-g` or `--global` appended to the command),
it installs the current package context (ie, the current working
directory) as a global package.
By default, `npm install` will install all modules listed as dependencies
in [`package.json`](/configuring-npm/package-json).
With the `--production` flag (or when the `NODE_ENV` environment variable
is set to `production`), npm will not install modules listed in
`devDependencies`. To install all modules listed in both `dependencies`
and `devDependencies` when `NODE_ENV` environment variable is set to `production`,
you can use `--production=false`.
> NOTE: The `--production` flag has no particular meaning when adding a
dependency to a project.
* `npm install <folder>`:
Install the package in the directory as a symlink in the current project.
Its dependencies will be installed before it's linked. If `<folder>` sits
inside the root of your project, its dependencies may be hoisted to the
toplevel `node_modules` as they would for other types of dependencies.
* `npm install <tarball file>`:
Install a package that is sitting on the filesystem. Note: if you just want
to link a dev directory into your npm root, you can do this more easily by
using `npm link`.
Tarball requirements:
* The filename *must* use `.tar`, `.tar.gz`, or `.tgz` as
the extension.
* The package contents should reside in a subfolder inside the tarball (usually it is called `package/`). npm strips one directory layer when installing the package (an equivalent of `tar x --strip-components=1` is run).
* The package must contain a `package.json` file with `name` and `version` properties.
Example:
npm install ./package.tgz
* `npm install <tarball url>`:
Fetch the tarball url, and then install it. In order to distinguish between
this and other options, the argument must start with "http://" or "https://"
Example:
npm install https://github.com/indexzero/forever/tarball/v0.5.6
* `npm install [<@scope>/]<name>`:
Do a `<name>@<tag>` install, where `<tag>` is the "tag" config. (See
[`config`](/using-npm/config). The config's default value is `latest`.)
In most cases, this will install the version of the modules tagged as
`latest` on the npm registry.
Example:
npm install sax
* `npm install <alias>@npm:<name>`:
Install a package under a custom alias. Allows multiple versions of
a same-name package side-by-side, more convenient import names for
packages with otherwise long ones and using git forks replacements
or forked npm packages as replacements. Aliasing works only on your
project and does not rename packages in transitive dependencies.
Aliases should follow the naming conventions stated in
[`validate-npm-package-name`](https://www.npmjs.com/package/validate-npm-package-name#naming-rules).
Examples:
npm install my-react@npm:react
npm install jquery2@npm:jquery@2
npm install jquery3@npm:jquery@3
npm install npa@npm:npm-package-arg
`npm install` saves any specified packages into `dependencies` by default.
Additionally, you can control where and how they get saved with some
additional flags:
* `-P, --save-prod`: Package will appear in your `dependencies`. This is the
default unless `-D` or `-O` are present.
* `-D, --save-dev`: Package will appear in your `devDependencies`.
* `-O, --save-optional`: Package will appear in your `optionalDependencies`.
* `--no-save`: Prevents saving to `dependencies`.
When using any of the above options to save dependencies to your
package.json, there are two additional, optional flags:
* `-E, --save-exact`: Saved dependencies will be configured with an
exact version rather than using npm's default semver range
operator.
* `-B, --save-bundle`: Saved dependencies will also be added to your `bundleDependencies` list.
Further, if you have an `npm-shrinkwrap.json` or `package-lock.json` then it
will be updated as well.
`<scope>` is optional. The package will be downloaded from the registry
associated with the specified scope. If no registry is associated with
the given scope the default registry is assumed. See [`scope`](/using-npm/scope).
Note: if you do not include the @-symbol on your scope name, npm will
interpret this as a GitHub repository instead, see below. Scopes names
must also be followed by a slash.
Examples:
```bash
npm install sax
npm install githubname/reponame
npm install @myorg/privatepackage
npm install node-tap --save-dev
npm install dtrace-provider --save-optional
npm install readable-stream --save-exact
npm install ansi-regex --save-bundle
```
**Note**: If there is a file or folder named `<name>` in the current
working directory, then it will try to install that, and only try to
fetch the package by name if it is not valid.
* `npm install [<@scope>/]<name>@<tag>`:
Install the version of the package that is referenced by the specified tag.
If the tag does not exist in the registry data for that package, then this
will fail.
Example:
```bash
npm install sax@latest
npm install @myorg/mypackage@latest
```
* `npm install [<@scope>/]<name>@<version>`:
Install the specified version of the package. This will fail if the
version has not been published to the registry.
Example:
```bash
npm install sax@0.1.1
npm install @myorg/privatepackage@1.5.0
```
* `npm install [<@scope>/]<name>@<version range>`:
Install a version of the package matching the specified version range. This
will follow the same rules for resolving dependencies described in [`package.json`](/configuring-npm/package-json).
Note that most version ranges must be put in quotes so that your shell will
treat it as a single argument.
Example:
```bash
npm install sax@">=0.1.0 <0.2.0"
npm install @myorg/privatepackage@">=0.1.0 <0.2.0"
```
* `npm install <git remote url>`:
Installs the package from the hosted git provider, cloning it with `git`.
For a full git remote url, only that URL will be attempted.
```bash
<protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish> | #semver:<semver>]
```
`<protocol>` is one of `git`, `git+ssh`, `git+http`, `git+https`, or
`git+file`.
If `#<commit-ish>` is provided, it will be used to clone exactly that
commit. If the commit-ish has the format `#semver:<semver>`, `<semver>` can
be any valid semver range or exact version, and npm will look for any tags
or refs matching that range in the remote repository, much as it would for a
registry dependency. If neither `#<commit-ish>` or `#semver:<semver>` is
specified, then the default branch of the repository is used.
If the repository makes use of submodules, those submodules will be cloned
as well.
If the package being installed contains a `prepare` script, its
`dependencies` and `devDependencies` will be installed, and the prepare
script will be run, before the package is packaged and installed.
The following git environment variables are recognized by npm and will be
added to the environment when running git:
* `GIT_ASKPASS`
* `GIT_EXEC_PATH`
* `GIT_PROXY_COMMAND`
* `GIT_SSH`
* `GIT_SSH_COMMAND`
* `GIT_SSL_CAINFO`
* `GIT_SSL_NO_VERIFY`
See the git man page for details.
Examples:
```bash
npm install git+ssh://git@github.com:npm/cli.git#v1.0.27
npm install git+ssh://git@github.com:npm/cli#semver:^5.0
npm install git+https://isaacs@github.com/npm/cli.git
npm install git://github.com/npm/cli.git#v1.0.27
GIT_SSH_COMMAND='ssh -i ~/.ssh/custom_ident' npm install git+ssh://git@github.com:npm/cli.git
```
* `npm install <githubname>/<githubrepo>[#<commit-ish>]`:
* `npm install github:<githubname>/<githubrepo>[#<commit-ish>]`:
Install the package at `https://github.com/githubname/githubrepo` by
attempting to clone it using `git`.
If `#<commit-ish>` is provided, it will be used to clone exactly that
commit. If the commit-ish has the format `#semver:<semver>`, `<semver>` can
be any valid semver range or exact version, and npm will look for any tags
or refs matching that range in the remote repository, much as it would for a
registry dependency. If neither `#<commit-ish>` or `#semver:<semver>` is
specified, then `master` is used.
As with regular git dependencies, `dependencies` and `devDependencies` will
be installed if the package has a `prepare` script, before the package is
done installing.
Examples:
```bash
npm install mygithubuser/myproject
npm install github:mygithubuser/myproject
```
* `npm install gist:[<githubname>/]<gistID>[#<commit-ish>|#semver:<semver>]`:
Install the package at `https://gist.github.com/gistID` by attempting to
clone it using `git`. The GitHub username associated with the gist is
optional and will not be saved in `package.json`.
As with regular git dependencies, `dependencies` and `devDependencies` will
be installed if the package has a `prepare` script, before the package is
done installing.
Example:
```bash
npm install gist:101a11beef
```
* `npm install bitbucket:<bitbucketname>/<bitbucketrepo>[#<commit-ish>]`:
Install the package at `https://bitbucket.org/bitbucketname/bitbucketrepo`
by attempting to clone it using `git`.
If `#<commit-ish>` is provided, it will be used to clone exactly that
commit. If the commit-ish has the format `#semver:<semver>`, `<semver>` can
be any valid semver range or exact version, and npm will look for any tags
or refs matching that range in the remote repository, much as it would for a
registry dependency. If neither `#<commit-ish>` or `#semver:<semver>` is
specified, then `master` is used.
As with regular git dependencies, `dependencies` and `devDependencies` will
be installed if the package has a `prepare` script, before the package is
done installing.
Example:
```bash
npm install bitbucket:mybitbucketuser/myproject
```
* `npm install gitlab:<gitlabname>/<gitlabrepo>[#<commit-ish>]`:
Install the package at `https://gitlab.com/gitlabname/gitlabrepo`
by attempting to clone it using `git`.
If `#<commit-ish>` is provided, it will be used to clone exactly that
commit. If the commit-ish has the format `#semver:<semver>`, `<semver>` can
be any valid semver range or exact version, and npm will look for any tags
or refs matching that range in the remote repository, much as it would for a
registry dependency. If neither `#<commit-ish>` or `#semver:<semver>` is
specified, then `master` is used.
As with regular git dependencies, `dependencies` and `devDependencies` will
be installed if the package has a `prepare` script, before the package is
done installing.
Example:
```bash
npm install gitlab:mygitlabuser/myproject
npm install gitlab:myusr/myproj#semver:^5.0
```
You may combine multiple arguments, and even multiple types of arguments.
For example:
```bash
npm install sax@">=0.1.0 <0.2.0" bench supervisor
```
The `--tag` argument will apply to all of the specified install targets. If a
tag with the given name exists, the tagged version is preferred over newer
versions.
The `--dry-run` argument will report in the usual way what the install would
have done without actually installing anything.
The `--package-lock-only` argument will only update the `package-lock.json`,
instead of checking `node_modules` and downloading dependencies.
The `-f` or `--force` argument will force npm to fetch remote resources even if a
local copy exists on disk.
```bash
npm install sax --force
```
The `--no-fund` argument will hide the message displayed at the end of each
install that acknowledges the number of dependencies looking for funding.
See `npm-fund(1)`
The `-g` or `--global` argument will cause npm to install the package globally
rather than locally. See [folders](/configuring-npm/folders).
The `--global-style` argument will cause npm to install the package into
your local `node_modules` folder with the same layout it uses with the
global `node_modules` folder. Only your direct dependencies will show in
`node_modules` and everything they depend on will be flattened in their
`node_modules` folders. This obviously will eliminate some deduping.
The `--ignore-scripts` argument will cause npm to not execute any
scripts defined in the package.json. See [`scripts`](/using-npm/scripts).
The `--legacy-bundling` argument will cause npm to install the package such
that versions of npm prior to 1.4, such as the one included with node 0.8,
can install the package. This eliminates all automatic deduping.
The `--link` argument will cause npm to link global installs into the
local space in some cases.
The `--no-bin-links` argument will prevent npm from creating symlinks for
any binaries the package might contain.
The `--no-optional` argument will prevent optional dependencies from
being installed.
The `--no-shrinkwrap` argument, which will ignore an available
package lock or shrinkwrap file and use the package.json instead.
The `--no-package-lock` argument will prevent npm from creating a
`package-lock.json` file. When running with package-lock's disabled npm
will not automatically prune your node modules when installing.
The `--nodedir=/path/to/node/source` argument will allow npm to find the
node source code so that npm can compile native modules.
The `--only={prod[uction]|dev[elopment]}` argument will cause either only
`devDependencies` or only non-`devDependencies` to be installed regardless of the `NODE_ENV`.
The `--no-audit` argument can be used to disable sending of audit reports to
the configured registries. See [`npm-audit`](npm-audit) for details on what is sent.
See [`config`](/using-npm/config). Many of the configuration params have some
effect on installation, since that's most of what npm does.
#### Algorithm
To install a package, npm uses the following algorithm:
```bash
load the existing node_modules tree from disk
clone the tree
fetch the package.json and assorted metadata and add it to the clone
walk the clone and add any missing dependencies
dependencies will be added as close to the top as is possible
without breaking any other modules
compare the original tree with the cloned tree and make a list of
actions to take to convert one to the other
execute all of the actions, deepest first
kinds of actions are install, update, remove and move
```
For this `package{dep}` structure: `A{B,C}, B{C}, C{D}`,
this algorithm produces:
```bash
A
+-- B
+-- C
+-- D
```
That is, the dependency from B to C is satisfied by the fact that A
already caused C to be installed at a higher level. D is still installed
at the top level because nothing conflicts with it.
For `A{B,C}, B{C,D@1}, C{D@2}`, this algorithm produces:
```bash
A
+-- B
+-- C
`-- D@2
+-- D@1
```
Because B's D@1 will be installed in the top level, C now has to install D@2
privately for itself. This algorithm is deterministic, but different trees may
be produced if two dependencies are requested for installation in a different
order.
See [folders](/configuring-npm/folders) for a more detailed description of the specific folder structures that npm creates.
### Limitations of npm's Install Algorithm
npm will refuse to install any package with an identical name to the
current package. This can be overridden with the `--force` flag, but in
most cases can simply be addressed by changing the local package name.
There are some very rare and pathological edge-cases where a cycle can
cause npm to try to install a never-ending tree of packages. Here is
the simplest case:
```bash
A -> B -> A' -> B' -> A -> B -> A' -> B' -> A -> ...
```
where `A` is some version of a package, and `A'` is a different version
of the same package. Because `B` depends on a different version of `A`
than the one that is already in the tree, it must install a separate
copy. The same is true of `A'`, which must install `B'`. Because `B'`
depends on the original version of `A`, which has been overridden, the
cycle falls into infinite regress.
To avoid this situation, npm flat-out refuses to install any
`name@version` that is already present anywhere in the tree of package
folder ancestors. A more correct, but more complex, solution would be
to symlink the existing version into the new location. If this ever
affects a real use-case, it will be investigated.
### See Also
* [npm folders](/configuring-npm/folders)
* [npm update](/cli-commands/npm-update)
* [npm audit](/cli-commands/npm-audit)
* [npm fund](/cli-commands/npm-fund)
* [npm link](/cli-commands/npm-link)
* [npm rebuild](/cli-commands/npm-rebuild)
* [npm scripts](/using-npm/scripts)
* [npm build](/cli-commands/npm-build)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [npm registry](/using-npm/registry)
* [npm dist-tag](/cli-commands/npm-dist-tag)
* [npm uninstall](/cli-commands/npm-uninstall)
* [npm shrinkwrap](/cli-commands/npm-shrinkwrap)
* [package.json](/configuring-npm/package-json)

92
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-link.md generated vendored Normal file
View File

@ -0,0 +1,92 @@
---
section: cli-commands
title: npm-link
description: Symlink a package folder
---
# npm-link(1)
## Symlink a package folder
### Synopsis
```bash
npm link (in package dir)
npm link [<@scope>/]<pkg>[@<version>]
alias: npm ln
```
### Description
Package linking is a two-step process.
First, `npm link` in a package folder will create a symlink in the global folder
`{prefix}/lib/node_modules/<package>` that links to the package where the `npm
link` command was executed. It will also link any bins in the package to `{prefix}/bin/{name}`.
Note that `npm link` uses the global prefix (see `npm prefix -g` for its value).
Next, in some other location, `npm link package-name` will create a
symbolic link from globally-installed `package-name` to `node_modules/`
of the current folder.
Note that `package-name` is taken from `package.json`,
not from directory name.
The package name can be optionally prefixed with a scope. See [`scope`](/using-npm/npm-scope).
The scope must be preceded by an @-symbol and followed by a slash.
When creating tarballs for `npm publish`, the linked packages are
"snapshotted" to their current state by resolving the symbolic links.
This is handy for installing your own stuff, so that you can work on it and
test it iteratively without having to continually rebuild.
For example:
```bash
cd ~/projects/node-redis # go into the package directory
npm link # creates global link
cd ~/projects/node-bloggy # go into some other package directory.
npm link redis # link-install the package
```
Now, any changes to ~/projects/node-redis will be reflected in
~/projects/node-bloggy/node_modules/node-redis/. Note that the link should
be to the package name, not the directory name for that package.
You may also shortcut the two steps in one. For example, to do the
above use-case in a shorter way:
```bash
cd ~/projects/node-bloggy # go into the dir of your main project
npm link ../node-redis # link the dir of your dependency
```
The second line is the equivalent of doing:
```bash
(cd ../node-redis; npm link)
npm link redis
```
That is, it first creates a global link, and then links the global
installation target into your project's `node_modules` folder.
Note that in this case, you are referring to the directory name, `node-redis`,
rather than the package name `redis`.
If your linked package is scoped (see [`scope`](/using-npm/npm-scope)) your link command must include that scope, e.g.
```bash
npm link @myorg/privatepackage
```
### See Also
* [npm developers](/using-npm/developers)
* [package.json](/configuring-npm/package-json)
* [npm install](/cli-commands/npm-install)
* [npm folders](/configuring-npm/folders)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)

54
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-logout.md generated vendored Normal file
View File

@ -0,0 +1,54 @@
---
section: cli-commands
title: npm-logout
description: Log out of the registry
---
# npm-logout(1)
## Log out of the registry
### Synopsis
```bash
npm logout [--registry=<url>] [--scope=<@scope>]
```
### Description
When logged into a registry that supports token-based authentication, tell the
server to end this token's session. This will invalidate the token everywhere
you're using it, not just for the current environment.
When logged into a legacy registry that uses username and password authentication, this will
clear the credentials in your user configuration. In this case, it will _only_ affect
the current environment.
If `--scope` is provided, this will find the credentials for the registry
connected to that scope, if set.
### Configuration
#### registry
Default: https://registry.npmjs.org/
The base URL of the npm package registry. If `scope` is also specified,
it takes precedence.
#### scope
Default: The scope of your current project, if any, otherwise none.
If specified, you will be logged out of the specified scope. See [`scope`](/using-npm/npm-scope).
```bash
npm logout --scope=@myco
```
### See Also
* [npm adduser](/cli-commands/npm-adduser)
* [npm registry](/using-npm/registry)
* [npm config](/cli-commands/npm-config)
* [npm whoami](/cli-commands/npm-whoami)

129
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-ls.md generated vendored Normal file
View File

@ -0,0 +1,129 @@
---
section: cli-commands
title: npm-ls
description: List installed packages
---
# npm-ls(1)
## List installed packages
### Synopsis
```bash
npm ls [[<@scope>/]<pkg> ...]
aliases: list, la, ll
```
### Description
This command will print to stdout all the versions of packages that are
installed, as well as their dependencies, in a tree-structure.
Positional arguments are `name@version-range` identifiers, which will
limit the results to only the paths to the packages named. Note that
nested packages will *also* show the paths to the specified packages.
For example, running `npm ls promzard` in npm's source tree will show:
```bash
npm@@VERSION@ /path/to/npm
└─┬ init-package-json@0.0.4
└── promzard@0.1.5
```
It will print out extraneous, missing, and invalid packages.
If a project specifies git urls for dependencies these are shown
in parentheses after the name@version to make it easier for users to
recognize potential forks of a project.
The tree shown is the logical dependency tree, based on package
dependencies, not the physical layout of your node_modules folder.
When run as `ll` or `la`, it shows extended information by default.
### Configuration
#### json
* Default: false
* Type: Boolean
Show information in JSON format.
#### long
* Default: false
* Type: Boolean
Show extended information.
#### parseable
* Default: false
* Type: Boolean
Show parseable output instead of tree view.
#### global
* Default: false
* Type: Boolean
List packages in the global install prefix instead of in the current
project.
#### depth
* Type: Int
Max display depth of the dependency tree.
#### prod / production
* Type: Boolean
* Default: false
Display only the dependency tree for packages in `dependencies`.
#### dev / development
* Type: Boolean
* Default: false
Display only the dependency tree for packages in `devDependencies`.
#### only
* Type: String
When "dev" or "development", is an alias to `dev`.
When "prod" or "production", is an alias to `production`.
#### link
* Type: Boolean
* Default: false
Display only dependencies which are linked
#### unicode
* Type: Boolean
* Default: true
Whether to represent the tree structure using unicode characters.
Set it to false in order to use all-ansi output.
### See Also
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [npm folders](/configuring-npm/folders)
* [npm install](/cli-commands/npm-install)
* [npm link](/cli-commands/npm-link)
* [npm prune](/cli-commands/npm-prune)
* [npm outdated](/cli-commands/npm-outdated)
* [npm update](/cli-commands/npm-update)

65
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-org.md generated vendored Normal file
View File

@ -0,0 +1,65 @@
---
section: cli-commands
title: npm-org
description: Manage orgs
---
# npm-org(1)
## Manage orgs
### Synopsis
```bash
npm org set <orgname> <username> [developer | admin | owner]
npm org rm <orgname> <username>
npm org ls <orgname> [<username>]
```
### Example
Add a new developer to an org:
```bash
$ npm org set my-org @mx-smith
```
Add a new admin to an org (or change a developer to an admin):
```bash
$ npm org set my-org @mx-santos admin
```
Remove a user from an org:
```bash
$ npm org rm my-org mx-santos
```
List all users in an org:
```bash
$ npm org ls my-org
```
List all users in JSON format:
```bash
$ npm org ls my-org --json
```
See what role a user has in an org:
```bash
$ npm org ls my-org @mx-santos
```
### Description
You can use the `npm org` commands to manage and view users of an organization.
It supports adding and removing users, changing their roles, listing them, and
finding specific ones and their roles.
### See Also
* [Documentation on npm Orgs](https://docs.npmjs.com/orgs/)

124
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-outdated.md generated vendored Normal file
View File

@ -0,0 +1,124 @@
---
section: cli-commands
title: npm-outdated
description: Check for outdated packages
---
# npm-outdated(1)
## Check for outdated packages
### Synopsis
```bash
npm outdated [[<@scope>/]<pkg> ...]
```
### Description
This command will check the registry to see if any (or, specific) installed
packages are currently outdated.
In the output:
* `wanted` is the maximum version of the package that satisfies the semver
range specified in `package.json`. If there's no available semver range (i.e.
you're running `npm outdated --global`, or the package isn't included in
`package.json`), then `wanted` shows the currently-installed version.
* `latest` is the version of the package tagged as latest in the registry.
Running `npm publish` with no special configuration will publish the package
with a dist-tag of `latest`. This may or may not be the maximum version of
the package, or the most-recently published version of the package, depending
on how the package's developer manages the latest [dist-tag](npm-dist-tag).
* `location` is where in the dependency tree the package is located. Note that
`npm outdated` defaults to a depth of 0, so unless you override that, you'll
always be seeing only top-level dependencies that are outdated.
* `package type` (when using `--long` / `-l`) tells you whether this package is
a `dependency` or a `devDependency`. Packages not included in `package.json`
are always marked `dependencies`.
* `homepage` (when using `--long` / `-l`) is the `homepage` value contained in the package's `package.json`
* Red means there's a newer version matching your semver requirements, so you should update now.
* Yellow indicates that there's a newer version above your semver requirements (usually new major, or new 0.x minor) so proceed with caution.
### An example
```bash
$ npm outdated
Package Current Wanted Latest Location
glob 5.0.15 5.0.15 6.0.1 test-outdated-output
nothingness 0.0.3 git git test-outdated-output
npm 3.5.1 3.5.2 3.5.1 test-outdated-output
local-dev 0.0.3 linked linked test-outdated-output
once 1.3.2 1.3.3 1.3.3 test-outdated-output
```
With these `dependencies`:
```json
{
"glob": "^5.0.15",
"nothingness": "github:othiym23/nothingness#master",
"npm": "^3.5.1",
"once": "^1.3.1"
}
```
A few things to note:
* `glob` requires `^5`, which prevents npm from installing `glob@6`, which is
outside the semver range.
* Git dependencies will always be reinstalled, because of how they're specified.
The installed committish might satisfy the dependency specifier (if it's
something immutable, like a commit SHA), or it might not, so `npm outdated` and
`npm update` have to fetch Git repos to check. This is why currently doing a
reinstall of a Git dependency always forces a new clone and install.
* `npm@3.5.2` is marked as "wanted", but "latest" is `npm@3.5.1` because npm
uses dist-tags to manage its `latest` and `next` release channels. `npm update`
will install the _newest_ version, but `npm install npm` (with no semver range)
will install whatever's tagged as `latest`.
* `once` is just plain out of date. Reinstalling `node_modules` from scratch or
running `npm update` will bring it up to spec.
### Configuration
#### json
* Default: false
* Type: Boolean
Show information in JSON format.
#### long
* Default: false
* Type: Boolean
Show extended information.
#### parseable
* Default: false
* Type: Boolean
Show parseable output instead of tree view.
#### global
* Default: false
* Type: Boolean
Check packages in the global install prefix instead of in the current
project.
#### depth
* Default: 0
* Type: Int
Max depth for checking dependency tree.
### See Also
* [npm update](/cli-commands/npm-update)
* [npm dist-tag](/cli-commands/npm-dist-tag)
* [npm registry](/using-npm/registry)
* [npm folders](/configuring-npm/folders)

47
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-owner.md generated vendored Normal file
View File

@ -0,0 +1,47 @@
---
section: cli-commands
title: npm-owner
description: Manage package owners
---
# npm-owner(1)
## Manage package owners
### Synopsis
```bash
npm owner add <user> [<@scope>/]<pkg>
npm owner rm <user> [<@scope>/]<pkg>
npm owner ls [<@scope>/]<pkg>
aliases: author
```
### Description
Manage ownership of published packages.
* ls:
List all the users who have access to modify a package and push new versions.
Handy when you need to know who to bug for help.
* add:
Add a new user as a maintainer of a package. This user is enabled to modify
metadata, publish new versions, and add other owners.
* rm:
Remove a user from the package owner list. This immediately revokes their
privileges.
Note that there is only one level of access. Either you can modify a package,
or you can't. Future versions may contain more fine-grained access levels, but
that is not implemented at this time.
If you have two-factor authentication enabled with `auth-and-writes` then
you'll need to include an otp on the command line when changing ownership
with `--otp`.
### See Also
* [npm publish](/cli-commands/npm-publish)
* [npm registry](/using-npm/registry)
* [npm adduser](/cli-commands/npm-adduser)
* [npm disputes](/using-npm/disputes)

38
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-pack.md generated vendored Normal file
View File

@ -0,0 +1,38 @@
---
section: cli-commands
title: npm-pack
description: Create a tarball from a package
---
# npm-pack(1)
## Create a tarball from a package
### Synopsis
```bash
npm pack [[<@scope>/]<pkg>...] [--dry-run]
```
### Description
For anything that's installable (that is, a package folder, tarball,
tarball url, name@tag, name@version, name, or scoped name), this
command will fetch it to the cache, and then copy the tarball to the
current working directory as `<name>-<version>.tgz`, and then write
the filenames out to stdout.
If the same package is specified multiple times, then the file will be
overwritten the second time.
If no arguments are supplied, then npm packs the current package folder.
The `--dry-run` argument will do everything that pack usually does without
actually packing anything. Reports on what would have gone into the tarball.
### See Also
* [npm cache](/cli-commands/npm-cache)
* [npm publish](/cli-commands/npm-publish)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)

33
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-ping.md generated vendored Normal file
View File

@ -0,0 +1,33 @@
---
section: cli-commands
title: npm-ping
description: Ping npm registry
---
# npm-ping(1)
## Ping npm registry
### Synopsis
```bash
npm ping [--registry <registry>]
```
### Description
Ping the configured or given npm registry and verify authentication.
If it works it will output something like:
```bash
Ping success: {*Details about registry*}
```
otherwise you will get:
```bash
Ping error: {*Detail about error}
```
### See Also
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)

32
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-prefix.md generated vendored Normal file
View File

@ -0,0 +1,32 @@
---
section: cli-commands
title: npm-prefix
description: Display prefix
---
# npm-prefix(1)
## Display prefix
### Synopsis
```bash
npm prefix [-g]
```
### Description
Print the local prefix to standard out. This is the closest parent directory
to contain a `package.json` file or `node_modules` directory, unless `-g` is
also specified.
If `-g` is specified, this will be the value of the global prefix. See
[`npm config`](/cli-commands/npm-config) for more detail.
### See Also
* [npm root](/cli-commands/npm-root)
* [npm bin](/cli-commands/npm-bin)
* [npm folders](/configuring-npm/folders)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)

82
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-profile.md generated vendored Normal file
View File

@ -0,0 +1,82 @@
---
section: cli-commands
title: npm-profile
description: Change settings on your registry profile
---
# npm-profile(1)
## Change settings on your registry profile
### Synopsis
```bash
npm profile get [--json|--parseable] [<property>]
npm profile set [--json|--parseable] <property> <value>
npm profile set password
npm profile enable-2fa [auth-and-writes|auth-only]
npm profile disable-2fa
```
### Description
Change your profile information on the registry. This not be available if
you're using a non-npmjs registry.
* `npm profile get [<property>]`:
Display all of the properties of your profile, or one or more specific
properties. It looks like:
```bash
+-----------------+---------------------------+
| name | example |
+-----------------+---------------------------+
| email | me@example.com (verified) |
+-----------------+---------------------------+
| two factor auth | auth-and-writes |
+-----------------+---------------------------+
| fullname | Example User |
+-----------------+---------------------------+
| homepage | |
+-----------------+---------------------------+
| freenode | |
+-----------------+---------------------------+
| twitter | |
+-----------------+---------------------------+
| github | |
+-----------------+---------------------------+
| created | 2015-02-26T01:38:35.892Z |
+-----------------+---------------------------+
| updated | 2017-10-02T21:29:45.922Z |
+-----------------+---------------------------+
```
* `npm profile set <property> <value>`:
Set the value of a profile property. You can set the following properties this way:
email, fullname, homepage, freenode, twitter, github
* `npm profile set password`:
Change your password. This is interactive, you'll be prompted for your
current password and a new password. You'll also be prompted for an OTP
if you have two-factor authentication enabled.
* `npm profile enable-2fa [auth-and-writes|auth-only]`:
Enables two-factor authentication. Defaults to `auth-and-writes` mode. Modes are:
* `auth-only`: Require an OTP when logging in or making changes to your
account's authentication. The OTP will be required on both the website
and the command line.
* `auth-and-writes`: Requires an OTP at all the times `auth-only` does, and also requires one when
publishing a module, setting the `latest` dist-tag, or changing access
via `npm access` and `npm owner`.
* `npm profile disable-2fa`:
Disables two-factor authentication.
### Details
All of the `npm profile` subcommands accept `--json` and `--parseable` and
will tailor their output based on those. Some of these commands may not be
available on non npmjs.com registries.
### See Also
* [npm config](/cli-commands/npm-config)

46
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-prune.md generated vendored Normal file
View File

@ -0,0 +1,46 @@
---
section: cli-commands
title: npm-prune
description: Remove extraneous packages
---
# npm-prune(1)
## Remove extraneous packages
### Synopsis
```bash
npm prune [[<@scope>/]<pkg>...] [--production] [--dry-run] [--json]
```
### Description
This command removes "extraneous" packages. If a package name is
provided, then only packages matching one of the supplied names are
removed.
Extraneous packages are packages that are not listed on the parent
package's dependencies list.
If the `--production` flag is specified or the `NODE_ENV` environment
variable is set to `production`, this command will remove the packages
specified in your `devDependencies`. Setting `--no-production` will
negate `NODE_ENV` being set to `production`.
If the `--dry-run` flag is used then no changes will actually be made.
If the `--json` flag is used then the changes `npm prune` made (or would
have made with `--dry-run`) are printed as a JSON object.
In normal operation with package-locks enabled, extraneous modules are
pruned automatically when modules are installed and you'll only need
this command with the `--production` flag.
If you've disabled package-locks then extraneous modules will not be removed
and it's up to you to run `npm prune` from time-to-time to remove them.
### See Also
* [npm uninstall](/cli-commands/npm-uninstall)
* [npm folders](/configuring-npm/folders)
* [npm ls](/cli-commands/npm-ls)

81
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-publish.md generated vendored Normal file
View File

@ -0,0 +1,81 @@
---
section: cli-commands
title: npm-publish
description: Publish a package
---
# npm-publish(1)
## Publish a package
### Synopsis
```bash
npm publish [<tarball>|<folder>] [--tag <tag>] [--access <public|restricted>] [--otp otpcode] [--dry-run]
Publishes '.' if no argument supplied
Sets tag 'latest' if no --tag specified
```
### Description
Publishes a package to the registry so that it can be installed by name. All
files in the package directory are included if no local `.gitignore` or
`.npmignore` file exists. If both files exist and a file is ignored by
`.gitignore` but not by `.npmignore` then it will be included. See
[`developers`](/using-npm/developers) for full details on what's included in the published package, as well as details on how the package is built.
By default npm will publish to the public registry. This can be overridden by
specifying a different default registry or using a [`scope`](/using-npm/npm-scope) in the name (see [`package.json`](/configuring-npm/package-json)).
* `<folder>`:
A folder containing a package.json file
* `<tarball>`:
A url or file path to a gzipped tar archive containing a single folder
with a package.json file inside.
* `[--tag <tag>]`
Registers the published package with the given tag, such that `npm install
<name>@<tag>` will install this version. By default, `npm publish` updates
and `npm install` installs the `latest` tag. See [`npm-dist-tag`](npm-dist-tag) for
details about tags.
* `[--access <public|restricted>]`
Tells the registry whether this package should be published as public or
restricted. Only applies to scoped packages, which default to `restricted`.
If you don't have a paid account, you must publish with `--access public`
to publish scoped packages.
* `[--otp <otpcode>]`
If you have two-factor authentication enabled in `auth-and-writes` mode
then you can provide a code from your authenticator with this. If you
don't include this and you're running from a TTY then you'll be prompted.
* `[--dry-run]`
As of `npm@6`, does everything publish would do except actually publishing
to the registry. Reports the details of what would have been published.
Fails if the package name and version combination already exists in
the specified registry.
Once a package is published with a given name and version, that
specific name and version combination can never be used again, even if
it is removed with [`npm unpublish`](/cli-commands/npm-unpublish).
As of `npm@5`, both a sha1sum and an integrity field with a sha512sum of the
tarball will be submitted to the registry during publication. Subsequent
installs will use the strongest supported algorithm to verify downloads.
Similar to `--dry-run` see [`npm pack`](/cli-commands/npm-pack), which figures out the files to be
included and packs them into a tarball to be uploaded to the registry.
### See Also
* [npm registry](/using-npm/registry)
* [npm scope](/using-npm/scope)
* [npm adduser](/cli-commands/adduser)
* [npm owner](/cli-commands/owner)
* [npm deprecate](/cli-commands/deprecate)
* [npm dist-tag](/cli-commands/dist-tag)
* [npm pack](/cli-commands/pack)
* [npm profile](/cli-commands/profile)

26
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-rebuild.md generated vendored Normal file
View File

@ -0,0 +1,26 @@
---
section: cli-commands
title: npm-rebuild
description: Rebuild a package
---
# npm-rebuild(1)
## Rebuild a package
### Synopsis
```bash
npm rebuild [[<@scope>/<name>]...]
alias: npm rb
```
### Description
This command runs the `npm build` command on the matched folders. This is useful when you install a new version of node, and must recompile all your C++ addons with the new binary.
### See Also
* [npm build](/cli-commands/npm-build)
* [npm install](/cli-commands/npm-install)

36
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-repo.md generated vendored Normal file
View File

@ -0,0 +1,36 @@
---
section: cli-commands
title: npm-repo
description: Open package repository page in the browser
---
# npm-repo(1)
## Open package repository page in the browser
### Synopsis
```bash
npm repo [<pkg>]
```
### Description
This command tries to guess at the likely location of a package's
repository URL, and then tries to open it using the `--browser`
config param. If no package name is provided, it will search for
a `package.json` in the current folder and use the `name` property.
### Configuration
#### browser
* Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
* Type: String
The browser that is called by the `npm repo` command to open websites.
### See Also
* [npm docs](/cli-commands/npm-docs)
* [npm config](/cli-commands/npm-config)

49
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-restart.md generated vendored Normal file
View File

@ -0,0 +1,49 @@
---
section: cli-commands
title: npm-restart
description: Restart a package
---
# npm-restart(1)
## Restart a package
### Synopsis
```bash
npm restart [-- <args>]
```
### Description
This restarts a package.
This runs a package's "stop", "restart", and "start" scripts, and associated
pre- and post- scripts, in the order given below:
1. prerestart
2. prestop
3. stop
4. poststop
5. restart
6. prestart
7. start
8. poststart
9. postrestart
### Note
Note that the "restart" script is run **in addition to** the "stop"
and "start" scripts, not instead of them.
This is the behavior as of `npm` major version 2. A change in this
behavior will be accompanied by an increase in major version number
### See Also
* [npm run-script](/cli-commands/npm-run-script)
* [npm scripts](/using-npm/scripts)
* [npm test](/cli-commands/npm-test)
* [npm start](/cli-commands/npm-start)
* [npm stop](/cli-commands/npm-stop)
* [npm restart](/cli-commands/npm-restart)

26
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-root.md generated vendored Normal file
View File

@ -0,0 +1,26 @@
---
section: cli-commands
title: npm-root
description: Display npm root
---
# npm-root(1)
## Display npm root
### Synopsis
```bash
npm root [-g]
```
### Description
Print the effective `node_modules` folder to standard out.
### See Also
* [npm prefix](/cli-commands/npm-prefix)
* [npm bin](/cli-commands/npm-bin)
* [npm folders](/configuring-npm/folders)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)

97
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-run-script.md generated vendored Normal file
View File

@ -0,0 +1,97 @@
---
section: cli-commands
title: npm-run-script
description: Run arbitrary package scripts
---
# npm-run-script(1)
## Run arbitrary package scripts
### Synopsis
```bash
npm run-script <command> [--silent] [-- <args>...]
alias: npm run
```
### Description
This runs an arbitrary command from a package's `"scripts"` object. If no
`"command"` is provided, it will list the available scripts. `run[-script]` is
used by the test, start, restart, and stop commands, but can be called
directly, as well. When the scripts in the package are printed out, they're
separated into lifecycle (test, start, restart) and directly-run scripts.
As of [`npm@2.0.0`](https://blog.npmjs.org/post/98131109725/npm-2-0-0), you can
use custom arguments when executing scripts. The special option `--` is used by
[getopt](https://goo.gl/KxMmtG) to delimit the end of the options. npm will pass
all the arguments after the `--` directly to your script:
```bash
npm run test -- --grep="pattern"
```
The arguments will only be passed to the script specified after ```npm run```
and not to any pre or post script.
The `env` script is a special built-in command that can be used to list
environment variables that will be available to the script at runtime. If an
"env" command is defined in your package, it will take precedence over the
built-in.
In addition to the shell's pre-existing `PATH`, `npm run` adds
`node_modules/.bin` to the `PATH` provided to scripts. Any binaries provided by
locally-installed dependencies can be used without the `node_modules/.bin`
prefix. For example, if there is a `devDependency` on `tap` in your package,
you should write:
```bash
"scripts": {"test": "tap test/\*.js"}
```
instead of
```bash
"scripts": {"test": "node_modules/.bin/tap test/\*.js"}
```
to run your tests.
The actual shell your script is run within is platform dependent. By default,
on Unix-like systems it is the `/bin/sh` command, on Windows it is the `cmd.exe`.
The actual shell referred to by `/bin/sh` also depends on the system.
As of [`npm@5.1.0`](https://github.com/npm/npm/releases/tag/v5.1.0) you can
customize the shell with the `script-shell` configuration.
Scripts are run from the root of the module, regardless of what your current
working directory is when you call `npm run`. If you want your script to
use different behavior based on what subdirectory you're in, you can use the
`INIT_CWD` environment variable, which holds the full path you were in when
you ran `npm run`.
`npm run` sets the `NODE` environment variable to the `node` executable with
which `npm` is executed. Also, if the `--scripts-prepend-node-path` is passed,
the directory within which `node` resides is added to the
`PATH`. If `--scripts-prepend-node-path=auto` is passed (which has been the
default in `npm` v3), this is only performed when that `node` executable is
not found in the `PATH`.
If you try to run a script without having a `node_modules` directory and it fails,
you will be given a warning to run `npm install`, just in case you've forgotten.
You can use the `--silent` flag to prevent showing `npm ERR!` output on error.
You can use the `--if-present` flag to avoid exiting with a non-zero exit code
when the script is undefined. This lets you run potentially undefined scripts
without breaking the execution chain.
### See Also
* [npm scripts](/using-npm/scripts)
* [npm test](/cli-commands/npm-test)
* [npm start](/cli-commands/npm-start)
* [npm restart](/cli-commands/npm-restart)
* [npm stop](/cli-commands/npm-stop)
* [npm config](/cli-commands/npm-config)

114
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-search.md generated vendored Normal file
View File

@ -0,0 +1,114 @@
---
section: cli-commands
title: npm-search
description: Search for packages
---
# npm-search(1)
## Search for packages
### Synopsis
```bash
npm search [-l|--long] [--json] [--parseable] [--no-description] [search terms ...]
aliases: s, se, find
```
### Description
Search the registry for packages matching the search terms. `npm search`
performs a linear, incremental, lexically-ordered search through package
metadata for all files in the registry. If color is enabled, it will further
highlight the matches in the results.
Additionally, using the `--searchopts` and `--searchexclude` options paired with
more search terms will respectively include and exclude further patterns. The
main difference between `--searchopts` and the standard search terms is that the
former does not highlight results in the output and can be used for more
fine-grained filtering. Additionally, both of these can be added to `.npmrc` for
default search filtering behavior.
Search also allows targeting of maintainers in search results, by prefixing
their npm username with `=`.
If a term starts with `/`, then it's interpreted as a regular expression and
supports standard JavaScript RegExp syntax. A trailing `/` will be ignored in
this case. (Note that many regular expression characters must be escaped or
quoted in most shells.)
### A Note on caching
### Configuration
#### description
* Default: true
* Type: Boolean
Used as `--no-description`, disables search matching in package descriptions and
suppresses display of that field in results.
#### json
* Default: false
* Type: Boolean
Output search results as a JSON array.
#### parseable
* Default: false
* Type: Boolean
Output search results as lines with tab-separated columns.
#### long
* Default: false
* Type: Boolean
Display full package descriptions and other long text across multiple
lines. When disabled (default) search results are truncated to fit
neatly on a single line. Modules with extremely long names will
fall on multiple lines.
#### searchopts
* Default: ""
* Type: String
Space-separated options that are always passed to search.
#### searchexclude
* Default: ""
* Type: String
Space-separated options that limit the results from search.
#### searchstaleness
* Default: 900 (15 minutes)
* Type: Number
The age of the cache, in seconds, before another registry request is made.
#### registry
* Default: https://registry.npmjs.org/
* Type: url
Search the specified registry for modules. If you have configured npm to point
to a different default registry, such as your internal private module
repository, `npm search` will default to that registry when searching. Pass a
different registry url such as the default above in order to override this
setting.
### See Also
* [npm registry](/using-npm/registry)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [npm view](/cli-commands/npm-view)

34
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-shrinkwrap.md generated vendored Normal file
View File

@ -0,0 +1,34 @@
---
section: cli-commands
title: npm-shrinkwrap
description: Lock down dependency versions for publication
---
# npm-shrinkwrap(1)
## Lock down dependency versions for publication
### Synopsis
```bash
npm shrinkwrap
```
### Description
This command repurposes `package-lock.json` into a publishable
`npm-shrinkwrap.json` or simply creates a new one. The file created and updated
by this command will then take precedence over any other existing or future
`package-lock.json` files. For a detailed explanation of the design and purpose
of package locks in npm, see [package-locks](/configuring-npm/package-locks).
### See Also
* [npm install](/cli-commands/npm-install)
* [npm run-script](/cli-commands/npm-run-script)
* [npm scripts](/using-npm/scripts)
* [package.js](/configuring-npm/package-json)
* [package-locks](/configuring-npm/package-locks)
* [package-lock.json](/configuring-npm/package-lock-json)
* [shrinkwrap.json](/configuring-npm/shrinkwrap-json)
* [npm ls](/cli-commands/npm-ls)

31
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-star.md generated vendored Normal file
View File

@ -0,0 +1,31 @@
---
section: cli-commands
title: npm-star
description: Mark your favorite packages
---
# npm-star(1)
## Mark your favorite packages
### Synopsis
```bash
npm star [<pkg>...]
npm unstar [<pkg>...]
```
### Description
"Starring" a package means that you have some interest in it. It's
a vaguely positive way to show that you care.
"Unstarring" is the same thing, but in reverse.
It's a boolean thing. Starring repeatedly has no additional effect.
### See Also
* [npm view](/cli-commands/npm-view)
* [npm whoami](/cli-commands/npm-whoami)
* [npm adduser](/cli-commands/npm-adduser)

29
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-stars.md generated vendored Normal file
View File

@ -0,0 +1,29 @@
---
section: cli-commands
title: npm-stars
description: View packages marked as favorites
---
# npm-stars(1)
## View packages marked as favorites
### Synopsis
```bash
npm stars [<user>]
```
### Description
If you have starred a lot of neat things and want to find them again
quickly this command lets you do just that.
You may also want to see your friend's favorite packages, in this case
you will most certainly enjoy this command.
### See Also
* [npm star](/cli-commands/npm-star)
* [npm view](/cli-commands/npm-view)
* [npm whoami](/cli-commands/npm-whoami)
* [npm adduser](/cli-commands/npm-adduser)

32
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-start.md generated vendored Normal file
View File

@ -0,0 +1,32 @@
---
section: cli-commands
title: npm-start
description: Start a package
---
# npm-start(1)
## Start a package
### Synopsis
```bash
npm start [-- <args>]
```
### Description
This runs an arbitrary command specified in the package's `"start"` property of
its `"scripts"` object. If no `"start"` property is specified on the
`"scripts"` object, it will run `node server.js`.
As of [`npm@2.0.0`](https://blog.npmjs.org/post/98131109725/npm-2-0-0), you can
use custom arguments when executing scripts. Refer to [`npm run-script`](/cli-commands/npm-run-script) for more details.
### See Also
* [npm run-script](/cli-commands/npm-run-script)
* [npm scripts](/using-npm/scripts)
* [npm test](/cli-commands/npm-test)
* [npm restart](/cli-commands/npm-restart)
* [npm stop](/cli-commands/npm-stop)

27
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-stop.md generated vendored Normal file
View File

@ -0,0 +1,27 @@
---
section: cli-commands
title: npm-stop
description: Stop a package
---
# npm-stop(1)
## Stop a package
### Synopsis
```bash
npm stop [-- <args>]
```
### Description
This runs a package's "stop" script, if one was provided.
### See Also
* [npm run-script](/cli-commands/npm-run-script)
* [npm scripts](/using-npm/scripts)
* [npm test](/cli-commands/npm-test)
* [npm start](/cli-commands/npm-start)
* [npm restart](/cli-commands/npm-restart)

66
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-team.md generated vendored Normal file
View File

@ -0,0 +1,66 @@
---
section: cli-commands
title: npm-team
description: Manage organization teams and team memberships
---
# npm-team(1)
## Manage organization teams and team memberships
### Synopsis
```bash
npm team create <scope:team>
npm team destroy <scope:team>
npm team add <scope:team> <user>
npm team rm <scope:team> <user>
npm team ls <scope>|<scope:team>
npm team edit <scope:team>
```
### Description
Used to manage teams in organizations, and change team memberships. Does not
handle permissions for packages.
Teams must always be fully qualified with the organization/scope they belong to
when operating on them, separated by a colon (`:`). That is, if you have a `wombats` team in a `wisdom` organization, you must always refer to that team as `wisdom:wombats` in these commands.
If you have two-factor authentication enabled in `auth-and-writes` mode, then you can provide a code from your authenticator with `[--otp <otpcode>]`. If you don't include this then you will be prompted.
* create / destroy:
Create a new team, or destroy an existing one. Note: You cannot remove the `developers` team, <a href="https://docs.npmjs.com/about-developers-team" target="_blank">learn more.</a>
* add / rm:
Add a user to an existing team, or remove a user from a team they belong to.
* ls:
If performed on an organization name, will return a list of existing teams
under that organization. If performed on a team, it will instead return a list
of all users belonging to that particular team.
* edit:
Edit a current team.
### Details
`npm team` always operates directly on the current registry, configurable from
the command line using `--registry=<registry url>`.
In order to create teams and manage team membership, you must be a *team admin*
under the given organization. Listing teams and team memberships may be done by
any member of the organizations.
Organization creation and management of team admins and *organization* members
is done through the website, not the npm CLI.
To use teams to manage permissions on packages belonging to your organization,
use the `npm access` command to grant or revoke the appropriate permissions.
### See Also
* [npm access](/cli-commands/npm-access)
* [npm registry](/using-npm/registry)

29
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-test.md generated vendored Normal file
View File

@ -0,0 +1,29 @@
---
section: cli-commands
title: npm-test
description: Test a package
---
# npm-test(1)
## Test a package
### Synopsis
```bash
npm test [-- <args>]
aliases: t, tst
```
### Description
This runs a package's "test" script, if one was provided.
### See Also
* [npm run-script](/cli-commands/npm-run-script)
* [npm scripts](/using-npm/scripts)
* [npm start](/cli-commands/npm-start)
* [npm restart](/cli-commands/npm-restart)
* [npm stop](/cli-commands/npm-stop)

68
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-token.md generated vendored Normal file
View File

@ -0,0 +1,68 @@
---
section: cli-commands
title: npm-token
description: Manage your authentication tokens
---
# npm-token(1)
## Manage your authentication tokens
### Synopsis
```bash
npm token list [--json|--parseable]
npm token create [--read-only] [--cidr=1.1.1.1/24,2.2.2.2/16]
npm token revoke <id|token>
```
### Description
This lets you list, create and revoke authentication tokens.
* `npm token list`:
Shows a table of all active authentication tokens. You can request this as
JSON with `--json` or tab-separated values with `--parseable`.
```bash
+--------+---------+------------+----------+----------------+
| id | token | created | read-only | CIDR whitelist |
+--------+---------+------------+----------+----------------+
| 7f3134 | 1fa9ba… | 2017-10-02 | yes | |
+--------+---------+------------+----------+----------------+
| c03241 | af7aef… | 2017-10-02 | no | 192.168.0.1/24 |
+--------+---------+------------+----------+----------------+
| e0cf92 | 3a436a… | 2017-10-02 | no | |
+--------+---------+------------+----------+----------------+
| 63eb9d | 74ef35… | 2017-09-28 | no | |
+--------+---------+------------+----------+----------------+
| 2daaa8 | cbad5f… | 2017-09-26 | no | |
+--------+---------+------------+----------+----------------+
| 68c2fe | 127e51… | 2017-09-23 | no | |
+--------+---------+------------+----------+----------------+
| 6334e1 | 1dadd1… | 2017-09-23 | no | |
+--------+---------+------------+----------+----------------+
```
* `npm token create [--read-only] [--cidr=<cidr-ranges>]`:
Create a new authentication token. It can be `--read-only` or accept a list of
[CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) ranges to
limit use of this token to. This will prompt you for your password, and, if you have
two-factor authentication enabled, an otp.
```bash
+----------------+--------------------------------------+
| token | a73c9572-f1b9-8983-983d-ba3ac3cc913d |
+----------------+--------------------------------------+
| cidr_whitelist | |
+----------------+--------------------------------------+
| readonly | false |
+----------------+--------------------------------------+
| created | 2017-10-02T07:52:24.838Z |
+----------------+--------------------------------------+
```
* `npm token revoke <token|id>`:
This removes an authentication token, making it immediately unusable. This can accept
both complete tokens (as you get back from `npm token create` and will
find in your `.npmrc`) and ids as seen in the `npm token list` output.
This will NOT accept the truncated token found in `npm token list` output.

64
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-uninstall.md generated vendored Normal file
View File

@ -0,0 +1,64 @@
---
section: cli-commands
title: npm-uninstall
description: Remove a package
---
# npm-uninstall(1)
## Remove a package
### Synopsis
```bash
npm uninstall [<@scope>/]<pkg>[@<version>]... [-S|--save|-D|--save-dev|-O|--save-optional|--no-save]
aliases: remove, rm, r, un, unlink
```
### Description
This uninstalls a package, completely removing everything npm installed
on its behalf.
Example:
```bash
npm uninstall sax
```
In global mode (ie, with `-g` or `--global` appended to the command),
it uninstalls the current package context as a global package.
`npm uninstall` takes 3 exclusive, optional flags which save or update
the package version in your main package.json:
* `-S, --save`: Package will be removed from your `dependencies`.
* `-D, --save-dev`: Package will be removed from your `devDependencies`.
* `-O, --save-optional`: Package will be removed from your `optionalDependencies`.
* `--no-save`: Package will not be removed from your `package.json` file.
Further, if you have an `npm-shrinkwrap.json` then it will be updated as
well.
Scope is optional and follows the usual rules for [`scope`](/using-npm/scope).
Examples:
```bash
npm uninstall sax --save
npm uninstall @myorg/privatepackage --save
npm uninstall node-tap --save-dev
npm uninstall dtrace-provider --save-optional
npm uninstall lodash --no-save
```
### See Also
* [npm prune](/cli-commands/npm-prune)
* [npm install](/cli-commands/npm-install)
* [npm folders](/configuring-npm/folders)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)

50
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-unpublish.md generated vendored Normal file
View File

@ -0,0 +1,50 @@
---
section: cli-commands
title: npm-unpublish
description: Remove a package from the registry
---
# npm-unpublish(1)
## Remove a package from the registry
### Synopsis
#### Unpublishing a single version of a package
```bash
npm unpublish [<@scope>/]<pkg>@<version>
```
#### Unpublishing an entire package
```bash
npm unpublish [<@scope>/]<pkg> --force
```
### Warning
Consider using the `deprecate` command instead, if your intent is to encourage users to upgrade, or if you no longer want to maintain a package.
### Description
This removes a package version from the registry, deleting its
entry and removing the tarball.
If no version is specified, or if all versions are removed then
the root package entry is removed from the registry entirely.
Even if a package version is unpublished, that specific name and
version combination can never be reused. In order to publish the
package again, a new version number must be used. If you unpublish the entire package, you may not publish any new versions of that package until 24 hours have passed.
To learn more about how unpublish is treated on the npm registry, see our <a href="https://www.npmjs.com/policies/unpublish" target="_blank" rel="noopener noreferrer"> unpublish policies</a>.
### See Also
* [npm deprecate](/cli-commands/npm-deprecate)
* [npm publish](/cli-commands/npm-publish)
* [npm registry](/using-npm/registry)
* [npm adduser](/cli-commands/npm-adduser)
* [npm owner](/cli-commands/npm-owner)

140
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-update.md generated vendored Normal file
View File

@ -0,0 +1,140 @@
---
section: cli-commands
title: npm-update
description: Update a package
---
# npm-update(1)
## Update a package
### Synopsis
```bash
npm update [-g] [<pkg>...]
aliases: up, upgrade
```
### Description
This command will update all the packages listed to the latest version
(specified by the `tag` config), respecting semver.
It will also install missing packages. As with all commands that install
packages, the `--dev` flag will cause `devDependencies` to be processed
as well.
If the `-g` flag is specified, this command will update globally installed
packages.
If no package name is specified, all packages in the specified location (global
or local) will be updated.
As of `npm@2.6.1`, the `npm update` will only inspect top-level packages.
Prior versions of `npm` would also recursively inspect all dependencies.
To get the old behavior, use `npm --depth 9999 update`.
As of `npm@5.0.0`, the `npm update` will change `package.json` to save the
new version as the minimum required dependency. To get the old behavior,
use `npm update --no-save`.
### Example
IMPORTANT VERSION NOTE: these examples assume `npm@2.6.1` or later. For
older versions of `npm`, you must specify `--depth 0` to get the behavior
described below.
For the examples below, assume that the current package is `app` and it depends
on dependencies, `dep1` (`dep2`, .. etc.). The published versions of `dep1` are:
```json
{
"dist-tags": { "latest": "1.2.2" },
"versions": [
"1.2.2",
"1.2.1",
"1.2.0",
"1.1.2",
"1.1.1",
"1.0.0",
"0.4.1",
"0.4.0",
"0.2.0"
]
}
```
#### Caret Dependencies
If `app`'s `package.json` contains:
```json
"dependencies": {
"dep1": "^1.1.1"
}
```
Then `npm update` will install `dep1@1.2.2`, because `1.2.2` is `latest` and
`1.2.2` satisfies `^1.1.1`.
#### Tilde Dependencies
However, if `app`'s `package.json` contains:
```json
"dependencies": {
"dep1": "~1.1.1"
}
```
In this case, running `npm update` will install `dep1@1.1.2`. Even though the `latest`
tag points to `1.2.2`, this version does not satisfy `~1.1.1`, which is equivalent
to `>=1.1.1 <1.2.0`. So the highest-sorting version that satisfies `~1.1.1` is used,
which is `1.1.2`.
#### Caret Dependencies below 1.0.0
Suppose `app` has a caret dependency on a version below `1.0.0`, for example:
```json
"dependencies": {
"dep1": "^0.2.0"
}
```
`npm update` will install `dep1@0.2.0`, because there are no other
versions which satisfy `^0.2.0`.
If the dependence were on `^0.4.0`:
```json
"dependencies": {
"dep1": "^0.4.0"
}
```
Then `npm update` will install `dep1@0.4.1`, because that is the highest-sorting
version that satisfies `^0.4.0` (`>= 0.4.0 <0.5.0`)
#### Updating Globally-Installed Packages
`npm update -g` will apply the `update` action to each globally installed
package that is `outdated` -- that is, has a version that is different from
`wanted`.
Note: Globally installed packages are treated as if they are installed with a caret semver range specified. So if you require to update to `latest` you may need to run `npm install -g [<pkg>...]`
NOTE: If a package has been upgraded to a version newer than `latest`, it will
be _downgraded_.
### See Also
* [npm install](/cli-commands/npm-install)
* [npm outdated](/cli-commands/npm-outdated)
* [npm shrinkwrap](/cli-commands/npm-shrinkwrap)
* [npm registry](/using-npm/registry)
* [npm folders](/configuring-npm/folders)
* [npm ls](/cli-commands/npm-ls)

134
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-version.md generated vendored Normal file
View File

@ -0,0 +1,134 @@
---
section: cli-commands
title: npm-version
description: Bump a package version
---
# npm-version(1)
## Bump a package version
### Synopsis
```bash
npm version [<newversion> | major | minor | patch | premajor | preminor | prepatch | prerelease [--preid=<prerelease-id>] | from-git]
'npm [-v | --version]' to print npm version
'npm view <pkg> version' to view a package's published version
'npm ls' to inspect current package/dependency versions
```
### Description
Run this in a package directory to bump the version and write the new
data back to `package.json`, `package-lock.json`, and, if present, `npm-shrinkwrap.json`.
The `newversion` argument should be a valid semver string, a
valid second argument to [semver.inc](https://github.com/npm/node-semver#functions) (one of `patch`, `minor`, `major`,
`prepatch`, `preminor`, `premajor`, `prerelease`), or `from-git`. In the second case,
the existing version will be incremented by 1 in the specified field.
`from-git` will try to read the latest git tag, and use that as the new npm version.
If run in a git repo, it will also create a version commit and tag.
This behavior is controlled by `git-tag-version` (see below), and can
be disabled on the command line by running `npm --no-git-tag-version version`.
It will fail if the working directory is not clean, unless the `-f` or
`--force` flag is set.
If supplied with `-m` or `--message` config option, npm will
use it as a commit message when creating a version commit. If the
`message` config contains `%s` then that will be replaced with the
resulting version number. For example:
```bash
npm version patch -m "Upgrade to %s for reasons"
```
If the `sign-git-tag` config is set, then the tag will be signed using
the `-s` flag to git. Note that you must have a default GPG key set up
in your git config for this to work properly. For example:
```bash
$ npm config set sign-git-tag true
$ npm version patch
You need a passphrase to unlock the secret key for
user: "isaacs (http://blog.izs.me/) <i@izs.me>"
2048-bit RSA key, ID 6C481CF6, created 2010-08-31
Enter passphrase:
```
If `preversion`, `version`, or `postversion` are in the `scripts` property of
the package.json, they will be executed as part of running `npm version`.
The exact order of execution is as follows:
1. Check to make sure the git working directory is clean before we get started.
Your scripts may add files to the commit in future steps.
This step is skipped if the `--force` flag is set.
2. Run the `preversion` script. These scripts have access to the old `version` in package.json.
A typical use would be running your full test suite before deploying.
Any files you want added to the commit should be explicitly added using `git add`.
3. Bump `version` in `package.json` as requested (`patch`, `minor`, `major`, etc).
4. Run the `version` script. These scripts have access to the new `version` in package.json
(so they can incorporate it into file headers in generated files for example).
Again, scripts should explicitly add generated files to the commit using `git add`.
5. Commit and tag.
6. Run the `postversion` script. Use it to clean up the file system or automatically push
the commit and/or tag.
Take the following example:
```json
"scripts": {
"preversion": "npm test",
"version": "npm run build && git add -A dist",
"postversion": "git push && git push --tags && rm -rf build/temp"
}
```
This runs all your tests, and proceeds only if they pass. Then runs your `build` script, and
adds everything in the `dist` directory to the commit. After the commit, it pushes the new commit
and tag up to the server, and deletes the `build/temp` directory.
### Configuration
#### allow-same-version
* Default: false
* Type: Boolean
Prevents throwing an error when `npm version` is used to set the new version
to the same value as the current version.
#### git-tag-version
* Default: true
* Type: Boolean
Commit and tag the version change.
#### commit-hooks
* Default: true
* Type: Boolean
Run git commit hooks when committing the version change.
#### sign-git-tag
* Default: false
* Type: Boolean
Pass the `-s` flag to git to sign the tag.
Note that you must have a default GPG key set up in your git config for this to work properly.
### See Also
* [npm init](/cli-commands/npm-init)
* [npm run-script](/cli-commands/npm-run-script)
* [npm scripts](/using-npm/scripts)
* [package.json](/configuring-npm/package-json)
* [semver](/using-npm/semver)
* [config](/using-npm/config)

124
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-view.md generated vendored Normal file
View File

@ -0,0 +1,124 @@
---
section: cli-commands
title: npm-view
description: View registry info
---
# npm-view(1)
## View registry info
### Synopsis
```bash
npm view [<@scope>/]<name>[@<version>] [<field>[.<subfield>]...]
aliases: info, show, v
```
### Description
This command shows data about a package and prints it to the stream
referenced by the `outfd` config, which defaults to stdout.
To show the package registry entry for the `connect` package, you can do
this:
```bash
npm view connect
```
The default version is "latest" if unspecified.
Field names can be specified after the package descriptor.
For example, to show the dependencies of the `ronn` package at version
0.3.5, you could do the following:
```bash
npm view ronn@0.3.5 dependencies
```
You can view child fields by separating them with a period.
To view the git repository URL for the latest version of npm, you could
do this:
```bash
npm view npm repository.url
```
This makes it easy to view information about a dependency with a bit of
shell scripting. For example, to view all the data about the version of
opts that ronn depends on, you can do this:
```bash
npm view opts@$(npm view ronn dependencies.opts)
```
For fields that are arrays, requesting a non-numeric field will return
all of the values from the objects in the list. For example, to get all
the contributor names for the "express" project, you can do this:
```bash
npm view express contributors.email
```
You may also use numeric indices in square braces to specifically select
an item in an array field. To just get the email address of the first
contributor in the list, you can do this:
```bash
npm view express contributors[0].email
```
Multiple fields may be specified, and will be printed one after another.
For example, to get all the contributor names and email addresses, you
can do this:
```bash
npm view express contributors.name contributors.email
```
"Person" fields are shown as a string if they would be shown as an
object. So, for example, this will show the list of npm contributors in
the shortened string format. (See [`package.json`](/configuring-npm/package.json) for more on this.)
```bash
npm view npm contributors
```
If a version range is provided, then data will be printed for every
matching version of the package. This will show which version of jsdom
was required by each matching version of yui3:
```bash
npm view yui3@'>0.5.4' dependencies.jsdom
```
To show the `connect` package version history, you can do
this:
```bash
npm view connect versions
```
### Output
If only a single string field for a single version is output, then it
will not be colorized or quoted, so as to enable piping the output to
another command. If the field is an object, it will be output as a JavaScript object literal.
If the --json flag is given, the outputted fields will be JSON.
If the version range matches multiple versions, than each printed value
will be prefixed with the version it applies to.
If multiple fields are requested, than each of them are prefixed with
the field name.
### See Also
* [npm search](/cli-commands/npm-search)
* [npm registry](/using-npm/registry)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [npm docs](/cli-commands/npm-docs)

24
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm-whoami.md generated vendored Normal file
View File

@ -0,0 +1,24 @@
---
section: cli-commands
title: npm-whoami
description: Display npm username
---
# npm-whoami(1)
## Display npm username
### Synopsis
```bash
npm whoami [--registry <registry>]
```
### Description
Print the `username` config to standard output.
### See Also
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [npm adduser](/cli-commands/npm-adduser)

168
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/cli-commands/npm.md generated vendored Normal file
View File

@ -0,0 +1,168 @@
---
section: cli-commands
title: npm
description: javascript package manager
---
# npm(1)
## javascript package manager
### Synopsis
```bash
npm <command> [args]
```
### Version
@VERSION@
### Description
npm is the package manager for the Node JavaScript platform. It puts
modules in place so that node can find them, and manages dependency
conflicts intelligently.
It is extremely configurable to support a wide variety of use cases.
Most commonly, it is used to publish, discover, install, and develop node
programs.
Run `npm help` to get a list of available commands.
### Important
npm is configured to use npm, Inc.'s public registry at
https://registry.npmjs.org by default. Use of the npm public registry is
subject to terms of use available at https://www.npmjs.com/policies/terms.
You can configure npm to use any compatible registry you like, and even run
your own registry. Use of someone else's registry may be governed by their
terms of use.
### Introduction
You probably got npm because you want to install stuff.
Use `npm install blerg` to install the latest version of "blerg". Check out
[`npm install`](/cli-commands/npm-install) for more info. It can do a lot of stuff.
Use the `npm search` command to show everything that's available.
Use `npm ls` to show everything you've installed.
### Dependencies
If a package references to another package with a git URL, npm depends
on a preinstalled git.
If one of the packages npm tries to install is a native node module and
requires compiling of C++ Code, npm will use
[node-gyp](https://github.com/nodejs/node-gyp) for that task.
For a Unix system, [node-gyp](https://github.com/nodejs/node-gyp)
needs Python, make and a buildchain like GCC. On Windows,
Python and Microsoft Visual Studio C++ are needed.
For more information visit
[the node-gyp repository](https://github.com/nodejs/node-gyp) and
the [node-gyp Wiki](https://github.com/nodejs/node-gyp/wiki).
### Directories
See [`folders`](/configuring-npm/folders) to learn about where npm puts stuff.
In particular, npm has two modes of operation:
* global mode:
npm installs packages into the install prefix at
`prefix/lib/node_modules` and bins are installed in `prefix/bin`.
* local mode:
npm installs packages into the current project directory, which
defaults to the current working directory. Packages are installed to
`./node_modules`, and bins are installed to `./node_modules/.bin`.
Local mode is the default. Use `-g` or `--global` on any command to
operate in global mode instead.
### Developer Usage
If you're using npm to develop and publish your code, check out the
following help topics:
* json:
Make a package.json file. See [`package.json`](/configuring-npm/package.json).
* link:
For linking your current working code into Node's path, so that you
don't have to reinstall every time you make a change. Use
`npm link` to do this.
* install:
It's a good idea to install things if you don't need the symbolic link.
Especially, installing other peoples code from the registry is done via
`npm install`
* adduser:
Create an account or log in. Credentials are stored in the
user config file.
* publish:
Use the `npm publish` command to upload your code to the registry.
#### Configuration
npm is extremely configurable. It reads its configuration options from
5 places.
* Command line switches:
Set a config with `--key val`. All keys take a value, even if they
are booleans (the config parser doesn't know what the options are at
the time of parsing). If no value is provided, then the option is set
to boolean `true`.
* Environment Variables:
Set any config by prefixing the name in an environment variable with
`npm_config_`. For example, `export npm_config_key=val`.
* User Configs:
The file at $HOME/.npmrc is an ini-formatted list of configs. If
present, it is parsed. If the `userconfig` option is set in the cli
or env, then that will be used instead.
* Global Configs:
The file found at ../etc/npmrc (from the node executable, by default
this resolves to /usr/local/etc/npmrc) will be parsed if it is found.
If the `globalconfig` option is set in the cli, env, or user config,
then that file is parsed instead.
* Defaults:
npm's default configuration options are defined in
lib/utils/config-defs.js. These must not be changed.
See [`config`](/using-npm/config) for much much more information.
### Contributions
Patches welcome!
If you would like to contribute, but don't know what to work on, read
the contributing guidelines and check the issues list.
* [CONTRIBUTING.md](https://github.com/npm/cli/blob/latest/CONTRIBUTING.md)
* [Bug tracker](https://github.com/npm/cli/issues)
### Bugs
When you find issues, please report them:
* web:
<https://npm.community/c/bugs>
Be sure to follow the template and bug reporting guidelines. You can also ask
for help in the [support forum](https://npm.community/c/support) if you're
unsure if it's actually a bug or are having trouble coming up with a detailed
reproduction to report.
### Author
[Isaac Z. Schlueter](http://blog.izs.me/) ::
[isaacs](https://github.com/isaacs/) ::
[@izs](https://twitter.com/izs) ::
<i@izs.me>
### See Also
* [npm help](/cli-commands/npm-help)
* [package.json](/configuring-npm/package-json)
* [npm install](/cli-commands/npm-install)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)

223
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/configuring-npm/folders.md generated vendored Normal file
View File

@ -0,0 +1,223 @@
---
section: configuring-npm
title: folders
description: Folder Structures Used by npm
---
# folders(5)
## Folder Structures Used by npm
### Description
npm puts various things on your computer. That's its job.
This document will tell you what it puts where.
#### tl;dr
* Local install (default): puts stuff in `./node_modules` of the current
package root.
* Global install (with `-g`): puts stuff in /usr/local or wherever node
is installed.
* Install it **locally** if you're going to `require()` it.
* Install it **globally** if you're going to run it on the command line.
* If you need both, then install it in both places, or use `npm link`.
#### prefix Configuration
The `prefix` config defaults to the location where node is installed.
On most systems, this is `/usr/local`. On Windows, it's `%AppData%\npm`.
On Unix systems, it's one level up, since node is typically installed at
`{prefix}/bin/node` rather than `{prefix}/node.exe`.
When the `global` flag is set, npm installs things into this prefix.
When it is not set, it uses the root of the current package, or the
current working directory if not in a package already.
#### Node Modules
Packages are dropped into the `node_modules` folder under the `prefix`.
When installing locally, this means that you can
`require("packagename")` to load its main module, or
`require("packagename/lib/path/to/sub/module")` to load other modules.
Global installs on Unix systems go to `{prefix}/lib/node_modules`.
Global installs on Windows go to `{prefix}/node_modules` (that is, no
`lib` folder.)
Scoped packages are installed the same way, except they are grouped together
in a sub-folder of the relevant `node_modules` folder with the name of that
scope prefix by the @ symbol, e.g. `npm install @myorg/package` would place
the package in `{prefix}/node_modules/@myorg/package`. See [`scope`](/using-npm/scope) for more details.
If you wish to `require()` a package, then install it locally.
#### Executables
When in global mode, executables are linked into `{prefix}/bin` on Unix,
or directly into `{prefix}` on Windows.
When in local mode, executables are linked into
`./node_modules/.bin` so that they can be made available to scripts run
through npm. (For example, so that a test runner will be in the path
when you run `npm test`.)
#### Man Pages
When in global mode, man pages are linked into `{prefix}/share/man`.
When in local mode, man pages are not installed.
Man pages are not installed on Windows systems.
#### Cache
See [`npm cache`](/cli-commands/npm-cache). Cache files are stored in `~/.npm` on Posix, or
`%AppData%/npm-cache` on Windows.
This is controlled by the `cache` configuration param.
#### Temp Files
Temporary files are stored by default in the folder specified by the
`tmp` config, which defaults to the TMPDIR, TMP, or TEMP environment
variables, or `/tmp` on Unix and `c:\windows\temp` on Windows.
Temp files are given a unique folder under this root for each run of the
program, and are deleted upon successful exit.
### More Information
When installing locally, npm first tries to find an appropriate
`prefix` folder. This is so that `npm install foo@1.2.3` will install
to the sensible root of your package, even if you happen to have `cd`ed
into some other folder.
Starting at the $PWD, npm will walk up the folder tree checking for a
folder that contains either a `package.json` file, or a `node_modules`
folder. If such a thing is found, then that is treated as the effective
"current directory" for the purpose of running npm commands. (This
behavior is inspired by and similar to git's .git-folder seeking
logic when running git commands in a working dir.)
If no package root is found, then the current folder is used.
When you run `npm install foo@1.2.3`, then the package is loaded into
the cache, and then unpacked into `./node_modules/foo`. Then, any of
foo's dependencies are similarly unpacked into
`./node_modules/foo/node_modules/...`.
Any bin files are symlinked to `./node_modules/.bin/`, so that they may
be found by npm scripts when necessary.
#### Global Installation
If the `global` configuration is set to true, then npm will
install packages "globally".
For global installation, packages are installed roughly the same way,
but using the folders described above.
#### Cycles, Conflicts, and Folder Parsimony
Cycles are handled using the property of node's module system that it
walks up the directories looking for `node_modules` folders. So, at every
stage, if a package is already installed in an ancestor `node_modules`
folder, then it is not installed at the current location.
Consider the case above, where `foo -> bar -> baz`. Imagine if, in
addition to that, baz depended on bar, so you'd have:
`foo -> bar -> baz -> bar -> baz ...`. However, since the folder
structure is: `foo/node_modules/bar/node_modules/baz`, there's no need to
put another copy of bar into `.../baz/node_modules`, since when it calls
require("bar"), it will get the copy that is installed in
`foo/node_modules/bar`.
This shortcut is only used if the exact same
version would be installed in multiple nested `node_modules` folders. It
is still possible to have `a/node_modules/b/node_modules/a` if the two
"a" packages are different versions. However, without repeating the
exact same package multiple times, an infinite regress will always be
prevented.
Another optimization can be made by installing dependencies at the
highest level possible, below the localized "target" folder.
#### Example
Consider this dependency graph:
```bash
foo
+-- blerg@1.2.5
+-- bar@1.2.3
| +-- blerg@1.x (latest=1.3.7)
| +-- baz@2.x
| | `-- quux@3.x
| | `-- bar@1.2.3 (cycle)
| `-- asdf@*
`-- baz@1.2.3
`-- quux@3.x
`-- bar
```
In this case, we might expect a folder structure like this:
```bash
foo
+-- node_modules
+-- blerg (1.2.5) <---[A]
+-- bar (1.2.3) <---[B]
| `-- node_modules
| +-- baz (2.0.2) <---[C]
| | `-- node_modules
| | `-- quux (3.2.0)
| `-- asdf (2.3.4)
`-- baz (1.2.3) <---[D]
`-- node_modules
`-- quux (3.2.0) <---[E]
```
Since foo depends directly on `bar@1.2.3` and `baz@1.2.3`, those are
installed in foo's `node_modules` folder.
Even though the latest copy of blerg is 1.3.7, foo has a specific
dependency on version 1.2.5. So, that gets installed at [A]. Since the
parent installation of blerg satisfies bar's dependency on `blerg@1.x`,
it does not install another copy under [B].
Bar [B] also has dependencies on baz and asdf, so those are installed in
bar's `node_modules` folder. Because it depends on `baz@2.x`, it cannot
re-use the `baz@1.2.3` installed in the parent `node_modules` folder [D],
and must install its own copy [C].
Underneath bar, the `baz -> quux -> bar` dependency creates a cycle.
However, because bar is already in quux's ancestry [B], it does not
unpack another copy of bar into that folder.
Underneath `foo -> baz` [D], quux's [E] folder tree is empty, because its
dependency on bar is satisfied by the parent folder copy installed at [B].
For a graphical breakdown of what is installed where, use `npm ls`.
#### Publishing
Upon publishing, npm will look in the `node_modules` folder. If any of
the items there are not in the `bundledDependencies` array, then they will
not be included in the package tarball.
This allows a package maintainer to install all of their dependencies
(and dev dependencies) locally, but only re-publish those items that
cannot be found elsewhere. See [`package.json`](/configuring-npm/package.json) for more information.
### See also
* [package.json](/configuring-npm/package-json)
* [npm install](/cli-commands/npm-install)
* [npm pack](/cli-commands/npm-pack)
* [npm cache](/cli-commands/npm-cache)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [config](/using-npm/config)
* [npm publish](/cli-commands/npm-publish)

70
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/configuring-npm/install.md generated vendored Normal file
View File

@ -0,0 +1,70 @@
---
section: configuring-npm
title: install
description: Download and install node and npm
---
# install(5)
## Download and Install npm
### Description
To publish and install packages to and from the public npm registry, you must install Node.js and the npm command line interface using either a Node version manager or a Node installer. **We strongly recommend using a Node version manager to install Node.js and npm.** We do not recommend using a Node installer, since the Node installation process installs npm in a directory with local permissions and can cause permissions errors when you run npm packages globally.
### Overview
- [Checking your version of npm and Node.js](#checking-your-version-of-npm-and-node-js)
- [Using a Node version manager to install Node.js and npm](#using-a-node-version-manager-to-install-node-js-and-npm)
- [Using a Node installer to install Node.js and npm](#using-a-node-installer-to-install-node-js-and-npm)
### Checking your version of npm and Node.js
To see if you already have Node.js and npm installed and check the installed version, run the following commands:
```
node -v
npm -v
```
### Using a Node version manager to install Node.js and npm
Node version managers allow you to install and switch between multiple versions of Node.js and npm on your system so you can test your applications on multiple versions of npm to ensure they work for users on different versions.
#### OSX or Linux Node version managers
* [nvm](https://github.com/creationix/nvm)
* [n](https://github.com/tj/n)
#### Windows Node version managers
* [nodist](https://github.com/marcelklehr/nodist)
* [nvm-windows](https://github.com/coreybutler/nvm-windows)
### Using a Node installer to install Node.js and npm
If you are unable to use a Node version manager, you can use a Node installer to install both Node.js and npm on your system.
* [Node.js installer](https://nodejs.org/en/download/)
* [NodeSource installer](https://github.com/nodesource/distributions). If you use Linux, we recommend that you use a NodeSource installer.
#### OS X or Windows Node installers
If you're using OS X or Windows, use one of the installers from the [Node.js download page](https://nodejs.org/en/download/). Be sure to install the version labeled **LTS**. Other versions have not yet been tested with npm.
#### Linux or other operating systems Node installers
If you're using Linux or another operating system, use one of the following installers:
- [NodeSource installer](https://github.com/nodesource/distributions) (recommended)
- One of the installers on the [Node.js download page](https://nodejs.org/en/download/)
Or see [this page](https://nodejs.org/en/download/package-manager/) to install npm for Linux in the way many Linux developers prefer.
#### Less-common operating systems
For more information on installing Node.js on a variety of operating systems, see [this page][pkg-mgr].
[pkg-mgr]: https://nodejs.org/en/download/package-manager/

103
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/configuring-npm/npmrc.md generated vendored Normal file
View File

@ -0,0 +1,103 @@
---
section: configuring-npm
title: npmrc
description: The npm config files
---
# npmrc(5)
## The npm config files
### 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](/using-npm/config).
### Files
The four relevant files are:
* per-project config file (/path/to/my/project/.npmrc)
* per-user config file (~/.npmrc)
* global config file ($PREFIX/etc/npmrc)
* npm builtin config file (/path/to/npm/npmrc)
All npm config files are an ini-formatted list of `key = value`
parameters. Environment variables can be replaced using
`${VARIABLE_NAME}`. For example:
```bash
prefix = ${HOME}/.npm-packages
```
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:
```bash
key[] = "first value"
key[] = "second value"
```
#### Comments
Lines in `.npmrc` files are interpreted as comments when they begin with a `;` or `#` character. `.npmrc` files are parsed by [npm/ini](https://github.com/npm/ini), which specifies this comment syntax.
For example:
```bash
# last modified: 01 Jan 2016
; Set a new registry for a scoped package
@myscope:registry=https://mycustomregistry.example.org
```
#### Per-project config file
When working locally in a project, a `.npmrc` file in the root of the
project (ie, a sibling of `node_modules` and `package.json`) will set
config values specific to this project.
Note that this only applies to the root of the project that you're
running npm in. It has no effect when your module is published. For
example, you can't publish a module that forces itself to install
globally, or in a different location.
Additionally, this file is not read in global mode, such as when running
`npm install -g`.
#### Per-user config file
`$HOME/.npmrc` (or the `userconfig` param, if set in the environment
or on the command line)
#### Global config file
`$PREFIX/etc/npmrc` (or the `globalconfig` param, if set above):
This file is an ini-file formatted list of `key = value` parameters.
Environment variables can be replaced as above.
#### Built-in config file
`path/to/npm/itself/npmrc`
This is an unchangeable "builtin" configuration file that npm keeps
consistent across updates. Set fields in here using the `./configure`
script that comes with npm. This is primarily for distribution
maintainers to override default configs in a standard and consistent
manner.
### See also
* [npm folders](/configuring-npm/folders)
* [npm config](/cli-commands/npm-config)
* [config](/using-npm/config)
* [package.json](/configuring-npm/package-json)
* [npm](/cli-commands/npm)

917
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/configuring-npm/package-json.md generated vendored Normal file
View File

@ -0,0 +1,917 @@
---
section: configuring-npm
title: package.json
description: Specifics of npm's package.json handling
---
# package.json(5)
## Specifics of npm's package.json handling
### Description
This document is all you need to know about what's required in your package.json
file. It must be actual JSON, not just a JavaScript object literal.
A lot of the behavior described in this document is affected by the config
settings described in [`config`](/using-npm/config).
### name
If you plan to publish your package, the *most* important things in your
package.json are the name and version fields as they will be required. The name
and version together form an identifier that is assumed to be completely unique.
Changes to the package should come along with changes to the version. If you don't
plan to publish your package, the name and version fields are optional.
The name is what your thing is called.
Some rules:
* The name must be less than or equal to 214 characters. This includes the scope for
scoped packages.
* The names of scoped packages can begin with a dot or an underscore. This is not permitted without a scope.
* New packages must not have uppercase letters in the name.
* The name ends up being part of a URL, an argument on the command line, and a
folder name. Therefore, the name can't contain any non-URL-safe characters.
Some tips:
* Don't use the same name as a core Node module.
* Don't put "js" or "node" in the name. It's assumed that it's js, since you're
writing a package.json file, and you can specify the engine using the "engines"
field. (See below.)
* The name will probably be passed as an argument to require(), so it should
be something short, but also reasonably descriptive.
* You may want to check the npm registry to see if there's something by that name
already, before you get too attached to it. <https://www.npmjs.com/>
A name can be optionally prefixed by a scope, e.g. `@myorg/mypackage`. See
[`scope`](/using-npm/scope) for more detail.
### version
If you plan to publish your package, the *most* important things in your
package.json are the name and version fields as they will be required. The name
and version together form an identifier that is assumed to be completely unique.
Changes to the package should come along with changes to the version. If you don't
plan to publish your package, the name and version fields are optional.
Version must be parseable by
[node-semver](https://github.com/isaacs/node-semver), which is bundled
with npm as a dependency. (`npm install semver` to use it yourself.)
More on version numbers and ranges at [semver](/using-npm/semver).
### description
Put a description in it. It's a string. This helps people discover your
package, as it's listed in `npm search`.
### keywords
Put keywords in it. It's an array of strings. This helps people
discover your package as it's listed in `npm search`.
### homepage
The url to the project homepage.
Example:
```json
"homepage": "https://github.com/owner/project#readme"
```
### bugs
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.
It should look like this:
```json
{ "url" : "https://github.com/owner/project/issues"
, "email" : "project@hostname.com"
}
```
You can specify either one or both values. If you want to provide only a url,
you can specify the value for "bugs" as a simple string instead of an object.
If a url is provided, it will be used by the `npm bugs` command.
### license
You should specify 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 for the license you're using, like this:
```json
{ "license" : "BSD-3-Clause" }
```
You can check [the full list of SPDX license IDs](https://spdx.org/licenses/).
Ideally you should pick one that is
[OSI](https://opensource.org/licenses/alphabetical) approved.
If your package is licensed under multiple common licenses, use an [SPDX license
expression syntax version 2.0 string](https://www.npmjs.com/package/spdx), like this:
```json
{ "license" : "(ISC OR GPL-3.0)" }
```
If you are using a license that hasn't been assigned an SPDX identifier, or if
you are using a custom license, use a string value like this one:
```json
{ "license" : "SEE LICENSE IN <filename>" }
```
Then include a file named `<filename>` at the top level of the package.
Some old packages used license objects or a "licenses" property containing an
array of license objects:
```json
// Not valid metadata
{ "license" :
{ "type" : "ISC"
, "url" : "https://opensource.org/licenses/ISC"
}
}
// Not valid metadata
{ "licenses" :
[
{ "type": "MIT"
, "url": "https://www.opensource.org/licenses/mit-license.php"
}
, { "type": "Apache-2.0"
, "url": "https://opensource.org/licenses/apache2.0.php"
}
]
}
```
Those styles are now deprecated. Instead, use SPDX expressions, like this:
```json
{ "license": "ISC" }
{ "license": "(MIT OR Apache-2.0)" }
```
Finally, if you do not wish to grant others the right to use a private or
unpublished package under any terms:
```json
{ "license": "UNLICENSED" }
```
Consider also setting `"private": true` to prevent accidental publication.
### people fields: author, contributors
The "author" is one person. "contributors" is an array of people. A "person"
is an object with a "name" field and optionally "url" and "email", like this:
```json
{ "name" : "Barney Rubble"
, "email" : "b@rubble.com"
, "url" : "http://barnyrubble.tumblr.com/"
}
```
Or you can shorten that all into a single string, and npm will parse it for you:
```json
"Barney Rubble <b@rubble.com> (http://barnyrubble.tumblr.com/)"
```
Both email and url are optional either way.
npm also sets a top-level "maintainers" field with your npm user info.
### funding
You can specify an object containing an URL that provides up-to-date
information about ways to help fund development of your package, or
a string URL, or an array of these:
"funding": {
"type" : "individual",
"url" : "http://example.com/donate"
}
"funding": {
"type" : "patreon",
"url" : "https://www.patreon.com/my-account"
}
"funding": "http://example.com/donate"
"funding": [
{
"type" : "individual",
"url" : "http://example.com/donate"
},
"http://example.com/donateAlso",
{
"type" : "patreon",
"url" : "https://www.patreon.com/my-account"
}
]
Users can use the `npm fund` subcommand to list the `funding` URLs of all
dependencies of their project, direct and indirect. A shortcut to visit each
funding url is also available when providing the project name such as:
`npm fund <projectname>` (when there are multiple URLs, the first one will be
visited)
### files
The optional `files` field is an array of file patterns that describes
the entries to be included when your package is installed as a
dependency. File patterns follow a similar syntax to `.gitignore`, but
reversed: including a file, directory, or glob pattern (`*`, `**/*`, and such)
will make it so that file is included in the tarball when it's packed. Omitting
the field will make it default to `["*"]`, which means it will include all files.
Some special files and directories are also included or excluded regardless of
whether they exist in the `files` array (see below).
You can also provide a `.npmignore` file in the root of your package or
in subdirectories, which will keep files from being included. At the
root of your package it will not override the "files" field, but in
subdirectories it will. The `.npmignore` file works just like a
`.gitignore`. If there is a `.gitignore` file, and `.npmignore` is
missing, `.gitignore`'s contents will be used instead.
Files included with the "package.json#files" field _cannot_ be excluded
through `.npmignore` or `.gitignore`.
Certain files are always included, regardless of settings:
* `package.json`
* `README`
* `CHANGES` / `CHANGELOG` / `HISTORY`
* `LICENSE` / `LICENCE`
* `NOTICE`
* The file in the "main" field
`README`, `CHANGES`, `LICENSE` & `NOTICE` can have any case and extension.
Conversely, some files are always ignored:
* `.git`
* `CVS`
* `.svn`
* `.hg`
* `.lock-wscript`
* `.wafpickle-N`
* `.DS_Store`
* `npm-debug.log`
* `.npmrc`
* `node_modules`
* `config.gypi`
* `package-lock.json` (use shrinkwrap instead)
* All files containing a `*` character (incompatible with Windows)
### main
The main field is a module ID that is the primary entry point to your program.
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.
### browser
If your module is meant to be used client-side the browser field should be
used instead of the main field. This is helpful to hint users that it might
rely on primitives that aren't available in Node.js modules. (e.g. `window`)
### bin
A lot of packages have one or more executable files that they'd like to
install into the PATH. npm makes this pretty easy (in fact, it uses this
feature to install the "npm" executable.)
To use this, supply a `bin` field in your package.json which is a map of
command name to local file name. On install, npm will symlink that file into
`prefix/bin` for global installs, or `./node_modules/.bin/` for local
installs.
For example, myapp could have this:
```json
{ "bin" : { "myapp" : "./cli.js" } }
```
So, when you install myapp, it'll create a symlink from the `cli.js` script to
`/usr/local/bin/myapp`.
If you have a single executable, and its name should be the name
of the package, then you can just supply it as a string. For example:
```json
{ "name": "my-program"
, "version": "1.2.5"
, "bin": "./path/to/program" }
```
would be the same as this:
```json
{ "name": "my-program"
, "version": "1.2.5"
, "bin" : { "my-program" : "./path/to/program" } }
```
Please make sure that your file(s) referenced in `bin` starts with
`#!/usr/bin/env node`, otherwise the scripts are started without the node
executable!
### man
Specify either a single file or an array of filenames to put in place for the
`man` program to find.
If only a single file is provided, then it's installed such that it is the
result from `man <pkgname>`, regardless of its actual filename. For example:
```json
{ "name" : "foo"
, "version" : "1.2.3"
, "description" : "A packaged foo fooer for fooing foos"
, "main" : "foo.js"
, "man" : "./man/doc.1"
}
```
would link the `./man/doc.1` file in such that it is the target for `man foo`
If the filename doesn't start with the package name, then it's prefixed.
So, this:
```json
{ "name" : "foo"
, "version" : "1.2.3"
, "description" : "A packaged foo fooer for fooing foos"
, "main" : "foo.js"
, "man" : [ "./man/foo.1", "./man/bar.1" ]
}
```
will create files to do `man foo` and `man foo-bar`.
Man files must end with a number, and optionally a `.gz` suffix if they are
compressed. The number dictates which man section the file is installed into.
```json
{ "name" : "foo"
, "version" : "1.2.3"
, "description" : "A packaged foo fooer for fooing foos"
, "main" : "foo.js"
, "man" : [ "./man/foo.1", "./man/foo.2" ]
}
```
will create entries for `man foo` and `man 2 foo`
### directories
The CommonJS [Packages](http://wiki.commonjs.org/wiki/Packages/1.0) spec details a
few ways that you can indicate the structure of your package using a `directories`
object. If you look at [npm's package.json](https://registry.npmjs.org/npm/latest),
you'll see that it has directories for doc, lib, and man.
In the future, this information may be used in other creative ways.
#### directories.lib
Tell people where the bulk of your library is. Nothing special is done
with the lib folder in any way, but it's useful meta info.
#### directories.bin
If you specify a `bin` directory in `directories.bin`, all the files in
that folder will be added.
Because of the way the `bin` directive works, specifying both a
`bin` path and setting `directories.bin` is an error. If you want to
specify individual files, use `bin`, and for all the files in an
existing `bin` directory, use `directories.bin`.
#### directories.man
A folder that is full of man pages. Sugar to generate a "man" array by
walking the folder.
#### directories.doc
Put markdown files in here. Eventually, these will be displayed nicely,
maybe, someday.
#### directories.example
Put example scripts in here. Someday, it might be exposed in some clever way.
#### directories.test
Put your tests in here. It is currently not exposed, but it might be in the
future.
### repository
Specify the place where your code lives. This is helpful for people who
want to contribute. If the git repo is on GitHub, then the `npm docs`
command will be able to find you.
Do it like this:
```json
"repository": {
"type" : "git",
"url" : "https://github.com/npm/cli.git"
}
"repository": {
"type" : "svn",
"url" : "https://v8.googlecode.com/svn/trunk/"
}
```
The URL should be a publicly available (perhaps read-only) url that can be handed
directly to a VCS program without any modification. It should not be a url to an
html project page that you put in your browser. It's for computers.
For GitHub, GitHub gist, Bitbucket, or GitLab repositories you can use the same
shortcut syntax you use for `npm install`:
```json
"repository": "npm/npm"
"repository": "github:user/repo"
"repository": "gist:11081aaa281"
"repository": "bitbucket:user/repo"
"repository": "gitlab:user/repo"
```
If the `package.json` for your package is not in the root directory (for example
if it is part of a monorepo), you can specify the directory in which it lives:
```json
"repository": {
"type" : "git",
"url" : "https://github.com/facebook/react.git",
"directory": "packages/react-dom"
}
```
### scripts
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.
See [`scripts`](/using-npm/scripts) to find out more about writing package scripts.
### config
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:
```json
{ "name" : "foo"
, "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`.
See [`config`](/using-npm/config) and [`scripts`](/using-npm/scripts) for more on package
configs.
### dependencies
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.
**Please do not put test harnesses or transpilers in your
`dependencies` object.** See `devDependencies`, below.
See [semver](/using-npm/semver) for more details about specifying version ranges.
* `version` Must match `version` exactly
* `>version` Must be greater than `version`
* `>=version` etc
* `<version`
* `<=version`
* `~version` "Approximately equivalent to version" See [semver](/using-npm/semver)
* `^version` "Compatible with version" See [semver](/using-npm/semver)
* `1.2.x` 1.2.0, 1.2.1, etc., but not 1.3.0
* `http://...` See 'URLs as Dependencies' below
* `*` 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...` See 'Git URLs as Dependencies' below
* `user/repo` See 'GitHub URLs' below
* `tag` A specific version tagged and published as `tag` See [`npm dist-tag`](/cli-commands/npm-dist-tag)
* `path/path/path` See [Local Paths](#local-paths) below
For example, these are all valid:
```json
{ "dependencies" :
{ "foo" : "1.0.0 - 2.9999.9999"
, "bar" : ">=1.0.2 <2.1.2"
, "baz" : ">1.0.2 <=2.3.4"
, "boo" : "2.0.1"
, "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0"
, "asd" : "http://asdf.com/asdf.tar.gz"
, "til" : "~1.2"
, "elf" : "~1.2.3"
, "two" : "2.x"
, "thr" : "3.3.x"
, "lat" : "latest"
, "dyl" : "file:../dyl"
}
}
```
#### URLs as Dependencies
You may specify a tarball URL in place of a version range.
This tarball will be downloaded and installed locally to your package at
install time.
#### Git URLs as Dependencies
Git urls are of the form:
```bash
<protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish> | #semver:<semver>]
```
`<protocol>` is one of `git`, `git+ssh`, `git+http`, `git+https`, or
`git+file`.
If `#<commit-ish>` is provided, it will be used to clone exactly that
commit. If the commit-ish has the format `#semver:<semver>`, `<semver>` can
be any valid semver range or exact version, and npm will look for any tags
or refs matching that range in the remote repository, much as it would for a
registry dependency. If neither `#<commit-ish>` or `#semver:<semver>` is
specified, then `master` is used.
Examples:
```bash
git+ssh://git@github.com:npm/cli.git#v1.0.27
git+ssh://git@github.com:npm/cli#semver:^5.0
git+https://isaacs@github.com/npm/cli.git
git://github.com/npm/cli.git#v1.0.27
```
#### GitHub URLs
As of version 1.1.65, you can refer to GitHub urls as just "foo":
"user/foo-project". Just as with git URLs, a `commit-ish` suffix can be
included. For example:
```json
{
"name": "foo",
"version": "0.0.0",
"dependencies": {
"express": "expressjs/express",
"mocha": "mochajs/mocha#4727d357ea",
"module": "user/repo#feature\/branch"
}
}
```
#### Local Paths
As of version 2.0.0 you can provide a path to a local directory that contains a
package. Local paths can be saved using `npm install -S` or
`npm install --save`, using any of these forms:
```bash
../foo/bar
~/foo/bar
./foo/bar
/foo/bar
```
in which case they will be normalized to a relative path and added to your
`package.json`. For example:
```json
{
"name": "baz",
"dependencies": {
"bar": "file:../foo/bar"
}
}
```
This feature is helpful for local offline development and creating
tests that require npm installing where you don't want to hit an
external server, but should not be used when publishing packages
to the public registry.
### devDependencies
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.
These things will be installed when doing `npm link` or `npm install`
from the root of a package, and can be managed like any other npm
configuration param. See [`config`](/using-npm/config) for more on the topic.
For build steps that are not platform-specific, such as compiling
CoffeeScript or other languages to JavaScript, use the `prepare`
script to do this, and make the required package a devDependency.
For example:
```json
{ "name": "ethopia-waza",
"description": "a delightfully fruity coffee varietal",
"version": "1.2.3",
"devDependencies": {
"coffee-script": "~1.6.3"
},
"scripts": {
"prepare": "coffee -o lib/ -c src/waza.coffee"
},
"main": "lib/waza.js"
}
```
The `prepare` script will be run before publishing, so that users
can consume the functionality without requiring them to compile it
themselves. In dev mode (ie, locally running `npm install`), it'll
run this script as well, so that you can test it easily.
### peerDependencies
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.
For example:
```json
{
"name": "tea-latte",
"version": "1.3.5",
"peerDependencies": {
"tea": "2.x"
}
}
```
This ensures your package `tea-latte` can be installed *along* with the second
major version of the host package `tea` only. `npm install tea-latte` could
possibly yield the following dependency graph:
```bash
├── tea-latte@1.3.5
└── tea@2.2.0
```
**NOTE: npm versions 1 and 2 will automatically install `peerDependencies` if
they are not explicitly depended upon higher in the dependency tree. In the
next major version of npm (npm@3), this will no longer be the case. You will
receive a warning that the peerDependency is not installed instead.** The
behavior in npms 1 & 2 was frequently confusing and could easily put you into
dependency hell, a situation that npm is designed to avoid as much as possible.
Trying to install another plugin with a conflicting requirement will cause an
error. For this reason, make sure your plugin requirement is as broad as
possible, and not to lock it down to specific patch versions.
Assuming the host complies with [semver](https://semver.org/), only changes in
the host package's major version will break your plugin. Thus, if you've worked
with every 1.x version of the host package, use `"^1.0"` or `"1.x"` to express
this. If you depend on features introduced in 1.5.2, use `">= 1.5.2 < 2"`.
### bundledDependencies
This defines an array of package names that will be bundled when publishing
the package.
In cases where you need to preserve npm packages locally or have them
available through a single file download, you can bundle the packages in a
tarball file by specifying the package names in the `bundledDependencies`
array and executing `npm pack`.
For example:
If we define a package.json like this:
```json
{
"name": "awesome-web-framework",
"version": "1.0.0",
"bundledDependencies": [
"renderized", "super-streams"
]
}
```
we can obtain `awesome-web-framework-1.0.0.tgz` file by running `npm pack`.
This file contains the dependencies `renderized` and `super-streams` which
can be installed in a new project by executing `npm install
awesome-web-framework-1.0.0.tgz`. Note that the package names do not include
any versions, as that information is specified in `dependencies`.
If this is spelled `"bundleDependencies"`, then that is also honored.
### optionalDependencies
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. Running `npm install --no-optional` will prevent these
dependencies from being installed.
It is still your program's responsibility to handle the lack of the
dependency. For example, something like this:
```js
try {
var foo = require('foo')
var fooVersion = require('foo/package.json').version
} catch (er) {
foo = null
}
if ( notGoodFooVersion(fooVersion) ) {
foo = null
}
// .. then later in your program ..
if (foo) {
foo.doFooThings()
}
```
Entries in `optionalDependencies` will override entries of the same name in
`dependencies`, so it's usually best to only put in one place.
### engines
You can specify the version of node that your stuff works on:
```json
{ "engines" : { "node" : ">=0.10.3 <0.12" } }
```
And, like with dependencies, if you don't specify the version (or if you
specify "\*" as the version), then any version of node will do.
If you specify an "engines" field, then npm will require that "node" be
somewhere on that list. If "engines" is omitted, then npm will just assume
that it works on node.
You can also use the "engines" field to specify which versions of npm
are capable of properly installing your program. For example:
```json
{ "engines" : { "npm" : "~1.0.20" } }
```
Unless the user has set the `engine-strict` config flag, this
field is advisory only and will only produce warnings when your package is installed as a dependency.
### engineStrict
**This feature was removed in npm 3.0.0**
Prior to npm 3.0.0, this feature was used to treat this package as if the
user had set `engine-strict`. It is no longer used.
### os
You can specify which operating systems your
module will run on:
```json
"os" : [ "darwin", "linux" ]
```
You can also blacklist instead of whitelist operating systems,
just prepend the blacklisted os with a '!':
```json
"os" : [ "!win32" ]
```
The host operating system is determined by `process.platform`
It is allowed to both blacklist, and whitelist, although there isn't any
good reason to do this.
### cpu
If your code only runs on certain cpu architectures,
you can specify which ones.
```json
"cpu" : [ "x64", "ia32" ]
```
Like the `os` option, you can also blacklist architectures:
```json
"cpu" : [ "!arm", "!mips" ]
```
The host architecture is determined by `process.arch`
### preferGlobal
**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.
### private
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.
### publishConfig
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 [`config`](/using-npm/config) to see the list of config options that can be
overridden.
### DEFAULT VALUES
npm will default some values based on package contents.
* `"scripts": {"start": "node server.js"}`
If there is a `server.js` file in the root of your package, then npm
will default the `start` command to `node server.js`.
* `"scripts":{"install": "node-gyp rebuild"}`
If there is a `binding.gyp` file in the root of your package and you have not defined an `install` or `preinstall` script, npm will
default the `install` command to compile using node-gyp.
* `"contributors": [...]`
If there is an `AUTHORS` file in the root of your package, npm will
treat each line as a `Name <email> (url)` format, where email and url
are optional. Lines which start with a `#` or are blank, will be
ignored.
### SEE ALSO
* [semver](/using-npm/semver)
* [npm init](/cli-commands/npm-init)
* [npm version](/cli-commands/npm-version)
* [npm config](/cli-commands/npm-config)
* [npm help](/cli-commands/npm-help)
* [npm install](/cli-commands/npm-install)
* [npm publish](/cli-commands/npm-publish)
* [npm uninstall](/cli-commands/npm-uninstall)

149
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/configuring-npm/package-lock-json.md generated vendored Normal file
View File

@ -0,0 +1,149 @@
---
section: configuring-npm
title: package-lock.json
description: A manifestation of the manifest
---
# package-lock.json(5)
## A manifestation of the manifest
### Description
`package-lock.json` is automatically generated for any operations where npm
modifies either the `node_modules` tree, or `package.json`. It describes the
exact tree that was generated, such that subsequent installs are able to
generate identical trees, regardless of intermediate dependency updates.
This file is intended to be committed into source repositories, and serves
various purposes:
* Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.
* Provide a facility for users to "time-travel" to previous states of `node_modules` without having to commit the directory itself.
* To facilitate greater visibility of tree changes through readable source control diffs.
* And optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages.
One key detail about `package-lock.json` is that it cannot be published, and it
will be ignored if found in any place other than the toplevel package. It shares
a format with [npm-shrinkwrap.json](/configuring-npm/shrinkwrap-json), which is essentially the same file, but
allows publication. This is not recommended unless deploying a CLI tool or
otherwise using the publication process for producing production packages.
If both `package-lock.json` and `npm-shrinkwrap.json` are present in the root of
a package, `package-lock.json` will be completely ignored.
### File Format
#### name
The name of the package this is a package-lock for. This must match what's in
`package.json`.
#### version
The version of the package this is a package-lock for. This must match what's in
`package.json`.
#### lockfileVersion
An integer version, starting at `1` with the version number of this document
whose semantics were used when generating this `package-lock.json`.
#### packageIntegrity
This is a [subresource
integrity](https://w3c.github.io/webappsec/specs/subresourceintegrity/) value
created from the `package.json`. No preprocessing of the `package.json` should
be done. Subresource integrity strings can be produced by modules like
[`ssri`](https://www.npmjs.com/package/ssri).
#### preserveSymlinks
Indicates that the install was done with the environment variable
`NODE_PRESERVE_SYMLINKS` enabled. The installer should insist that the value of
this property match that environment variable.
#### dependencies
A mapping of package name to dependency object. Dependency objects have the
following properties:
##### version
This is a specifier that uniquely identifies this package and should be
usable in fetching a new copy of it.
* bundled dependencies: Regardless of source, this is a version number that is purely for informational purposes.
* registry sources: This is a version number. (eg, `1.2.3`)
* git sources: This is a git specifier with resolved committish. (eg, `git+https://example.com/foo/bar#115311855adb0789a0466714ed48a1499ffea97e`)
* http tarball sources: This is the URL of the tarball. (eg, `https://example.com/example-1.3.0.tgz`)
* local tarball sources: This is the file URL of the tarball. (eg `file:///opt/storage/example-1.3.0.tgz`)
* local link sources: This is the file URL of the link. (eg `file:libs/our-module`)
##### integrity
This is a [Standard Subresource
Integrity](https://w3c.github.io/webappsec/specs/subresourceintegrity/) for this
resource.
* For bundled dependencies this is not included, regardless of source.
* For registry sources, this is the `integrity` that the registry provided, or if one wasn't provided the SHA1 in `shasum`.
* For git sources this is the specific commit hash we cloned from.
* For remote tarball sources this is an integrity based on a SHA512 of
the file.
* For local tarball sources: This is an integrity field based on the SHA512 of the file.
##### resolved
* For bundled dependencies this is not included, regardless of source.
* For registry sources this is path of the tarball relative to the registry
URL. If the tarball URL isn't on the same server as the registry URL then
this is a complete URL.
##### bundled
If true, this is the bundled dependency and will be installed by the parent
module. When installing, this module will be extracted from the parent
module during the extract phase, not installed as a separate dependency.
##### dev
If true then this dependency is either a development dependency ONLY of the
top level module or a transitive dependency of one. This is false for
dependencies that are both a development dependency of the top level and a
transitive dependency of a non-development dependency of the top level.
##### optional
If true then this dependency is either an optional dependency ONLY of the
top level module or a transitive dependency of one. This is false for
dependencies that are both an optional dependency of the top level and a
transitive dependency of a non-optional dependency of the top level.
All optional dependencies should be included even if they're uninstallable
on the current platform.
##### requires
This is a mapping of module name to version. This is a list of everything
this module requires, regardless of where it will be installed. The version
should match via normal matching rules a dependency either in our
`dependencies` or in a level higher than us.
##### dependencies
The dependencies of this dependency, exactly as at the top level.
### See also
* [npm shrinkwrap](/cli-commands/npm-shrinkwrap)
* [shrinkwrap.json](/configuring-npm/shrinkwrap-json)
* [package-locks](/configuring-npm/package-locks)
* [package.json](/configuring-npm/package-json)
* [npm install](/cli-commands/npm-install)

182
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/configuring-npm/package-locks.md generated vendored Normal file
View File

@ -0,0 +1,182 @@
---
section: configuring-npm
title: package-locks
description: An explanation of npm lockfiles
---
# package-locks(5)
## An explanation of npm lockfiles
### Description
Conceptually, the "input" to [`npm install`](/cli-commands/npm-install) is a [package.json](/configuring-npm/package-json), while its
"output" is a fully-formed `node_modules` tree: a representation of the
dependencies you declared. In an ideal world, npm would work like a pure
function: the same `package.json` should produce the exact same `node_modules`
tree, any time. In some cases, this is indeed true. But in many others, npm is
unable to do this. There are multiple reasons for this:
* different versions of npm (or other package managers) may have been used to install a package, each using slightly different installation algorithms.
* a new version of a direct semver-range package may have been published since the last time your packages were installed, and thus a newer version will be used.
* A dependency of one of your dependencies may have published a new version, which will update even if you used pinned dependency specifiers (`1.2.3` instead of `^1.2.3`)
* The registry you installed from is no longer available, or allows mutation of versions (unlike the primary npm registry), and a different version of a package exists under the same version number now.
As an example, consider package A:
```json
{
"name": "A",
"version": "0.1.0",
"dependencies": {
"B": "<0.1.0"
}
}
```
package B:
```json
{
"name": "B",
"version": "0.0.1",
"dependencies": {
"C": "<0.1.0"
}
}
```
and package C:
```json
{
"name": "C",
"version": "0.0.1"
}
```
If these are the only versions of A, B, and C available in the
registry, then a normal `npm install A` will install:
```json
A@0.1.0
`-- B@0.0.1
`-- C@0.0.1
```
However, if B@0.0.2 is published, then a fresh `npm install A` will
install:
```bash
A@0.1.0
`-- B@0.0.2
`-- C@0.0.1
```
assuming the new version did not modify B's dependencies. Of course,
the new version of B could include a new version of C and any number
of new dependencies. If such changes are undesirable, the author of A
could specify a dependency on B@0.0.1. However, if A's author and B's
author are not the same person, there's no way for A's author to say
that he or she does not want to pull in newly published versions of C
when B hasn't changed at all.
To prevent this potential issue, npm uses [package-lock.json](/configuring-npm/package-lock-json) or, if present, [npm-shrinkwrap.json](/configuring-npm/shrinkwrap-json). These files are called package locks, or lockfiles.
Whenever you run `npm install`, npm generates or updates your package lock,
which will look something like this:
```json
{
"name": "A",
"version": "0.1.0",
...metadata fields...
"dependencies": {
"B": {
"version": "0.0.1",
"resolved": "https://registry.npmjs.org/B/-/B-0.0.1.tgz",
"integrity": "sha512-DeAdb33F+"
"dependencies": {
"C": {
"version": "git://github.com/org/C.git#5c380ae319fc4efe9e7f2d9c78b0faa588fd99b4"
}
}
}
}
}
```
This file describes an *exact*, and more importantly *reproducible*
`node_modules` tree. Once it's present, any future installation will base its
work off this file, instead of recalculating dependency versions off
[package.json](/configuring-npm/package-json).
The presence of a package lock changes the installation behavior such that:
1. The module tree described by the package lock is reproduced. This means
reproducing the structure described in the file, using the specific files
referenced in "resolved" if available, falling back to normal package resolution
using "version" if one isn't.
2. The tree is walked and any missing dependencies are installed in the usual
fashion.
If `preshrinkwrap`, `shrinkwrap` or `postshrinkwrap` are in the `scripts`
property of the `package.json`, they will be executed in order. `preshrinkwrap`
and `shrinkwrap` are executed before the shrinkwrap, `postshrinkwrap` is
executed afterwards. These scripts run for both `package-lock.json` and
`npm-shrinkwrap.json`. For example to run some postprocessing on the generated
file:
```json
"scripts": {
"postshrinkwrap": "json -I -e \"this.myMetadata = $MY_APP_METADATA\""
}
```
#### Using locked packages
Using a locked package is no different than using any package without a package
lock: any commands that update `node_modules` and/or `package.json`'s
dependencies will automatically sync the existing lockfile. This includes `npm
install`, `npm rm`, `npm update`, etc. To prevent this update from happening,
you can use the `--no-save` option to prevent saving altogether, or
`--no-shrinkwrap` to allow `package.json` to be updated while leaving
`package-lock.json` or `npm-shrinkwrap.json` intact.
It is highly recommended you commit the generated package lock to source
control: this will allow anyone else on your team, your deployments, your
CI/continuous integration, and anyone else who runs `npm install` in your
package source to get the exact same dependency tree that you were developing
on. Additionally, the diffs from these changes are human-readable and will
inform you of any changes npm has made to your `node_modules`, so you can notice
if any transitive dependencies were updated, hoisted, etc.
#### Resolving lockfile conflicts
Occasionally, two separate npm install will create package locks that cause
merge conflicts in source control systems. As of `npm@5.7.0`, these conflicts
can be resolved by manually fixing any `package.json` conflicts, and then
running `npm install [--package-lock-only]` again. npm will automatically
resolve any conflicts for you and write a merged package lock that includes all
the dependencies from both branches in a reasonable tree. If
`--package-lock-only` is provided, it will do this without also modifying your
local `node_modules/`.
To make this process seamless on git, consider installing
[`npm-merge-driver`](https://npm.im/npm-merge-driver), which will teach git how
to do this itself without any user interaction. In short: `$ npx
npm-merge-driver install -g` will let you do this, and even works with
pre-`npm@5.7.0` versions of npm 5, albeit a bit more noisily. Note that if
`package.json` itself conflicts, you will have to resolve that by hand and run
`npm install` manually, even with the merge driver.
### See Also
* https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527
* [package.json](/configuring-npm/package-json)
* [package-lock.json](/configuring-npm/package-lock-json)
* [shrinkwrap.json](/configuring-npm/shrinkwrap-json)
* [npm shrinkwrap](/cli-commands/npm-shrinkwrap)

34
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/configuring-npm/shrinkwrap-json.md generated vendored Normal file
View File

@ -0,0 +1,34 @@
---
section: configuring-npm
title: shrinkwrap.json
description: A publishable lockfile
---
# npm-shrinkwrap.json(5)
## A publishable lockfile
### Description
`npm-shrinkwrap.json` is a file created by [`npm shrinkwrap`](/cli-commands/npm-shrinkwrap). It is identical to
`package-lock.json`, with one major caveat: Unlike `package-lock.json`,
`npm-shrinkwrap.json` may be included when publishing a package.
The recommended use-case for `npm-shrinkwrap.json` is applications deployed
through the publishing process on the registry: for example, daemons and
command-line tools intended as global installs or `devDependencies`. It's
strongly discouraged for library authors to publish this file, since that would
prevent end users from having control over transitive dependency updates.
Additionally, if both `package-lock.json` and `npm-shrinkwrap.json` are present
in a package root, `package-lock.json` will be ignored in favor of this file.
For full details and description of the `npm-shrinkwrap.json` file format, refer
to the manual page for [package-lock.json](/configuring-npm/package-lock-json).
### See also
* [npm shrinkwrap](/cli-commands/npm-shrinkwrap)
* [package-lock.json](/configuring-npm/package-lock-json)
* [package.json](/configuring-npm/package-json)
* [npm install](/cli-commands/npm-install)

1300
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/using-npm/config.md generated vendored Normal file
View File

File diff suppressed because it is too large Load Diff

252
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/using-npm/developers.md generated vendored Normal file
View File

@ -0,0 +1,252 @@
---
section: using-npm
title: developers
description: Developer Guide
---
# developers(7)
## Developer Guide
### Description
So, you've decided to use npm to develop (and maybe publish/deploy)
your project.
Fantastic!
There are a few things that you need to do above the simple steps
that your users will do to install your program.
### About These Documents
These are man pages. If you install npm, you should be able to
then do `man npm-thing` to get the documentation on a particular
topic, or `npm help thing` to see the same information.
### What is a package
A package is:
* a) a folder containing a program described by a package.json file
* b) a gzipped tarball containing (a)
* c) a url that resolves to (b)
* d) a `<name>@<version>` that is published on the registry with (c)
* e) a `<name>@<tag>` that points to (d)
* f) a `<name>` that has a "latest" tag satisfying (e)
* g) a `git` url that, when cloned, results in (a).
Even if you never publish your package, you can still get a lot of
benefits of using npm if you just want to write a node program (a), and
perhaps if you also want to be able to easily install it elsewhere
after packing it up into a tarball (b).
Git urls can be of the form:
```bash
git://github.com/user/project.git#commit-ish
git+ssh://user@hostname:project.git#commit-ish
git+http://user@hostname/project/blah.git#commit-ish
git+https://user@hostname/project/blah.git#commit-ish
```
The `commit-ish` can be any tag, sha, or branch which can be supplied as
an argument to `git checkout`. The default is `master`.
### The package.json File
You need to have a `package.json` file in the root of your project to do
much of anything with npm. That is basically the whole interface.
See [`package.json`](/configuring-npm/package-json) for details about what goes in that file. At the very
least, you need:
* name:
This should be a string that identifies your project. Please do not
use the name to specify that it runs on node, or is in JavaScript.
You can use the "engines" field to explicitly state the versions of
node (or whatever else) that your program requires, and it's pretty
well assumed that it's JavaScript.
It does not necessarily need to match your github repository name.
So, `node-foo` and `bar-js` are bad names. `foo` or `bar` are better.
* version:
A semver-compatible version.
* engines:
Specify the versions of node (or whatever else) that your program
runs on. The node API changes a lot, and there may be bugs or new
functionality that you depend on. Be explicit.
* author:
Take some credit.
* scripts:
If you have a special compilation or installation script, then you
should put it in the `scripts` object. You should definitely have at
least a basic smoke-test command as the "scripts.test" field.
See [scripts](/using-npm/scripts).
* main:
If you have a single module that serves as the entry point to your
program (like what the "foo" package gives you at require("foo")),
then you need to specify that in the "main" field.
* directories:
This is an object mapping names to folders. The best ones to include are
"lib" and "doc", but if you use "man" to specify a folder full of man pages,
they'll get installed just like these ones.
You can use `npm init` in the root of your package in order to get you
started with a pretty basic package.json file. See [`npm init`](/cli-commands/npm-init) for
more info.
### Keeping files *out* of your package
Use a `.npmignore` file to keep stuff out of your package. If there's
no `.npmignore` file, but there *is* a `.gitignore` file, then npm will
ignore the stuff matched by the `.gitignore` file. If you *want* to
include something that is excluded by your `.gitignore` file, you can
create an empty `.npmignore` file to override it. Like `git`, `npm` looks
for `.npmignore` and `.gitignore` files in all subdirectories of your
package, not only the root directory.
`.npmignore` files follow the [same pattern rules](https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository#Ignoring-Files)
as `.gitignore` files:
* Blank lines or lines starting with `#` are ignored.
* Standard glob patterns work.
* You can end patterns with a forward slash `/` to specify a directory.
* You can negate a pattern by starting it with an exclamation point `!`.
By default, the following paths and files are ignored, so there's no
need to add them to `.npmignore` explicitly:
* `.*.swp`
* `._*`
* `.DS_Store`
* `.git`
* `.hg`
* `.npmrc`
* `.lock-wscript`
* `.svn`
* `.wafpickle-*`
* `config.gypi`
* `CVS`
* `npm-debug.log`
Additionally, everything in `node_modules` is ignored, except for
bundled dependencies. npm automatically handles this for you, so don't
bother adding `node_modules` to `.npmignore`.
The following paths and files are never ignored, so adding them to
`.npmignore` is pointless:
* `package.json`
* `README` (and its variants)
* `CHANGELOG` (and its variants)
* `LICENSE` / `LICENCE`
If, given the structure of your project, you find `.npmignore` to be a
maintenance headache, you might instead try populating the `files`
property of `package.json`, which is an array of file or directory names
that should be included in your package. Sometimes a whitelist is easier
to manage than a blacklist.
#### Testing whether your `.npmignore` or `files` config works
If you want to double check that your package will include only the files
you intend it to when published, you can run the `npm pack` command locally
which will generate a tarball in the working directory, the same way it
does for publishing.
### Link Packages
`npm link` is designed to install a development package and see the
changes in real time without having to keep re-installing it. (You do
need to either re-link or `npm rebuild -g` to update compiled packages,
of course.)
More info at [`npm link`](/cli-commands/npm-link).
### Before Publishing: Make Sure Your Package Installs and Works
**This is important.**
If you can not install it locally, you'll have
problems trying to publish it. Or, worse yet, you'll be able to
publish it, but you'll be publishing a broken or pointless package.
So don't do that.
In the root of your package, do this:
```bash
npm install . -g
```
That'll show you that it's working. If you'd rather just create a symlink
package that points to your working directory, then do this:
```bash
npm link
```
Use `npm ls -g` to see if it's there.
To test a local install, go into some other folder, and then do:
```bash
cd ../some-other-folder
npm install ../my-package
```
to install it locally into the node_modules folder in that other place.
Then go into the node-repl, and try using require("my-thing") to
bring in your module's main module.
### Create a User Account
Create a user with the adduser command. It works like this:
```bash
npm adduser
```
and then follow the prompts.
This is documented better in [npm adduser](/cli-commands/npm-adduser).
### Publish your package
This part's easy. In the root of your folder, do this:
```bash
npm publish
```
You can give publish a url to a tarball, or a filename of a tarball,
or a path to a folder.
Note that pretty much **everything in that folder will be exposed**
by default. So, if you have secret stuff in there, use a
`.npmignore` file to list out the globs to ignore, or publish
from a fresh checkout.
### Brag about it
Send emails, write blogs, blab in IRC.
Tell the world how easy it is to install your program!
### See also
* [npm](/cli-commands/npm)
* [npm init](/cli-commands/npm-init)
* [package.json](/configuring-npm/package-json)
* [npm scripts](/using-npm/scripts)
* [npm publish](/cli-commands/npm-publish)
* [npm adduser](/cli-commands/npm-adduser)
* [npm registry](/using-npm/registry)

137
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/using-npm/disputes.md generated vendored Normal file
View File

@ -0,0 +1,137 @@
---
section: using-npm
title: disputes
description: Handling Module Name Disputes
---
# disputes(7)
## Handling Module Name Disputes
This document describes the steps that you should take to resolve module name
disputes with other npm publishers. It also describes special steps you should
take about names you think infringe your trademarks.
This document is a clarification of the acceptable behavior outlined in the
[npm Code of Conduct](https://www.npmjs.com/policies/conduct), and nothing in
this document should be interpreted to contradict any aspect of the npm Code of
Conduct.
### TL;DR
1. Get the author email with `npm owner ls <pkgname>`
2. Email the author, CC <support@npmjs.com>
3. After a few weeks, if there's no resolution, we'll sort it out.
Don't squat on package names. Publish code or move out of the way.
### Description
There sometimes arise cases where a user publishes a module, and then later,
some other user wants to use that name. Here are some common ways that happens
(each of these is based on actual events.)
1. Alice writes a JavaScript module `foo`, which is not node-specific. Alice
doesn't use node at all. Yusuf wants to use `foo` in node, so he wraps it in
an npm module. Some time later, Alice starts using node, and wants to take
over management of her program.
2. Yusuf writes an npm module `foo`, and publishes it. Perhaps much later, Alice
finds a bug in `foo`, and fixes it. She sends a pull request to Yusuf, but
Yusuf doesn't have the time to deal with it, because he has a new job and a
new baby and is focused on his new Erlang project, and kind of not involved
with node any more. Alice would like to publish a new `foo`, but can't,
because the name is taken.
3. Yusuf writes a 10-line flow-control library, and calls it `foo`, and
publishes it to the npm registry. Being a simple little thing, it never
really has to be updated. Alice works for Foo Inc, the makers of the
critically acclaimed and widely-marketed `foo` JavaScript toolkit framework.
They publish it to npm as `foojs`, but people are routinely confused when
`npm install foo` is some different thing.
4. Yusuf writes a parser for the widely-known `foo` file format, because he
needs it for work. Then, he gets a new job, and never updates the prototype.
Later on, Alice writes a much more complete `foo` parser, but can't publish,
because Yusuf's `foo` is in the way.
1. `npm owner ls foo`. This will tell Alice the email address of the owner
(Yusuf).
2. Alice emails Yusuf, explaining the situation **as respectfully as possible**,
and what she would like to do with the module name. She adds the npm support
staff <support@npmjs.com> to the CC list of the email. Mention in the email
that Yusuf can run npm owner `add alice foo` to add Alice as an owner of the
foo package.
3. After a reasonable amount of time, if Yusuf has not responded, or if Yusuf
and Alice can't come to any sort of resolution, email support
<support@npmjs.com> and we'll sort it out. ("Reasonable" is usually at least
4 weeks.)
### Reasoning
In almost every case so far, the parties involved have been able to reach an
amicable resolution without any major intervention. Most people really do want
to be reasonable, and are probably not even aware that they're in your way.
Module ecosystems are most vibrant and powerful when they are as self-directed
as possible. If an admin one day deletes something you had worked on, then that
is going to make most people quite upset, regardless of the justification. When
humans solve their problems by talking to other humans with respect, everyone
has the chance to end up feeling good about the interaction.
### Exceptions
Some things are not allowed, and will be removed without discussion if they are
brought to the attention of the npm registry admins, including but not limited
to:
1. Malware (that is, a package designed to exploit or harm the machine on which
it is installed).
2. Violations of copyright or licenses (for example, cloning an MIT-licensed
program, and then removing or changing the copyright and license statement).
3. Illegal content.
4. "Squatting" on a package name that you plan to use, but aren't actually
using. Sorry, I don't care how great the name is, or how perfect a fit it is
for the thing that someday might happen. If someone wants to use it today,
and you're just taking up space with an empty tarball, you're going to be
evicted.
5. Putting empty packages in the registry. Packages must have SOME
functionality. It can be silly, but it can't be nothing. (See also:
squatting.)
6. Doing weird things with the registry, like using it as your own personal
application database or otherwise putting non-packagey things into it.
7. Other things forbidden by the npm
[Code of Conduct](https://www.npmjs.com/policies/conduct) such as hateful
language, pornographic content, or harassment.
If you see bad behavior like this, please report it to <abuse@npmjs.com> right
away. **You are never expected to resolve abusive behavior on your own. We are
here to help.**
### Trademarks
If you think another npm publisher is infringing your trademark, such as by
using a confusingly similar package name, email <abuse@npmjs.com> with a link to
the package or user account on [https://www.npmjs.com/](https://www.npmjs.com/).
Attach a copy of your trademark registration certificate.
If we see that the package's publisher is intentionally misleading others by
misusing your registered mark without permission, we will transfer the package
name to you. Otherwise, we will contact the package publisher and ask them to
clear up any confusion with changes to their package's `README` file or
metadata.
### Changes
This is a living document and may be updated from time to time. Please refer to
the [git history for this document](https://github.com/npm/cli/commits/latest/doc/misc/npm-disputes.md)
to view the changes.
### License
Copyright (C) npm, Inc., All rights reserved
This document may be reused under a Creative Commons Attribution-ShareAlike
License.
### See also
* [npm registry](/using-npm/registry)
* [npm owner](/cli-commands/npm-owner)

97
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/using-npm/orgs.md generated vendored Normal file
View File

@ -0,0 +1,97 @@
---
section: using-npm
title: orgs
description: Working with Teams & Orgs
---
# orgs(7)
## Working with Teams & Orgs
### Description
There are three levels of org users:
1. Super admin, controls billing & adding people to the org.
2. Team admin, manages team membership & package access.
3. Developer, works on packages they are given access to.
The super admin is the only person who can add users to the org because it impacts the monthly bill. The super admin will use the website to manage membership. Every org has a `developers` team that all users are automatically added to.
The team admin is the person who manages team creation, team membership, and package access for teams. The team admin grants package access to teams, not individuals.
The developer will be able to access packages based on the teams they are on. Access is either read-write or read-only.
There are two main commands:
1. `npm team` see [npm team](/cli-commands/npm-team) for more details
2. `npm access` see [npm access](/cli-commands/npm-access) for more details
### Team Admins create teams
* Check who you’ve added to your org:
```bash
npm team ls <org>:developers
```
* Each org is automatically given a `developers` team, so you can see the whole list of team members in your org. This team automatically gets read-write access to all packages, but you can change that with the `access` command.
* Create a new team:
```bash
npm team create <org:team>
```
* Add members to that team:
```bash
npm team add <org:team> <user>
```
### Publish a package and adjust package access
* In package directory, run
```bash
npm init --scope=<org>
```
to scope it for your org & publish as usual
* Grant access:
```bash
npm access grant <read-only|read-write> <org:team> [<package>]
```
* Revoke access:
```bash
npm access revoke <org:team> [<package>]
```
### Monitor your package access
* See what org packages a team member can access:
```bash
npm access ls-packages <org> <user>
```
* See packages available to a specific team:
```bash
npm access ls-packages <org:team>
```
* Check which teams are collaborating on a package:
```bash
npm access ls-collaborators <pkg>
```
### See also
* [npm team](/cli-commands/npm-team)
* [npm access](/cli-commands/npm-access)
* [npm scope](/using-npm/scope)

107
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/using-npm/registry.md generated vendored Normal file
View File

@ -0,0 +1,107 @@
---
section: using-npm
title: registry
description: The JavaScript Package Registry
---
# registry(7)
## The JavaScript Package Registry
### Description
To resolve packages by name and version, npm talks to a registry website
that implements the CommonJS Package Registry specification for reading
package info.
npm is configured to use npm, Inc.'s public registry at
<https://registry.npmjs.org> by default. Use of the npm public registry is
subject to terms of use available at <https://www.npmjs.com/policies/terms>.
You can configure npm to use any compatible registry you like, and even run
your own registry. Use of someone else's registry may be governed by their
terms of use.
npm's package registry implementation supports several
write APIs as well, to allow for publishing packages and managing user
account information.
The npm public registry is powered by a CouchDB database,
of which there is a public mirror at
<https://skimdb.npmjs.com/registry>. The code for the couchapp is
available at <https://github.com/npm/npm-registry-couchapp>.
The registry URL used is determined by the scope of the package (see
[`scope`](/using-npm/scope). If no scope is specified, the default registry is used, which is
supplied by the `registry` config parameter. See [`npm config`](/cli-commands/npm-config),
[`npmrc`](/configuring-npm/npmrc), and [`config`](/using-npm/config) for more on managing npm's configuration.
### Does npm send any information about me back to the registry?
Yes.
When making requests of the registry npm adds two headers with information
about your environment:
* `Npm-Scope` – If your project is scoped, this header will contain its
scope. In the future npm hopes to build registry features that use this
information to allow you to customize your experience for your
organization.
* `Npm-In-CI` – Set to "true" if npm believes this install is running in a
continuous integration environment, "false" otherwise. This is detected by
looking for the following environment variables: `CI`, `TDDIUM`,
`JENKINS_URL`, `bamboo.buildKey`. If you'd like to learn more you may find
the [original PR](https://github.com/npm/npm-registry-client/pull/129)
interesting.
This is used to gather better metrics on how npm is used by humans, versus
build farms.
The npm registry does not try to correlate the information in these headers
with any authenticated accounts that may be used in the same requests.
### Can I run my own private registry?
Yes!
The easiest way is to replicate the couch database, and use the same (or
similar) design doc to implement the APIs.
If you set up continuous replication from the official CouchDB, and then
set your internal CouchDB as the registry config, then you'll be able
to read any published packages, in addition to your private ones, and by
default will only publish internally.
If you then want to publish a package for the whole world to see, you can
simply override the `--registry` option for that `publish` command.
### I don't want my package published in the official registry. It's private.
Set `"private": true` in your package.json to prevent it from being
published at all, or
`"publishConfig":{"registry":"http://my-internal-registry.local"}`
to force it to be published only to your internal registry.
See [`package.json`](/configuring-npm/package-json) for more info on what goes in the package.json file.
### Will you replicate from my registry into the public one?
No. If you want things to be public, then publish them into the public
registry using npm. What little security there is would be for nought
otherwise.
### Do I have to use couchdb to build a registry that npm can talk to?
No, but it's way easier. Basically, yes, you do, or you have to
effectively implement the entire CouchDB API anyway.
### Is there a website or something to see package docs and such?
Yes, head over to <https://www.npmjs.com/>
### See also
* [npm config](/cli-commands/npm-config)
* [config](/using-npm/config)
* [npmrc](/configuring-npm/npmrc)
* [npm developers](/using-npm/developers)
* [npm disputes](/using-npm/disputes)

70
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/using-npm/removal.md generated vendored Normal file
View File

@ -0,0 +1,70 @@
---
section: using-npm
title: removal
description: Cleaning the Slate
---
# removal(7)
## Cleaning the Slate
### Synopsis
So sad to see you go.
```bash
sudo npm uninstall npm -g
```
Or, if that fails, get the npm source code, and do:
```bash
sudo make uninstall
```
### More Severe Uninstalling
Usually, the above instructions are sufficient. That will remove
npm, but leave behind anything you've installed.
If that doesn't work, or if you require more drastic measures,
continue reading.
Note that this is only necessary for globally-installed packages. Local
installs are completely contained within a project's `node_modules`
folder. Delete that folder, and everything is gone less a package's
install script is particularly ill-behaved).
This assumes that you installed node and npm in the default place. If
you configured node with a different `--prefix`, or installed npm with a
different prefix setting, then adjust the paths accordingly, replacing
`/usr/local` with your install prefix.
To remove everything npm-related manually:
```bash
rm -rf /usr/local/{lib/node{,/.npm,_modules},bin,share/man}/npm*
```
If you installed things *with* npm, then your best bet is to uninstall
them with npm first, and then install them again once you have a
proper install. This can help find any symlinks that are lying
around:
```bash
ls -laF /usr/local/{lib/node{,/.npm},bin,share/man} | grep npm
```
Prior to version 0.3, npm used shim files for executables and node
modules. To track those down, you can do the following:
```bash
find /usr/local/{lib/node,bin} -exec grep -l npm \{\} \; ;
```
(This is also in the README file.)
### See also
* [npm uninstall](/cli-commands/npm-uninstall)
* [npm prune](/cli-commands/npm-prune)

131
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/using-npm/scope.md generated vendored Normal file
View File

@ -0,0 +1,131 @@
---
section: using-npm
title: scope
description: Scoped packages
---
# scope(7)
## Scoped packages
### Description
All npm packages have a name. Some package names also have a scope. A scope
follows the usual rules for package names (URL-safe characters, no leading dots
or underscores). When used in package names, scopes are preceded by an `@` symbol
and followed by a slash, e.g.
```bash
@somescope/somepackagename
```
Scopes are a way of grouping related packages together, and also affect a few
things about the way npm treats the package.
Each npm user/organization has their own scope, and only you can add packages
in your scope. This means you don't have to worry about someone taking your
package name ahead of you. Thus it is also a good way to signal official packages
for organizations.
Scoped packages can be published and installed as of `npm@2` and are supported
by the primary npm registry. Unscoped packages can depend on scoped packages and
vice versa. The npm client is backwards-compatible with unscoped registries,
so it can be used to work with scoped and unscoped registries at the same time.
### Installing scoped packages
Scoped packages are installed to a sub-folder of the regular installation
folder, e.g. if your other packages are installed in `node_modules/packagename`,
scoped modules will be installed in `node_modules/@myorg/packagename`. The scope
folder (`@myorg`) is simply the name of the scope preceded by an `@` symbol, and can
contain any number of scoped packages.
A scoped package is installed by referencing it by name, preceded by an
`@` symbol, in `npm install`:
```bash
npm install @myorg/mypackage
```
Or in `package.json`:
```json
"dependencies": {
"@myorg/mypackage": "^1.3.0"
}
```
Note that if the `@` symbol is omitted, in either case, npm will instead attempt to
install from GitHub; see [`npm install`](/cli-commands/npm-install).
### Requiring scoped packages
Because scoped packages are installed into a scope folder, you have to
include the name of the scope when requiring them in your code, e.g.
```javascript
require('@myorg/mypackage')
```
There is nothing special about the way Node treats scope folders. This
simply requires the `mypackage` module in the folder named `@myorg`.
### Publishing scoped packages
Scoped packages can be published from the CLI as of `npm@2` and can be
published to any registry that supports them, including the primary npm
registry.
(As of 2015-04-19, and with npm 2.0 or better, the primary npm registry
**does** support scoped packages.)
If you wish, you may associate a scope with a registry; see below.
#### Publishing public scoped packages to the primary npm registry
To publish a public scoped package, you must specify `--access public` with
the initial publication. This will publish the package and set access
to `public` as if you had run `npm access public` after publishing.
#### Publishing private scoped packages to the npm registry
To publish a private scoped package to the npm registry, you must have
an [npm Private Modules](https://docs.npmjs.com/private-modules/intro)
account.
You can then publish the module with `npm publish` or `npm publish
--access restricted`, and it will be present in the npm registry, with
restricted access. You can then change the access permissions, if
desired, with `npm access` or on the npmjs.com website.
### Associating a scope with a registry
Scopes can be associated with a separate registry. This allows you to
seamlessly use a mix of packages from the primary npm registry and one or more
private registries, such as npm Enterprise.
You can associate a scope with a registry at login, e.g.
```bash
npm login --registry=http://reg.example.com --scope=@myco
```
Scopes have a many-to-one relationship with registries: one registry can
host multiple scopes, but a scope only ever points to one registry.
You can also associate a scope with a registry using `npm config`:
```bash
npm config set @myco:registry http://reg.example.com
```
Once a scope is associated with a registry, any `npm install` for a package
with that scope will request packages from that registry instead. Any
`npm publish` for a package name that contains the scope will be published to
that registry instead.
### See also
* [npm install](/cli-commands/npm-install)
* [npm publish](/cli-commands/npm-publish)
* [npm access](/cli-commands/npm-access)
* [npm registry](/using-npm/registry)

310
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/using-npm/scripts.md generated vendored Normal file
View File

@ -0,0 +1,310 @@
---
section: using-npm
title: scripts
description: How npm handles the "scripts" field
---
# scripts(7)
## How npm handles the "scripts" field
### Description
The `"scripts"` property of of your `package.json` file supports a number of built-in scripts and their preset life cycle events as well as arbitrary scripts. These all can be executed by running `npm run-script <stage>` or `npm run <stage>` for short. *Pre* and *post* commands with matching names will be run for those as well (e.g. `premyscript`, `myscript`, `postmyscript`). Scripts from dependencies can be run with `npm explore <pkg> -- npm run <stage>`.
### Pre & Post Scripts
To create "pre" or "post" scripts for any scripts defined in the `"scripts"` section of the `package.json`, simply create another script *with a matching name* and add "pre" or "post" to the beginning of them.
```json
{
"scripts": {
"precompress": "{{ executes BEFORE the `compress` script }}",
"compress": "{{ run command to compress files }}",
"postcompress": "{{ executes AFTER `compress` script }}"
}
}
```
### Life Cycle Scripts
There are some special life cycle scripts that happen only in certain situations. These scripts happen in addtion to the "pre" and "post" script.
* `prepare`, `prepublish`, `prepublishOnly`, `prepack`, `postpack`
**prepare** (since `npm@4.0.0`)
* Runs BEFORE the package is packed
* Runs BEFORE the package is published
* Runs on local `npm install` without any arguments
* Run AFTER `prepublish`, but BEFORE `prepublishOnly`
* NOTE: If a package being installed through git contains a `prepare` script, its `dependencies` and `devDependencies` will be installed, and the prepare script will be run, before the package is packaged and installed.
**prepublish** (DEPRECATED)
* Same as `prepare`
**prepublishOnly**
* Runs BEFORE the package is prepared and packed, ONLY on `npm publish`.
**prepack**
* Runs BEFORE a tarball is packed (on "`npm pack`", "`npm publish`", and when installing a git dependencies).
* NOTE: "`npm run pack`" is NOT the same as "`npm pack`". "`npm run pack`" is an arbitrary user defined script name, where as, "`npm pack`" is a CLI defined command.
**postpack**
* Runs AFTER the tarball has been generated and moved to its final destination.
#### Prepare and Prepublish
**Deprecation Note: prepublish**
Since `npm@1.1.71`, the npm CLI has run the `prepublish` script for both `npm publish` and `npm install`, because it's a convenient way to prepare a package for use (some common use cases are described in the section below). It has also turned out to be, in practice, [very confusing](https://github.com/npm/npm/issues/10074). As of `npm@4.0.0`, a new event has been introduced, `prepare`, that preserves this existing behavior. A _new_ event, `prepublishOnly` has been added as a transitional strategy to allow users to avoid the confusing behavior of existing npm versions and only run on `npm publish` (for instance, running the tests one last time to ensure they're in good shape).
See <https://github.com/npm/npm/issues/10074> for a much lengthier justification, with further reading, for this change.
**Use Cases**
If you need to perform operations on your package before it is used, in a way that is not dependent on the operating system or architecture of the target system, use a `prepublish` script. This includes tasks such as:
* Compiling CoffeeScript source code into JavaScript.
* Creating minified versions of JavaScript source code.
* Fetching remote resources that your package will use.
The advantage of doing these things at `prepublish` time is that they can be done once, in a single place, thus reducing complexity and variability. Additionally, this means that:
* You can depend on `coffee-script` as a `devDependency`, and thus
your users don't need to have it installed.
* You don't need to include minifiers in your package, reducing
the size for your users.
* You don't need to rely on your users having `curl` or `wget` or
other system tools on the target machines.
### Life Cycle Operation Order
#### [`npm publish`](/cli-commands/npm-publish)
* `prepublishOnly`
* `prepare`
* `prepublish`
* `publish`
* `postpublish`
#### [`npm pack`](/cli-commands/npm-pack)
* `prepack`
* `postpack`
#### [`npm install`](/cli-commands/npm-install)
* `preinstall`
* `install`
* `postinstall`
Also triggers
* `prepublish` (when on local)
* `prepare` (when on local)
#### [`npm start`](/cli-commands/npm-start)
`npm run start` has an `npm start` shorthand.
* `prestart`
* `start`
* `poststart`
### Default Values
npm will default some script values based on package contents.
* `"start": "node server.js"`:
If there is a `server.js` file in the root of your package, then npm
will default the `start` command to `node server.js`.
* `"install": "node-gyp rebuild"`:
If there is a `binding.gyp` file in the root of your package and you
haven't defined your own `install` or `preinstall` scripts, npm will
default the `install` command to compile using node-gyp.
### User
If npm was invoked with root privileges, then it will change the uid
to the user account or uid specified by the `user` config, which
defaults to `nobody`. Set the `unsafe-perm` flag to run scripts with
root privileges.
### Environment
Package scripts run in an environment where many pieces of information
are made available regarding the setup of npm and the current state of
the process.
#### path
If you depend on modules that define executable scripts, like test
suites, then those executables will be added to the `PATH` for
executing the scripts. So, if your package.json has this:
```json
{
"name" : "foo",
"dependencies" : {
"bar" : "0.1.x"
},
"scripts": {
"start" : "bar ./test"
}
}
```
then you could run `npm start` to execute the `bar` script, which is
exported into the `node_modules/.bin` directory on `npm install`.
#### package.json vars
The package.json fields are tacked onto the `npm_package_` prefix. So,
for instance, if you had `{"name":"foo", "version":"1.2.5"}` in your
package.json file, then your package scripts would have the
`npm_package_name` environment variable set to "foo", and the
`npm_package_version` set to "1.2.5". You can access these variables
in your code with `process.env.npm_package_name` and
`process.env.npm_package_version`, and so on for other fields.
#### configuration
Configuration parameters are put in the environment with the
`npm_config_` prefix. For instance, you can view the effective `root`
config by checking the `npm_config_root` environment variable.
#### Special: package.json "config" object
The package.json "config" keys are overwritten in the environment if
there is a config param of `<name>[@<version>]:<key>`. For example,
if the package.json has this:
```json
{
"name" : "foo",
"config" : {
"port" : "8080"
},
"scripts" : {
"start" : "node server.js"
}
}
```
and the server.js is this:
```javascript
http.createServer(...).listen(process.env.npm_package_config_port)
```
then the user could change the behavior by doing:
```bash
npm config set foo:port 80
```
#### current lifecycle event
Lastly, the `npm_lifecycle_event` environment variable is set to
whichever stage of the cycle is being executed. So, you could have a
single script used for different parts of the process which switches
based on what's currently happening.
Objects are flattened following this format, so if you had
`{"scripts":{"install":"foo.js"}}` in your package.json, then you'd
see this in the script:
```bash
process.env.npm_package_scripts_install === "foo.js"
```
### Examples
For example, if your package.json contains this:
```json
{
"scripts" : {
"install" : "scripts/install.js",
"postinstall" : "scripts/install.js",
"uninstall" : "scripts/uninstall.js"
}
}
```
then `scripts/install.js` will be called for the install
and post-install stages of the lifecycle, and `scripts/uninstall.js`
will be called when the package is uninstalled. Since
`scripts/install.js` is running for two different phases, it would
be wise in this case to look at the `npm_lifecycle_event` environment
variable.
If you want to run a make command, you can do so. This works just
fine:
```json
{
"scripts" : {
"preinstall" : "./configure",
"install" : "make && make install",
"test" : "make test"
}
}
```
### Exiting
Scripts are run by passing the line as a script argument to `sh`.
If the script exits with a code other than 0, then this will abort the
process.
Note that these script files don't have to be nodejs or even
javascript programs. They just have to be some kind of executable
file.
### Hook Scripts
If you want to run a specific script at a specific lifecycle event for
ALL packages, then you can use a hook script.
Place an executable file at `node_modules/.hooks/{eventname}`, and
it'll get run for all packages when they are going through that point
in the package lifecycle for any packages installed in that root.
Hook scripts are run exactly the same way as package.json scripts.
That is, they are in a separate child process, with the env described
above.
### Best Practices
* Don't exit with a non-zero error code unless you *really* mean it.
Except for uninstall scripts, this will cause the npm action to
fail, and potentially be rolled back. If the failure is minor or
only will prevent some optional features, then it's better to just
print a warning and exit successfully.
* Try not to use scripts to do what npm can do for you. Read through
[`package.json`](/configuring-npm/package-json) to see all the things that you can specify and enable
by simply describing your package appropriately. In general, this
will lead to a more robust and consistent state.
* Inspect the env to determine where to put things. For instance, if
the `npm_config_binroot` environment variable is set to `/home/user/bin`, then
don't try to install executables into `/usr/local/bin`. The user
probably set it up that way for a reason.
* Don't prefix your script commands with "sudo". If root permissions
are required for some reason, then it'll fail with that error, and
the user will sudo the npm command in question.
* Don't use `install`. Use a `.gyp` file for compilation, and `prepublish`
for anything else. You should almost never have to explicitly set a
preinstall or install script. If you are doing this, please consider if
there is another option. The only valid use of `install` or `preinstall`
scripts is for compilation which must be done on the target architecture.
### See Also
* [npm run-script](/cli-commands/npm-run-script)
* [package.json](/configuring-npm/package-json)
* [npm developers](/using-npm/developers)
* [npm install](/cli-commands/npm-install)

418
builder-docker/jenkins/node-v12.22.8-linux-x64/lib/node_modules/npm/docs/content/using-npm/semver.md generated vendored Normal file
View File

@ -0,0 +1,418 @@
---
section: using-npm
title: semver
description: The semantic versioner for npm
---
semver(7) -- The semantic versioner for npm
===========================================
## Install
```bash
npm install --save semver
````
## Usage
As a node module:
```js
const semver = require('semver')
semver.valid('1.2.3') // '1.2.3'
semver.valid('a.b.c') // null
semver.clean(' =v1.2.3 ') // '1.2.3'
semver.satisfies('1.2.3', '1.x || >=2.5.0 || 5.0.0 - 7.2.3') // true
semver.gt('1.2.3', '9.8.7') // false
semver.lt('1.2.3', '9.8.7') // true
semver.minVersion('>=1.0.0') // '1.0.0'
semver.valid(semver.coerce('v2')) // '2.0.0'
semver.valid(semver.coerce('42.6.7.9.3-alpha')) // '42.6.7'
```
As a command-line utility:
```
$ semver -h
A JavaScript implementation of the https://semver.org/ specification
Copyright Isaac Z. Schlueter
Usage: semver [options] <version> [<version> [...]]
Prints valid versions sorted by SemVer precedence
Options:
-r --range <range>
Print versions that match the specified range.
-i --increment [<level>]
Increment a version by the specified level. Level can
be one of: major, minor, patch, premajor, preminor,
prepatch, or prerelease. Default level is 'patch'.
Only one version may be specified.
--preid <identifier>
Identifier to be used to prefix premajor, preminor,
prepatch or prerelease version increments.
-l --loose
Interpret versions and ranges loosely
-p --include-prerelease
Always include prerelease versions in range matching
-c --coerce
Coerce a string into SemVer if possible
(does not imply --loose)
Program exits successfully if any valid version satisfies
all supplied ranges, and prints all satisfying versions.
If no satisfying versions are found, then exits failure.
Versions are printed in ascending order, so supplying
multiple versions to the utility will just sort them.
```
## Versions
A "version" is described by the `v2.0.0` specification found at
<https://semver.org/>.
A leading `"="` or `"v"` character is stripped off and ignored.
## Ranges
A `version range` is a set of `comparators` which specify versions
that satisfy the range.
A `comparator` is composed of an `operator` and a `version`. The set
of primitive `operators` is:
* `<` Less than
* `<=` Less than or equal to
* `>` Greater than
* `>=` Greater than or equal to
* `=` Equal. If no operator is specified, then equality is assumed,
so this operator is optional, but MAY be included.
For example, the comparator `>=1.2.7` would match the versions
`1.2.7`, `1.2.8`, `2.5.3`, and `1.3.9`, but not the versions `1.2.6`
or `1.1.0`.
Comparators can be joined by whitespace to form a `comparator set`,
which is satisfied by the **intersection** of all of the comparators
it includes.
A range is composed of one or more comparator sets, joined by `||`. A
version matches a range if and only if every comparator in at least
one of the `||`-separated comparator sets is satisfied by the version.
For example, the range `>=1.2.7 <1.3.0` would match the versions
`1.2.7`, `1.2.8`, and `1.2.99`, but not the versions `1.2.6`, `1.3.0`,
or `1.1.0`.
The range `1.2.7 || >=1.2.9 <2.0.0` would match the versions `1.2.7`,
`1.2.9`, and `1.4.6`, but not the versions `1.2.8` or `2.0.0`.
### Prerelease Tags
If a version has a prerelease tag (for example, `1.2.3-alpha.3`) then
it will only be allowed to satisfy comparator sets if at least one
comparator with the same `[major, minor, patch]` tuple also has a
prerelease tag.
For example, the range `>1.2.3-alpha.3` would be allowed to match the
version `1.2.3-alpha.7`, but it would *not* be satisfied by
`3.4.5-alpha.9`, even though `3.4.5-alpha.9` is technically "greater
than" `1.2.3-alpha.3` according to the SemVer sort rules. The version
range only accepts prerelease tags on the `1.2.3` version. The
version `3.4.5` *would* satisfy the range, because it does not have a
prerelease flag, and `3.4.5` is greater than `1.2.3-alpha.7`.
The purpose for this behavior is twofold. First, prerelease versions
frequently are updated very quickly, and contain many breaking changes
that are (by the author's design) not yet fit for public consumption.
Therefore, by default, they are excluded from range matching
semantics.
Second, a user who has opted into using a prerelease version has
clearly indicated the intent to use *that specific* set of
alpha/beta/rc versions. By including a prerelease tag in the range,
the user is indicating that they are aware of the risk. However, it
is still not appropriate to assume that they have opted into taking a
similar risk on the *next* set of prerelease versions.
Note that this behavior can be suppressed (treating all prerelease
versions as if they were normal versions, for the purpose of range
matching) by setting the `includePrerelease` flag on the options
object to any
[functions](https://github.com/npm/node-semver#functions) that do
range matching.
#### Prerelease Identifiers
The method `.inc` takes an additional `identifier` string argument that
will append the value of the string as a prerelease identifier:
```javascript
semver.inc('1.2.3', 'prerelease', 'beta')
// '1.2.4-beta.0'
```
command-line example:
```bash
$ semver 1.2.3 -i prerelease --preid beta
1.2.4-beta.0
```
Which then can be used to increment further:
```bash
$ semver 1.2.4-beta.0 -i prerelease
1.2.4-beta.1
```
### Advanced Range Syntax
Advanced range syntax desugars to primitive comparators in
deterministic ways.
Advanced ranges may be combined in the same way as primitive
comparators using white space or `||`.
#### Hyphen Ranges `X.Y.Z - A.B.C`
Specifies an inclusive set.
* `1.2.3 - 2.3.4` := `>=1.2.3 <=2.3.4`
If a partial version is provided as the first version in the inclusive
range, then the missing pieces are replaced with zeroes.
* `1.2 - 2.3.4` := `>=1.2.0 <=2.3.4`
If a partial version is provided as the second version in the
inclusive range, then all versions that start with the supplied parts
of the tuple are accepted, but nothing that would be greater than the
provided tuple parts.
* `1.2.3 - 2.3` := `>=1.2.3 <2.4.0`
* `1.2.3 - 2` := `>=1.2.3 <3.0.0`
#### X-Ranges `1.2.x` `1.X` `1.2.*` `*`
Any of `X`, `x`, or `*` may be used to "stand in" for one of the
numeric values in the `[major, minor, patch]` tuple.
* `*` := `>=0.0.0` (Any version satisfies)
* `1.x` := `>=1.0.0 <2.0.0` (Matching major version)
* `1.2.x` := `>=1.2.0 <1.3.0` (Matching major and minor versions)
A partial version range is treated as an X-Range, so the special
character is in fact optional.
* `""` (empty string) := `*` := `>=0.0.0`
* `1` := `1.x.x` := `>=1.0.0 <2.0.0`
* `1.2` := `1.2.x` := `>=1.2.0 <1.3.0`
#### Tilde Ranges `~1.2.3` `~1.2` `~1`
Allows patch-level changes if a minor version is specified on the
comparator. Allows minor-level changes if not.
* `~1.2.3` := `>=1.2.3 <1.(2+1).0` := `>=1.2.3 <1.3.0`
* `~1.2` := `>=1.2.0 <1.(2+1).0` := `>=1.2.0 <1.3.0` (Same as `1.2.x`)
* `~1` := `>=1.0.0 <(1+1).0.0` := `>=1.0.0 <2.0.0` (Same as `1.x`)
* `~0.2.3` := `>=0.2.3 <0.(2+1).0` := `>=0.2.3 <0.3.0`
* `~0.2` := `>=0.2.0 <0.(2+1).0` := `>=0.2.0 <0.3.0` (Same as `0.2.x`)
* `~0` := `>=0.0.0 <(0+1).0.0` := `>=0.0.0 <1.0.0` (Same as `0.x`)
* `~1.2.3-beta.2` := `>=1.2.3-beta.2 <1.3.0` Note that prereleases in
the `1.2.3` version will be allowed, if they are greater than or
equal to `beta.2`. So, `1.2.3-beta.4` would be allowed, but
`1.2.4-beta.2` would not, because it is a prerelease of a
different `[major, minor, patch]` tuple.
#### Caret Ranges `^1.2.3` `^0.2.5` `^0.0.4`
Allows changes that do not modify the left-most non-zero digit in the
`[major, minor, patch]` tuple. In other words, this 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`.
Many authors treat a `0.x` version as if the `x` were the major
"breaking-change" indicator.
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.
* `^1.2.3` := `>=1.2.3 <2.0.0`
* `^0.2.3` := `>=0.2.3 <0.3.0`
* `^0.0.3` := `>=0.0.3 <0.0.4`
* `^1.2.3-beta.2` := `>=1.2.3-beta.2 <2.0.0` Note that prereleases in
the `1.2.3` version will be allowed, if they are greater than or
equal to `beta.2`. So, `1.2.3-beta.4` would be allowed, but
`1.2.4-beta.2` would not, because it is a prerelease of a
different `[major, minor, patch]` tuple.
* `^0.0.3-beta` := `>=0.0.3-beta <0.0.4` Note that prereleases in the
`0.0.3` version *only* will be allowed, if they are greater than or
equal to `beta`. So, `0.0.3-pr.2` would be allowed.
When parsing caret ranges, a missing `patch` value desugars to the
number `0`, but will allow flexibility within that value, even if the
major and minor versions are both `0`.
* `^1.2.x` := `>=1.2.0 <2.0.0`
* `^0.0.x` := `>=0.0.0 <0.1.0`
* `^0.0` := `>=0.0.0 <0.1.0`
A missing `minor` and `patch` values will desugar to zero, but also
allow flexibility within those values, even if the major version is
zero.
* `^1.x` := `>=1.0.0 <2.0.0`
* `^0.x` := `>=0.0.0 <1.0.0`
### Range Grammar
Putting all this together, here is a Backus-Naur grammar for ranges,
for the benefit of parser authors:
```bnf
range-set ::= range ( logical-or range ) *
logical-or ::= ( ' ' ) * '||' ( ' ' ) *
range ::= hyphen | simple ( ' ' simple ) * | ''
hyphen ::= partial ' - ' partial
simple ::= primitive | partial | tilde | caret
primitive ::= ( '<' | '>' | '>=' | '<=' | '=' ) partial
partial ::= xr ( '.' xr ( '.' xr qualifier ? )? )?
xr ::= 'x' | 'X' | '*' | nr
nr ::= '0' | ['1'-'9'] ( ['0'-'9'] ) *
tilde ::= '~' partial
caret ::= '^' partial
qualifier ::= ( '-' pre )? ( '+' build )?
pre ::= parts
build ::= parts
parts ::= part ( '.' part ) *
part ::= nr | [-0-9A-Za-z]+
```
## Functions
All methods and classes take a final `options` object argument. All
options in this object are `false` by default. The options supported
are:
- `loose` Be more forgiving about not-quite-valid semver strings.
(Any resulting output will always be 100% strict compliant, of
course.) For backwards compatibility reasons, if the `options`
argument is a boolean value instead of an object, it is interpreted
to be the `loose` param.
- `includePrerelease` Set to suppress the [default
behavior](https://github.com/npm/node-semver#prerelease-tags) of
excluding prerelease tagged versions from ranges unless they are
explicitly opted into.
Strict-mode Comparators and Ranges will be strict about the SemVer
strings that they parse.
* `valid(v)`: Return the parsed version, or null if it's not valid.
* `inc(v, release)`: Return the version incremented by the release
type (`major`, `premajor`, `minor`, `preminor`, `patch`,
`prepatch`, or `prerelease`), or null if it's not valid
* `premajor` in one call will bump the version up to the next major
version and down to a prerelease of that major version.
`preminor`, and `prepatch` work the same way.
* If called from a non-prerelease version, the `prerelease` will work the
same as `prepatch`. It increments the patch version, then makes a
prerelease. If the input version is already a prerelease it simply
increments it.
* `prerelease(v)`: Returns an array of prerelease components, or null
if none exist. Example: `prerelease('1.2.3-alpha.1') -> ['alpha', 1]`
* `major(v)`: Return the major version number.
* `minor(v)`: Return the minor version number.
* `patch(v)`: Return the patch version number.
* `intersects(r1, r2, loose)`: Return true if the two supplied ranges
or comparators intersect.
* `parse(v)`: Attempt to parse a string as a semantic version, returning either
a `SemVer` object or `null`.
### Comparison
* `gt(v1, v2)`: `v1 > v2`
* `gte(v1, v2)`: `v1 >= v2`
* `lt(v1, v2)`: `v1 < v2`
* `lte(v1, v2)`: `v1 <= v2`
* `eq(v1, v2)`: `v1 == v2` This is true if they're logically equivalent,
even if they're not the exact same string. You already know how to
compare strings.
* `neq(v1, v2)`: `v1 != v2` The opposite of `eq`.
* `cmp(v1, comparator, v2)`: Pass in a comparison string, and it'll call
the corresponding function above. `"==="` and `"!=="` do simple
string comparison, but are included for completeness. Throws if an
invalid comparison string is provided.
* `compare(v1, v2)`: Return `0` if `v1 == v2`, or `1` if `v1` is greater, or `-1` if
`v2` is greater. Sorts in ascending order if passed to `Array.sort()`.
* `rcompare(v1, v2)`: The reverse of compare. Sorts an array of versions
in descending order when passed to `Array.sort()`.
* `diff(v1, v2)`: Returns difference between two versions by the release type
(`major`, `premajor`, `minor`, `preminor`, `patch`, `prepatch`, or `prerelease`),
or null if the versions are the same.
### Comparators
* `intersects(comparator)`: Return true if the comparators intersect
### Ranges
* `validRange(range)`: Return the valid range or null if it's not valid
* `satisfies(version, range)`: Return true if the version satisfies the
range.
* `maxSatisfying(versions, range)`: Return the highest version in the list
that satisfies the range, or `null` if none of them do.
* `minSatisfying(versions, range)`: Return the lowest version in the list
that satisfies the range, or `null` if none of them do.
* `minVersion(range)`: Return the lowest version that can possibly match
the given range.
* `gtr(version, range)`: Return `true` if version is greater than all the
versions possible in the range.
* `ltr(version, range)`: Return `true` if version is less than all the
versions possible in the range.
* `outside(version, range, hilo)`: Return true if the version is outside
the bounds of the range in either the high or low direction. The
`hilo` argument must be either the string `'>'` or `'<'`. (This is
the function called by `gtr` and `ltr`.)
* `intersects(range)`: Return true if any of the ranges comparators intersect
Note that, since ranges may be non-contiguous, a version might not be
greater than a range, less than a range, *or* satisfy a range! For
example, the range `1.2 <1.2.9 || >2.0.0` would have a hole from `1.2.9`
until `2.0.0`, so the version `1.2.10` would not be greater than the
range (because `2.0.1` satisfies, which is higher), nor less than the
range (since `1.2.8` satisfies, which is lower), and it also does not
satisfy the range.
If you want to know if a version satisfies or does not satisfy a
range, use the `satisfies(version, range)` function.
### Coercion
* `coerce(version)`: Coerces a string to semver if possible
This aims to provide a very forgiving translation of a non-semver string to
semver. It looks for the first digit in a string, and consumes all
remaining characters which satisfy at least a partial semver (e.g., `1`,
`1.2`, `1.2.3`) up to the max permitted length (256 characters). Longer
versions are simply truncated (`4.6.3.9.2-alpha2` becomes `4.6.3`). All
surrounding text is simply ignored (`v3.4 replaces v3.3.1` becomes
`3.4.0`). Only text which lacks digits will fail coercion (`version one`
is not valid). The maximum length for any semver component considered for
coercion is 16 characters; longer components will be ignored
(`10000000000000000.4.7.4` becomes `4.7.4`). The maximum value for any
semver component is `Number.MAX_SAFE_INTEGER || (2**53 - 1)`; higher value
components are invalid (`9999999999999999.4.7.4` is likely invalid).