Removed the Requirement to Install Python and NodeJS (Now Bundled with Borealis)
This commit is contained in:
115
Dependencies/NodeJS/node_modules/npm/man/man1/npm-access.1
generated
vendored
Normal file
115
Dependencies/NodeJS/node_modules/npm/man/man1/npm-access.1
generated
vendored
Normal file
@ -0,0 +1,115 @@
|
||||
.TH "NPM-ACCESS" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-access\fR - Set access level on published packages
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm access list packages \[lB]<user>|<scope>|<scope:team>\[rB] \[lB]<package>\[rB]
|
||||
npm access list collaborators \[lB]<package> \[lB]<user>\[rB]\[rB]
|
||||
npm access get status \[lB]<package>\[rB]
|
||||
npm access set status=public|private \[lB]<package>\[rB]
|
||||
npm access set mfa=none|publish|automation \[lB]<package>\[rB]
|
||||
npm access grant <read-only|read-write> <scope:team> \[lB]<package>\[rB]
|
||||
npm access revoke <scope:team> \[lB]<package>\[rB]
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Description"
|
||||
.P
|
||||
Used to set access controls on private packages.
|
||||
.P
|
||||
For all of the subcommands, \fBnpm access\fR will perform actions on the packages in the current working directory if no package name is passed to the subcommand.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
public / restricted (deprecated): Set a package to be either publicly accessible or restricted.
|
||||
.IP \(bu 4
|
||||
grant / revoke (deprecated): Add or remove the ability of users and teams to have read-only or read-write access to a package.
|
||||
.IP \(bu 4
|
||||
2fa-required / 2fa-not-required (deprecated): Configure whether a package requires that anyone publishing it have two-factor authentication enabled on their account.
|
||||
.IP \(bu 4
|
||||
ls-packages (deprecated): 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)
|
||||
.IP \(bu 4
|
||||
ls-collaborators (deprecated): Show all of the access privileges for a package. Will only show permissions for packages to which you have at least read access. If \fB<user>\fR is passed in, the list is filtered only to teams \fIthat\fR user happens to belong to.
|
||||
.IP \(bu 4
|
||||
edit (not implemented)
|
||||
.RE 0
|
||||
|
||||
.SS "Details"
|
||||
.P
|
||||
\fBnpm access\fR always operates directly on the current registry, configurable from the command line using \fB--registry=<registry url>\fR.
|
||||
.P
|
||||
Unscoped packages are \fIalways public\fR.
|
||||
.P
|
||||
Scoped packages \fIdefault to restricted\fR, but you can either publish them as public using \fBnpm publish --access=public\fR, or set their access as public using \fBnpm access public\fR after the initial publish.
|
||||
.P
|
||||
You must have privileges to set the access of a package:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
You are an owner of an unscoped or scoped package.
|
||||
.IP \(bu 4
|
||||
You are a member of the team that owns a scope.
|
||||
.IP \(bu 4
|
||||
You have been given read-write privileges for a package, either as a member of a team or directly as an owner.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If you have two-factor authentication enabled then you'll be prompted to provide a second factor, or may use the \fB--otp=...\fR option to specify it on the command line.
|
||||
.P
|
||||
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 \fB--access=public\fR.
|
||||
.P
|
||||
Management of teams and team memberships is done with the \fBnpm team\fR command.
|
||||
.SS "Configuration"
|
||||
.SS "\fBjson\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Whether or not to output JSON data, rather than the normal output.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
In \fBnpm pkg set\fR it enables parsing set values with JSON.parse() before saving them to your \fBpackage.json\fR.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Not supported by all npm commands.
|
||||
.SS "\fBotp\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm access\fR.
|
||||
.P
|
||||
If not set, and a registry response fails with a challenge for a one-time password, npm will prompt on the command line for one.
|
||||
.SS "\fBregistry\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "https://registry.npmjs.org/"
|
||||
.IP \(bu 4
|
||||
Type: URL
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The base URL of the npm registry.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
\fB\fBlibnpmaccess\fR\fR \fI\(lahttps://npm.im/libnpmaccess\(ra\fR
|
||||
.IP \(bu 4
|
||||
npm help team
|
||||
.IP \(bu 4
|
||||
npm help publish
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help registry
|
||||
.RE 0
|
||||
91
Dependencies/NodeJS/node_modules/npm/man/man1/npm-adduser.1
generated
vendored
Normal file
91
Dependencies/NodeJS/node_modules/npm/man/man1/npm-adduser.1
generated
vendored
Normal file
@ -0,0 +1,91 @@
|
||||
.TH "NPM-ADDUSER" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-adduser\fR - Add a registry user account
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm adduser
|
||||
|
||||
alias: add-user
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Description"
|
||||
.P
|
||||
Create a new user in the specified registry, and save the credentials to the \fB.npmrc\fR file. If no registry is specified, the default registry will be used (see npm help registry).
|
||||
.P
|
||||
When using \fBlegacy\fR for your \fBauth-type\fR, the username, password, and email are read in from prompts.
|
||||
.SS "Configuration"
|
||||
.SS "\fBregistry\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "https://registry.npmjs.org/"
|
||||
.IP \(bu 4
|
||||
Type: URL
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The base URL of the npm registry.
|
||||
.SS "\fBscope\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: the scope of the current project, if any, or ""
|
||||
.IP \(bu 4
|
||||
Type: String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Associate an operation with a scope for a scoped registry.
|
||||
.P
|
||||
Useful when logging in to or out of a private registry:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
# log in, linking the scope to the custom registry
|
||||
npm login --scope=@mycorp --registry=https://registry.mycorp.com
|
||||
|
||||
# log out, removing the link and the auth token
|
||||
npm logout --scope=@mycorp
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
This will cause \fB@mycorp\fR to be mapped to the registry for future installation of packages specified according to the pattern \fB@mycorp/package\fR.
|
||||
.P
|
||||
This will also cause \fBnpm init\fR to create a scoped package.
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
# accept all defaults, and create a package named "@foo/whatever",
|
||||
# instead of just named "whatever"
|
||||
npm init --scope=@foo --yes
|
||||
.fi
|
||||
.RE
|
||||
.SS "\fBauth-type\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "web"
|
||||
.IP \(bu 4
|
||||
Type: "legacy" or "web"
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
What authentication strategy to use with \fBlogin\fR. Note that if an \fBotp\fR config is given, this value will always be set to \fBlegacy\fR.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help registry
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help npmrc
|
||||
.IP \(bu 4
|
||||
npm help owner
|
||||
.IP \(bu 4
|
||||
npm help whoami
|
||||
.IP \(bu 4
|
||||
npm help token
|
||||
.IP \(bu 4
|
||||
npm help profile
|
||||
.RE 0
|
||||
448
Dependencies/NodeJS/node_modules/npm/man/man1/npm-audit.1
generated
vendored
Normal file
448
Dependencies/NodeJS/node_modules/npm/man/man1/npm-audit.1
generated
vendored
Normal file
@ -0,0 +1,448 @@
|
||||
.TH "NPM-AUDIT" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-audit\fR - Run a security audit
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm audit \[lB]fix|signatures\[rB]
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
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. If any vulnerabilities are found, then the impact and appropriate remediation will be calculated. If the \fBfix\fR argument is provided, then remediations will be applied to the package tree.
|
||||
.P
|
||||
The command will exit with a 0 exit code if no vulnerabilities were found.
|
||||
.P
|
||||
Note that some vulnerabilities cannot be fixed automatically and will require manual intervention or review. Also note that since \fBnpm audit
|
||||
fix\fR runs a full-fledged \fBnpm install\fR under the hood, all configs that apply to the installer will also apply to \fBnpm install\fR -- so things like \fBnpm audit fix --package-lock-only\fR will work as expected.
|
||||
.P
|
||||
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 \fB--audit-level\fR 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.
|
||||
.SS "Package lock"
|
||||
.P
|
||||
By default npm requires a package-lock or shrinkwrap in order to run the audit. You can bypass the package lock with \fB--no-package-lock\fR but be aware the results may be different with every run, since npm will re-build the dependency tree each time.
|
||||
.SS "Audit Signatures"
|
||||
.P
|
||||
To ensure the integrity of packages you download from the public npm registry, or any registry that supports signatures, you can verify the registry signatures of downloaded packages using the npm CLI.
|
||||
.P
|
||||
Registry signatures can be verified using the following \fBaudit\fR command:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm audit signatures
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
The \fBaudit signatures\fR command will also verify the provenance attestations of downloaded packages. Because provenance attestations are such a new feature, security features may be added to (or changed in) the attestation format over time. To ensure that you're always able to verify attestation signatures check that you're running the latest version of the npm CLI. Please note this often means updating npm beyond the version that ships with Node.js.
|
||||
.P
|
||||
The npm CLI supports registry signatures and signing keys provided by any registry if the following conventions are followed:
|
||||
.RS 0
|
||||
.IP 1. 4
|
||||
Signatures are provided in the package's \fBpackument\fR in each published version within the \fBdist\fR object:
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
"dist":{
|
||||
"..omitted..": "..omitted..",
|
||||
"signatures": \[lB]{
|
||||
"keyid": "SHA256:{{SHA256_PUBLIC_KEY}}",
|
||||
"sig": "a312b9c3cb4a1b693e8ebac5ee1ca9cc01f2661c14391917dcb111517f72370809..."
|
||||
}\[rB]
|
||||
}
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
See this \fBexample\fR \fI\(lahttps://registry.npmjs.org/light-cycle/1.4.3\(ra\fR of a signed package from the public npm registry.
|
||||
.P
|
||||
The \fBsig\fR is generated using the following template: \fB${package.name}@${package.version}:${package.dist.integrity}\fR and the \fBkeyid\fR has to match one of the public signing keys below.
|
||||
.RS 0
|
||||
.IP 2. 4
|
||||
Public signing keys are provided at \fBregistry-host.tld/-/npm/v1/keys\fR in the following format:
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
{
|
||||
"keys": \[lB]{
|
||||
"expires": null,
|
||||
"keyid": "SHA256:{{SHA256_PUBLIC_KEY}}",
|
||||
"keytype": "ecdsa-sha2-nistp256",
|
||||
"scheme": "ecdsa-sha2-nistp256",
|
||||
"key": "{{B64_PUBLIC_KEY}}"
|
||||
}\[rB]
|
||||
}
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Keys response:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
\fBexpires\fR: null or a simplified extended \fBISO 8601 format\fR \fI\(lahttps://en.wikipedia.org/wiki/ISO_8601\(ra\fR: \fBYYYY-MM-DDTHH:mm:ss.sssZ\fR
|
||||
.IP \(bu 4
|
||||
\fBkeydid\fR: sha256 fingerprint of the public key
|
||||
.IP \(bu 4
|
||||
\fBkeytype\fR: only \fBecdsa-sha2-nistp256\fR is currently supported by the npm CLI
|
||||
.IP \(bu 4
|
||||
\fBscheme\fR: only \fBecdsa-sha2-nistp256\fR is currently supported by the npm CLI
|
||||
.IP \(bu 4
|
||||
\fBkey\fR: base64 encoded public key
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
See this \fBexample key's response from the public npm registry\fR \fI\(lahttps://registry.npmjs.org/-/npm/v1/keys\(ra\fR.
|
||||
.SS "Audit Endpoints"
|
||||
.P
|
||||
There are two audit endpoints that npm may use to fetch vulnerability information: the \fBBulk Advisory\fR endpoint and the \fBQuick Audit\fR endpoint.
|
||||
.SS "Bulk Advisory Endpoint"
|
||||
.P
|
||||
As of version 7, npm uses the much faster \fBBulk Advisory\fR endpoint to optimize the speed of calculating audit results.
|
||||
.P
|
||||
npm will generate a JSON payload with the name and list of versions of each package in the tree, and POST it to the default configured registry at the path \fB/-/npm/v1/security/advisories/bulk\fR.
|
||||
.P
|
||||
Any packages in the tree that do not have a \fBversion\fR field in their package.json file will be ignored. If any \fB--omit\fR options are specified (either via the \fB\fB--omit\fR config\fR \fI\(la/using-npm/config#omit\(ra\fR, or one of the shorthands such as \fB--production\fR, \fB--only=dev\fR, and so on), then packages will be omitted from the submitted payload as appropriate.
|
||||
.P
|
||||
If the registry responds with an error, or with an invalid response, then npm will attempt to load advisory data from the \fBQuick Audit\fR endpoint.
|
||||
.P
|
||||
The expected result will contain a set of advisory objects for each dependency that matches the advisory range. Each advisory object contains a \fBname\fR, \fBurl\fR, \fBid\fR, \fBseverity\fR, \fBvulnerable_versions\fR, and \fBtitle\fR.
|
||||
.P
|
||||
npm then uses these advisory objects to calculate vulnerabilities and meta-vulnerabilities of the dependencies within the tree.
|
||||
.SS "Quick Audit Endpoint"
|
||||
.P
|
||||
If the \fBBulk Advisory\fR endpoint returns an error, or invalid data, npm will attempt to load advisory data from the \fBQuick Audit\fR endpoint, which is considerably slower in most cases.
|
||||
.P
|
||||
The full package tree as found in \fBpackage-lock.json\fR is submitted, along with the following pieces of additional metadata:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
\fBnpm_version\fR
|
||||
.IP \(bu 4
|
||||
\fBnode_version\fR
|
||||
.IP \(bu 4
|
||||
\fBplatform\fR
|
||||
.IP \(bu 4
|
||||
\fBarch\fR
|
||||
.IP \(bu 4
|
||||
\fBnode_env\fR
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
All packages in the tree are submitted to the Quick Audit endpoint. Omitted dependency types are skipped when generating the report.
|
||||
.SS "Scrubbing"
|
||||
.P
|
||||
Out of an abundance of caution, npm versions 5 and 6 would "scrub" any packages from the submitted report if their name contained a \fB/\fR character, so as to avoid leaking the names of potentially private packages or git URLs.
|
||||
.P
|
||||
However, in practice, this resulted in audits often failing to properly detect meta-vulnerabilities, because the tree would appear to be invalid due to missing dependencies, and prevented the detection of vulnerabilities in package trees that used git dependencies or private modules.
|
||||
.P
|
||||
This scrubbing has been removed from npm as of version 7.
|
||||
.SS "Calculating Meta-Vulnerabilities and Remediations"
|
||||
.P
|
||||
npm uses the \fB\fB@npmcli/metavuln-calculator\fR\fR \fI\(lahttp://npm.im/@npmcli/metavuln-calculator\(ra\fR module to turn a set of security advisories into a set of "vulnerability" objects. A "meta-vulnerability" is a dependency that is vulnerable by virtue of dependence on vulnerable versions of a vulnerable package.
|
||||
.P
|
||||
For example, if the package \fBfoo\fR is vulnerable in the range \fB>=1.0.2
|
||||
<2.0.0\fR, and the package \fBbar\fR depends on \fBfoo@^1.1.0\fR, then that version of \fBbar\fR can only be installed by installing a vulnerable version of \fBfoo\fR. In this case, \fBbar\fR is a "metavulnerability".
|
||||
.P
|
||||
Once metavulnerabilities for a given package are calculated, they are cached in the \fB~/.npm\fR folder and only re-evaluated if the advisory range changes, or a new version of the package is published (in which case, the new version is checked for metavulnerable status as well).
|
||||
.P
|
||||
If the chain of metavulnerabilities extends all the way to the root project, and it cannot be updated without changing its dependency ranges, then \fBnpm audit fix\fR will require the \fB--force\fR option to apply the remediation. If remediations do not require changes to the dependency ranges, then all vulnerable packages will be updated to a version that does not have an advisory or metavulnerability posted against it.
|
||||
.SS "Exit Code"
|
||||
.P
|
||||
The \fBnpm audit\fR command will exit with a 0 exit code if no vulnerabilities were found. The \fBnpm audit fix\fR command will exit with 0 exit code if no vulnerabilities are found \fIor\fR if the remediation is able to successfully fix all vulnerabilities.
|
||||
.P
|
||||
If vulnerabilities were found the exit code will depend on the \fB\fBaudit-level\fR config\fR \fI\(la/using-npm/config#audit-level\(ra\fR.
|
||||
.SS "Examples"
|
||||
.P
|
||||
Scan your project for vulnerabilities and automatically install any compatible updates to vulnerable dependencies:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm audit fix
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Run \fBaudit fix\fR without modifying \fBnode_modules\fR, but still updating the pkglock:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm audit fix --package-lock-only
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Skip updating \fBdevDependencies\fR:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm audit fix --only=prod
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Have \fBaudit fix\fR install SemVer-major updates to toplevel dependencies, not just SemVer-compatible ones:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm audit fix --force
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Do a dry run to get an idea of what \fBaudit fix\fR will do, and \fIalso\fR output install information in JSON format:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm audit fix --dry-run --json
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Scan your project for vulnerabilities and just show the details, without fixing anything:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm audit
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Get the detailed audit report in JSON format:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm audit --json
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Fail an audit only if the results include a vulnerability with a level of moderate or higher:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm audit --audit-level=moderate
|
||||
.fi
|
||||
.RE
|
||||
.SS "Configuration"
|
||||
.SS "\fBaudit-level\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null, "info", "low", "moderate", "high", "critical", or "none"
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The minimum level of vulnerability for \fBnpm audit\fR to exit with a non-zero exit code.
|
||||
.SS "\fBdry-run\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, \fBinstall\fR, \fBupdate\fR, \fBdedupe\fR, \fBuninstall\fR, as well as \fBpack\fR and \fBpublish\fR.
|
||||
.P
|
||||
Note: This is NOT honored by other network related commands, eg \fBdist-tags\fR, \fBowner\fR, etc.
|
||||
.SS "\fBforce\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Removes various protections against unfortunate side effects, common mistakes, unnecessary performance degradation, and malicious input.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Allow clobbering non-npm files in global installs.
|
||||
.IP \(bu 4
|
||||
Allow the \fBnpm version\fR command to work on an unclean git repository.
|
||||
.IP \(bu 4
|
||||
Allow deleting the cache folder with \fBnpm cache clean\fR.
|
||||
.IP \(bu 4
|
||||
Allow installing packages that have an \fBengines\fR declaration requiring a different version of npm.
|
||||
.IP \(bu 4
|
||||
Allow installing packages that have an \fBengines\fR declaration requiring a different version of \fBnode\fR, even if \fB--engine-strict\fR is enabled.
|
||||
.IP \(bu 4
|
||||
Allow \fBnpm audit fix\fR to install modules outside your stated dependency range (including SemVer-major changes).
|
||||
.IP \(bu 4
|
||||
Allow unpublishing all versions of a published package.
|
||||
.IP \(bu 4
|
||||
Allow conflicting peerDependencies to be installed in the root project.
|
||||
.IP \(bu 4
|
||||
Implicitly set \fB--yes\fR during \fBnpm init\fR.
|
||||
.IP \(bu 4
|
||||
Allow clobbering existing values in \fBnpm pkg\fR
|
||||
.IP \(bu 4
|
||||
Allow unpublishing of entire packages (not just a single version).
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If you don't have a clear idea of what you want to do, it is strongly recommended that you do not use this option!
|
||||
.SS "\fBjson\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Whether or not to output JSON data, rather than the normal output.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
In \fBnpm pkg set\fR it enables parsing set values with JSON.parse() before saving them to your \fBpackage.json\fR.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Not supported by all npm commands.
|
||||
.SS "\fBpackage-lock-only\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If set to true, the current operation will only use the \fBpackage-lock.json\fR, ignoring \fBnode_modules\fR.
|
||||
.P
|
||||
For \fBupdate\fR this means only the \fBpackage-lock.json\fR will be updated, instead of checking \fBnode_modules\fR and downloading dependencies.
|
||||
.P
|
||||
For \fBlist\fR this means the output will be based on the tree described by the \fBpackage-lock.json\fR, rather than the contents of \fBnode_modules\fR.
|
||||
.SS "\fBpackage-lock\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If set to false, then ignore \fBpackage-lock.json\fR files when installing. This will also prevent \fIwriting\fR \fBpackage-lock.json\fR if \fBsave\fR is true.
|
||||
.SS "\fBomit\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production', otherwise empty.
|
||||
.IP \(bu 4
|
||||
Type: "dev", "optional", or "peer" (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Dependency types to omit from the installation tree on disk.
|
||||
.P
|
||||
Note that these dependencies \fIare\fR still resolved and added to the \fBpackage-lock.json\fR or \fBnpm-shrinkwrap.json\fR file. They are just not physically installed on disk.
|
||||
.P
|
||||
If a package type appears in both the \fB--include\fR and \fB--omit\fR lists, then it will be included.
|
||||
.P
|
||||
If the resulting omit list includes \fB'dev'\fR, then the \fBNODE_ENV\fR environment variable will be set to \fB'production'\fR for all lifecycle scripts.
|
||||
.SS "\fBinclude\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Option that allows for defining which types of dependencies to install.
|
||||
.P
|
||||
This is the inverse of \fB--omit=<type>\fR.
|
||||
.P
|
||||
Dependency types specified in \fB--include\fR will not be omitted, regardless of the order in which omit/include are specified on the command-line.
|
||||
.SS "\fBforeground-scripts\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: \fBfalse\fR unless when using \fBnpm pack\fR or \fBnpm publish\fR where it defaults to \fBtrue\fR
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Run all build scripts (ie, \fBpreinstall\fR, \fBinstall\fR, and \fBpostinstall\fR) scripts for installed packages in the foreground process, sharing standard input, output, and error with the main npm process.
|
||||
.P
|
||||
Note that this will generally make installs run slower, and be much noisier, but can be useful for debugging.
|
||||
.SS "\fBignore-scripts\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If true, npm does not run scripts specified in package.json files.
|
||||
.P
|
||||
Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run-script\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts.
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinclude-workspace-root\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
.P
|
||||
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinstall-links\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set file: protocol dependencies will be packed and installed as regular dependencies instead of creating a symlink. This option has no effect on workspaces.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help install
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.RE 0
|
||||
115
Dependencies/NodeJS/node_modules/npm/man/man1/npm-bugs.1
generated
vendored
Normal file
115
Dependencies/NodeJS/node_modules/npm/man/man1/npm-bugs.1
generated
vendored
Normal file
@ -0,0 +1,115 @@
|
||||
.TH "NPM-BUGS" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-bugs\fR - Report bugs for a package in a web browser
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm bugs \[lB]<pkgname> \[lB]<pkgname> ...\[rB]\[rB]
|
||||
|
||||
alias: issues
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
This command tries to guess at the likely location of a package's bug tracker URL or the \fBmailto\fR URL of the support email, and then tries to open it using the \fB\fB--browser\fR config\fR \fI\(la/using-npm/config#browser\(ra\fR param. If no package name is provided, it will search for a \fBpackage.json\fR in the current folder and use the \fBname\fR property.
|
||||
.SS "Configuration"
|
||||
.SS "\fBbrowser\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: OS X: \fB"open"\fR, Windows: \fB"start"\fR, Others: \fB"xdg-open"\fR
|
||||
.IP \(bu 4
|
||||
Type: null, Boolean, or String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The browser that is called by npm commands to open websites.
|
||||
.P
|
||||
Set to \fBfalse\fR to suppress browser behavior and instead print urls to terminal.
|
||||
.P
|
||||
Set to \fBtrue\fR to use default system URL opener.
|
||||
.SS "\fBregistry\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "https://registry.npmjs.org/"
|
||||
.IP \(bu 4
|
||||
Type: URL
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The base URL of the npm registry.
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinclude-workspace-root\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
.P
|
||||
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help docs
|
||||
.IP \(bu 4
|
||||
npm help view
|
||||
.IP \(bu 4
|
||||
npm help publish
|
||||
.IP \(bu 4
|
||||
npm help registry
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help npmrc
|
||||
.IP \(bu 4
|
||||
\fBpackage.json\fR \fI\(la/configuring-npm/package-json\(ra\fR
|
||||
.RE 0
|
||||
78
Dependencies/NodeJS/node_modules/npm/man/man1/npm-cache.1
generated
vendored
Normal file
78
Dependencies/NodeJS/node_modules/npm/man/man1/npm-cache.1
generated
vendored
Normal file
@ -0,0 +1,78 @@
|
||||
.TH "NPM-CACHE" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-cache\fR - Manipulates packages cache
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm cache add <package-spec>
|
||||
npm cache clean \[lB]<key>\[rB]
|
||||
npm cache ls \[lB]<name>@<version>\[rB]
|
||||
npm cache verify
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Description"
|
||||
.P
|
||||
Used to add, list, or clean the npm cache folder.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
add: Add the specified packages 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.
|
||||
.IP \(bu 4
|
||||
clean: Delete all data out of the cache folder. Note that this is typically unnecessary, as npm's cache is self-healing and resistant to data corruption issues.
|
||||
.IP \(bu 4
|
||||
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.
|
||||
.RE 0
|
||||
|
||||
.SS "Details"
|
||||
.P
|
||||
npm stores cache data in an opaque directory within the configured \fBcache\fR, named \fB_cacache\fR. This directory is a \fB\fBcacache\fR\fR \fI\(lahttp://npm.im/cacache\(ra\fR-based content-addressable cache that stores all http request data as well as other package-related data. This directory is primarily accessed through \fBpacote\fR, the library responsible for all package fetching as of npm@5.
|
||||
.P
|
||||
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 \fBpacote\fR 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 \fBclean\fR now requires \fB--force\fR to run.
|
||||
.P
|
||||
There is currently no method exposed through npm to inspect or directly manage the contents of this cache. In order to access it, \fBcacache\fR must be used directly.
|
||||
.P
|
||||
npm will not remove data by itself: the cache will grow as new packages are installed.
|
||||
.SS "A note about the cache's design"
|
||||
.P
|
||||
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.
|
||||
.P
|
||||
To run an offline verification of existing cache contents, use \fBnpm cache
|
||||
verify\fR.
|
||||
.SS "Configuration"
|
||||
.SS "\fBcache\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: Windows: \fB%LocalAppData%\[rs]npm-cache\fR, Posix: \fB~/.npm\fR
|
||||
.IP \(bu 4
|
||||
Type: Path
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The location of npm's cache directory.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help "package spec"
|
||||
.IP \(bu 4
|
||||
npm help folders
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help npmrc
|
||||
.IP \(bu 4
|
||||
npm help install
|
||||
.IP \(bu 4
|
||||
npm help publish
|
||||
.IP \(bu 4
|
||||
npm help pack
|
||||
.IP \(bu 4
|
||||
https://npm.im/cacache
|
||||
.IP \(bu 4
|
||||
https://npm.im/pacote
|
||||
.IP \(bu 4
|
||||
https://npm.im/@npmcli/arborist
|
||||
.IP \(bu 4
|
||||
https://npm.im/make-fetch-happen
|
||||
.RE 0
|
||||
289
Dependencies/NodeJS/node_modules/npm/man/man1/npm-ci.1
generated
vendored
Normal file
289
Dependencies/NodeJS/node_modules/npm/man/man1/npm-ci.1
generated
vendored
Normal file
@ -0,0 +1,289 @@
|
||||
.TH "NPM-CI" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-ci\fR - Clean install a project
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm ci
|
||||
|
||||
aliases: clean-install, ic, install-clean, isntall-clean
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
This command is similar to npm help 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.
|
||||
.P
|
||||
The main differences between using \fBnpm install\fR and \fBnpm ci\fR are:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
The project \fBmust\fR have an existing \fBpackage-lock.json\fR or \fBnpm-shrinkwrap.json\fR.
|
||||
.IP \(bu 4
|
||||
If dependencies in the package lock do not match those in \fBpackage.json\fR, \fBnpm ci\fR will exit with an error, instead of updating the package lock.
|
||||
.IP \(bu 4
|
||||
\fBnpm ci\fR can only install entire projects at a time: individual dependencies cannot be added with this command.
|
||||
.IP \(bu 4
|
||||
If a \fBnode_modules\fR is already present, it will be automatically removed before \fBnpm ci\fR begins its install.
|
||||
.IP \(bu 4
|
||||
It will never write to \fBpackage.json\fR or any of the package-locks: installs are essentially frozen.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
NOTE: If you create your \fBpackage-lock.json\fR file by running \fBnpm install\fR with flags that can affect the shape of your dependency tree, such as \fB--legacy-peer-deps\fR or \fB--install-links\fR, you \fImust\fR provide the same flags to \fBnpm ci\fR or you are likely to encounter errors. An easy way to do this is to run, for example, \fBnpm config set legacy-peer-deps=true --location=project\fR and commit the \fB.npmrc\fR file to your repo.
|
||||
.SS "Example"
|
||||
.P
|
||||
Make sure you have a package-lock and an up-to-date install:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ cd ./my/npm/project
|
||||
$ npm install
|
||||
added 154 packages in 10s
|
||||
$ ls | grep package-lock
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Run \fBnpm ci\fR in that project
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm ci
|
||||
added 154 packages in 5s
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Configure Travis CI to build using \fBnpm ci\fR instead of \fBnpm install\fR:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
# .travis.yml
|
||||
install:
|
||||
- npm ci
|
||||
# keep the npm cache around to speed up installs
|
||||
cache:
|
||||
directories:
|
||||
- "$HOME/.npm"
|
||||
.fi
|
||||
.RE
|
||||
.SS "Configuration"
|
||||
.SS "\fBinstall-strategy\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "hoisted"
|
||||
.IP \(bu 4
|
||||
Type: "hoisted", "nested", "shallow", or "linked"
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Sets the strategy for installing packages in node_modules. hoisted (default): Install non-duplicated in top-level, and duplicated as necessary within directory structure. nested: (formerly --legacy-bundling) install in place, no hoisting. shallow (formerly --global-style) only install direct deps at top-level. linked: (experimental) install in node_modules/.store, link in place, unhoisted.
|
||||
.SS "\fBlegacy-bundling\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.IP \(bu 4
|
||||
DEPRECATED: This option has been deprecated in favor of \fB--install-strategy=nested\fR
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Instead of hoisting package installs in \fBnode_modules\fR, install packages in the same manner that they are depended on. This may cause very deep directory structures and duplicate package installs as there is no de-duplicating. Sets \fB--install-strategy=nested\fR.
|
||||
.SS "\fBglobal-style\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.IP \(bu 4
|
||||
DEPRECATED: This option has been deprecated in favor of \fB--install-strategy=shallow\fR
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Only install direct dependencies in the top level \fBnode_modules\fR, but hoist on deeper dependencies. Sets \fB--install-strategy=shallow\fR.
|
||||
.SS "\fBomit\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production', otherwise empty.
|
||||
.IP \(bu 4
|
||||
Type: "dev", "optional", or "peer" (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Dependency types to omit from the installation tree on disk.
|
||||
.P
|
||||
Note that these dependencies \fIare\fR still resolved and added to the \fBpackage-lock.json\fR or \fBnpm-shrinkwrap.json\fR file. They are just not physically installed on disk.
|
||||
.P
|
||||
If a package type appears in both the \fB--include\fR and \fB--omit\fR lists, then it will be included.
|
||||
.P
|
||||
If the resulting omit list includes \fB'dev'\fR, then the \fBNODE_ENV\fR environment variable will be set to \fB'production'\fR for all lifecycle scripts.
|
||||
.SS "\fBinclude\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Option that allows for defining which types of dependencies to install.
|
||||
.P
|
||||
This is the inverse of \fB--omit=<type>\fR.
|
||||
.P
|
||||
Dependency types specified in \fB--include\fR will not be omitted, regardless of the order in which omit/include are specified on the command-line.
|
||||
.SS "\fBstrict-peer-deps\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If set to \fBtrue\fR, and \fB--legacy-peer-deps\fR is not set, then \fIany\fR conflicting \fBpeerDependencies\fR will be treated as an install failure, even if npm could reasonably guess the appropriate resolution based on non-peer dependency relationships.
|
||||
.P
|
||||
By default, conflicting \fBpeerDependencies\fR deep in the dependency graph will be resolved using the nearest non-peer dependency specification, even if doing so will result in some packages receiving a peer dependency outside the range set in their package's \fBpeerDependencies\fR object.
|
||||
.P
|
||||
When such an override is performed, a warning is printed, explaining the conflict and the packages involved. If \fB--strict-peer-deps\fR is set, then this warning is treated as a failure.
|
||||
.SS "\fBforeground-scripts\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: \fBfalse\fR unless when using \fBnpm pack\fR or \fBnpm publish\fR where it defaults to \fBtrue\fR
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Run all build scripts (ie, \fBpreinstall\fR, \fBinstall\fR, and \fBpostinstall\fR) scripts for installed packages in the foreground process, sharing standard input, output, and error with the main npm process.
|
||||
.P
|
||||
Note that this will generally make installs run slower, and be much noisier, but can be useful for debugging.
|
||||
.SS "\fBignore-scripts\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If true, npm does not run scripts specified in package.json files.
|
||||
.P
|
||||
Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run-script\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts.
|
||||
.SS "\fBaudit\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When "true" submit audit reports alongside the current npm command to the default registry and all registries configured for scopes. See the documentation for npm help audit for details on what is submitted.
|
||||
.SS "\fBbin-links\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Tells npm to create symlinks (or \fB.cmd\fR shims on Windows) for package executables.
|
||||
.P
|
||||
Set to false to have it not do this. This can be used to work around the fact that some file systems don't support symlinks, even on ostensibly Unix systems.
|
||||
.SS "\fBfund\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When "true" displays the message at the end of each \fBnpm install\fR acknowledging the number of dependencies looking for funding. See npm help fund for details.
|
||||
.SS "\fBdry-run\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, \fBinstall\fR, \fBupdate\fR, \fBdedupe\fR, \fBuninstall\fR, as well as \fBpack\fR and \fBpublish\fR.
|
||||
.P
|
||||
Note: This is NOT honored by other network related commands, eg \fBdist-tags\fR, \fBowner\fR, etc.
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinclude-workspace-root\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
.P
|
||||
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinstall-links\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set file: protocol dependencies will be packed and installed as regular dependencies instead of creating a symlink. This option has no effect on workspaces.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help install
|
||||
.IP \(bu 4
|
||||
\fBpackage-lock.json\fR \fI\(la/configuring-npm/package-lock-json\(ra\fR
|
||||
.RE 0
|
||||
35
Dependencies/NodeJS/node_modules/npm/man/man1/npm-completion.1
generated
vendored
Normal file
35
Dependencies/NodeJS/node_modules/npm/man/man1/npm-completion.1
generated
vendored
Normal file
@ -0,0 +1,35 @@
|
||||
.TH "NPM-COMPLETION" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-completion\fR - Tab Completion for npm
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm completion
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Description"
|
||||
.P
|
||||
Enables tab-completion in all npm commands.
|
||||
.P
|
||||
The synopsis above loads the completions into your current shell. Adding it to your ~/.bashrc or ~/.zshrc will make the completions available everywhere:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm completion >> ~/.bashrc
|
||||
npm completion >> ~/.zshrc
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
You may of course also pipe the output of \fBnpm completion\fR to a file such as \fB/usr/local/etc/bash_completion.d/npm\fR or \fB/etc/bash_completion.d/npm\fR if you have a system that will read that file for you.
|
||||
.P
|
||||
When \fBCOMP_CWORD\fR, \fBCOMP_LINE\fR, and \fBCOMP_POINT\fR are defined in the environment, \fBnpm completion\fR acts in "plumbing mode", and outputs completions based on the arguments.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help developers
|
||||
.IP \(bu 4
|
||||
npm help npm
|
||||
.RE 0
|
||||
187
Dependencies/NodeJS/node_modules/npm/man/man1/npm-config.1
generated
vendored
Normal file
187
Dependencies/NodeJS/node_modules/npm/man/man1/npm-config.1
generated
vendored
Normal file
@ -0,0 +1,187 @@
|
||||
.TH "NPM-CONFIG" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-config\fR - Manage the npm configuration files
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm config set <key>=<value> \[lB]<key>=<value> ...\[rB]
|
||||
npm config get \[lB]<key> \[lB]<key> ...\[rB]\[rB]
|
||||
npm config delete <key> \[lB]<key> ...\[rB]
|
||||
npm config list \[lB]--json\[rB]
|
||||
npm config edit
|
||||
npm config fix
|
||||
|
||||
alias: c
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Description"
|
||||
.P
|
||||
npm gets its config settings from the command line, environment variables, \fBnpmrc\fR files, and in some cases, the \fBpackage.json\fR file.
|
||||
.P
|
||||
See npm help npmrc for more information about the npmrc files.
|
||||
.P
|
||||
See npm help config for a more thorough explanation of the mechanisms involved, and a full list of config options available.
|
||||
.P
|
||||
The \fBnpm config\fR command can be used to update and edit the contents of the user and global npmrc files.
|
||||
.SS "Sub-commands"
|
||||
.P
|
||||
Config supports the following sub-commands:
|
||||
.SS "set"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm config set key=value \[lB]key=value...\[rB]
|
||||
npm set key=value \[lB]key=value...\[rB]
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Sets each of the config keys to the value provided. Modifies the user configuration file unless \fB\fBlocation\fR\fR \fI\(la/commands/npm-config#location\(ra\fR is passed.
|
||||
.P
|
||||
If value is omitted, the key will be removed from your config file entirely.
|
||||
.P
|
||||
Note: for backwards compatibility, \fBnpm config set key value\fR is supported as an alias for \fBnpm config set key=value\fR.
|
||||
.SS "get"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm config get \[lB]key ...\[rB]
|
||||
npm get \[lB]key ...\[rB]
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Echo the config value(s) to stdout.
|
||||
.P
|
||||
If multiple keys are provided, then the values will be prefixed with the key names.
|
||||
.P
|
||||
If no keys are provided, then this command behaves the same as \fBnpm config
|
||||
list\fR.
|
||||
.SS "list"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm config list
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Show all the config settings. Use \fB-l\fR to also show defaults. Use \fB--json\fR to show the settings in json format.
|
||||
.SS "delete"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm config delete key \[lB]key ...\[rB]
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Deletes the specified keys from all configuration files.
|
||||
.SS "edit"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm config edit
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Opens the config file in an editor. Use the \fB--global\fR flag to edit the global config.
|
||||
.SS "fix"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm config fix
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Attempts to repair invalid configuration items. Usually this means attaching authentication config (i.e. \fB_auth\fR, \fB_authToken\fR) to the configured \fBregistry\fR.
|
||||
.SS "Configuration"
|
||||
.SS "\fBjson\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Whether or not to output JSON data, rather than the normal output.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
In \fBnpm pkg set\fR it enables parsing set values with JSON.parse() before saving them to your \fBpackage.json\fR.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Not supported by all npm commands.
|
||||
.SS "\fBglobal\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Operates in "global" mode, so that packages are installed into the \fBprefix\fR folder instead of the current working directory. See npm help folders for more on the differences in behavior.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
packages are installed into the \fB{prefix}/lib/node_modules\fR folder, instead of the current working directory.
|
||||
.IP \(bu 4
|
||||
bin files are linked to \fB{prefix}/bin\fR
|
||||
.IP \(bu 4
|
||||
man pages are linked to \fB{prefix}/share/man\fR
|
||||
.RE 0
|
||||
|
||||
.SS "\fBeditor\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: The EDITOR or VISUAL environment variables, or '%SYSTEMROOT%\[rs]notepad.exe' on Windows, or 'vi' on Unix systems
|
||||
.IP \(bu 4
|
||||
Type: String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The command to run for \fBnpm edit\fR and \fBnpm config edit\fR.
|
||||
.SS "\fBlocation\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "user" unless \fB--global\fR is passed, which will also set this value to "global"
|
||||
.IP \(bu 4
|
||||
Type: "global", "user", or "project"
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When passed to \fBnpm config\fR this refers to which config file to use.
|
||||
.P
|
||||
When set to "global" mode, packages are installed into the \fBprefix\fR folder instead of the current working directory. See npm help folders for more on the differences in behavior.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
packages are installed into the \fB{prefix}/lib/node_modules\fR folder, instead of the current working directory.
|
||||
.IP \(bu 4
|
||||
bin files are linked to \fB{prefix}/bin\fR
|
||||
.IP \(bu 4
|
||||
man pages are linked to \fB{prefix}/share/man\fR
|
||||
.RE 0
|
||||
|
||||
.SS "\fBlong\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Show extended information in \fBls\fR, \fBsearch\fR, and \fBhelp-search\fR.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help folders
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
\fBpackage.json\fR \fI\(la/configuring-npm/package-json\(ra\fR
|
||||
.IP \(bu 4
|
||||
npm help npmrc
|
||||
.IP \(bu 4
|
||||
npm help npm
|
||||
.RE 0
|
||||
290
Dependencies/NodeJS/node_modules/npm/man/man1/npm-dedupe.1
generated
vendored
Normal file
290
Dependencies/NodeJS/node_modules/npm/man/man1/npm-dedupe.1
generated
vendored
Normal file
@ -0,0 +1,290 @@
|
||||
.TH "NPM-DEDUPE" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-dedupe\fR - Reduce duplication in the package tree
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm dedupe
|
||||
|
||||
alias: ddp
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
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.
|
||||
.P
|
||||
For example, consider this dependency graph:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
a
|
||||
+-- b <-- depends on c@1.0.x
|
||||
| `-- c@1.0.3
|
||||
`-- d <-- depends on c@~1.0.9
|
||||
`-- c@1.0.10
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
In this case, \fBnpm dedupe\fR will transform the tree to:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
a
|
||||
+-- b
|
||||
+-- d
|
||||
`-- c@1.0.10
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
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.
|
||||
.P
|
||||
In some cases, you may have a dependency graph like this:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
a
|
||||
+-- b <-- depends on c@1.0.x
|
||||
+-- c@1.0.3
|
||||
`-- d <-- depends on c@1.x
|
||||
`-- c@1.9.9
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
During the installation process, the \fBc@1.0.3\fR dependency for \fBb\fR was placed in the root of the tree. Though \fBd\fR's dependency on \fBc@1.x\fR could have been satisfied by \fBc@1.0.3\fR, the newer \fBc@1.9.0\fR dependency was used, because npm favors updates by default, even when doing so causes duplication.
|
||||
.P
|
||||
Running \fBnpm dedupe\fR will cause npm to note the duplication and re-evaluate, deleting the nested \fBc\fR module, because the one in the root is sufficient.
|
||||
.P
|
||||
To prefer deduplication over novelty during the installation process, run \fBnpm install --prefer-dedupe\fR or \fBnpm config set prefer-dedupe true\fR.
|
||||
.P
|
||||
Arguments are ignored. Dedupe always acts on the entire tree.
|
||||
.P
|
||||
Note that this operation transforms the dependency tree, but will never result in new modules being installed.
|
||||
.P
|
||||
Using \fBnpm find-dupes\fR will run the command in \fB--dry-run\fR mode.
|
||||
.P
|
||||
Note: \fBnpm dedupe\fR will never update the semver values of direct dependencies in your project \fBpackage.json\fR, if you want to update values in \fBpackage.json\fR you can run: \fBnpm update --save\fR instead.
|
||||
.SS "Configuration"
|
||||
.SS "\fBinstall-strategy\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "hoisted"
|
||||
.IP \(bu 4
|
||||
Type: "hoisted", "nested", "shallow", or "linked"
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Sets the strategy for installing packages in node_modules. hoisted (default): Install non-duplicated in top-level, and duplicated as necessary within directory structure. nested: (formerly --legacy-bundling) install in place, no hoisting. shallow (formerly --global-style) only install direct deps at top-level. linked: (experimental) install in node_modules/.store, link in place, unhoisted.
|
||||
.SS "\fBlegacy-bundling\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.IP \(bu 4
|
||||
DEPRECATED: This option has been deprecated in favor of \fB--install-strategy=nested\fR
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Instead of hoisting package installs in \fBnode_modules\fR, install packages in the same manner that they are depended on. This may cause very deep directory structures and duplicate package installs as there is no de-duplicating. Sets \fB--install-strategy=nested\fR.
|
||||
.SS "\fBglobal-style\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.IP \(bu 4
|
||||
DEPRECATED: This option has been deprecated in favor of \fB--install-strategy=shallow\fR
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Only install direct dependencies in the top level \fBnode_modules\fR, but hoist on deeper dependencies. Sets \fB--install-strategy=shallow\fR.
|
||||
.SS "\fBstrict-peer-deps\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If set to \fBtrue\fR, and \fB--legacy-peer-deps\fR is not set, then \fIany\fR conflicting \fBpeerDependencies\fR will be treated as an install failure, even if npm could reasonably guess the appropriate resolution based on non-peer dependency relationships.
|
||||
.P
|
||||
By default, conflicting \fBpeerDependencies\fR deep in the dependency graph will be resolved using the nearest non-peer dependency specification, even if doing so will result in some packages receiving a peer dependency outside the range set in their package's \fBpeerDependencies\fR object.
|
||||
.P
|
||||
When such an override is performed, a warning is printed, explaining the conflict and the packages involved. If \fB--strict-peer-deps\fR is set, then this warning is treated as a failure.
|
||||
.SS "\fBpackage-lock\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If set to false, then ignore \fBpackage-lock.json\fR files when installing. This will also prevent \fIwriting\fR \fBpackage-lock.json\fR if \fBsave\fR is true.
|
||||
.SS "\fBomit\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production', otherwise empty.
|
||||
.IP \(bu 4
|
||||
Type: "dev", "optional", or "peer" (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Dependency types to omit from the installation tree on disk.
|
||||
.P
|
||||
Note that these dependencies \fIare\fR still resolved and added to the \fBpackage-lock.json\fR or \fBnpm-shrinkwrap.json\fR file. They are just not physically installed on disk.
|
||||
.P
|
||||
If a package type appears in both the \fB--include\fR and \fB--omit\fR lists, then it will be included.
|
||||
.P
|
||||
If the resulting omit list includes \fB'dev'\fR, then the \fBNODE_ENV\fR environment variable will be set to \fB'production'\fR for all lifecycle scripts.
|
||||
.SS "\fBinclude\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Option that allows for defining which types of dependencies to install.
|
||||
.P
|
||||
This is the inverse of \fB--omit=<type>\fR.
|
||||
.P
|
||||
Dependency types specified in \fB--include\fR will not be omitted, regardless of the order in which omit/include are specified on the command-line.
|
||||
.SS "\fBignore-scripts\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If true, npm does not run scripts specified in package.json files.
|
||||
.P
|
||||
Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run-script\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts.
|
||||
.SS "\fBaudit\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When "true" submit audit reports alongside the current npm command to the default registry and all registries configured for scopes. See the documentation for npm help audit for details on what is submitted.
|
||||
.SS "\fBbin-links\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Tells npm to create symlinks (or \fB.cmd\fR shims on Windows) for package executables.
|
||||
.P
|
||||
Set to false to have it not do this. This can be used to work around the fact that some file systems don't support symlinks, even on ostensibly Unix systems.
|
||||
.SS "\fBfund\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When "true" displays the message at the end of each \fBnpm install\fR acknowledging the number of dependencies looking for funding. See npm help fund for details.
|
||||
.SS "\fBdry-run\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, \fBinstall\fR, \fBupdate\fR, \fBdedupe\fR, \fBuninstall\fR, as well as \fBpack\fR and \fBpublish\fR.
|
||||
.P
|
||||
Note: This is NOT honored by other network related commands, eg \fBdist-tags\fR, \fBowner\fR, etc.
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinclude-workspace-root\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
.P
|
||||
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinstall-links\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set file: protocol dependencies will be packed and installed as regular dependencies instead of creating a symlink. This option has no effect on workspaces.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help find-dupes
|
||||
.IP \(bu 4
|
||||
npm help ls
|
||||
.IP \(bu 4
|
||||
npm help update
|
||||
.IP \(bu 4
|
||||
npm help install
|
||||
.RE 0
|
||||
73
Dependencies/NodeJS/node_modules/npm/man/man1/npm-deprecate.1
generated
vendored
Normal file
73
Dependencies/NodeJS/node_modules/npm/man/man1/npm-deprecate.1
generated
vendored
Normal file
@ -0,0 +1,73 @@
|
||||
.TH "NPM-DEPRECATE" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-deprecate\fR - Deprecate a version of a package
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm deprecate <package-spec> <message>
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Description"
|
||||
.P
|
||||
This command will update the npm registry entry for a package, providing a deprecation warning to all who attempt to install it.
|
||||
.P
|
||||
It works on \fBversion ranges\fR \fI\(lahttps://semver.npmjs.com/\(ra\fR as well as specific versions, so you can do something like this:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm deprecate my-thing@"< 0.2.3" "critical bug fixed in v0.2.3"
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
SemVer ranges passed to this command are interpreted such that they \fIdo\fR include prerelease versions. For example:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm deprecate my-thing@1.x "1.x is no longer supported"
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
In this case, a version \fBmy-thing@1.0.0-beta.0\fR will also be deprecated.
|
||||
.P
|
||||
You must be the package owner to deprecate something. See the \fBowner\fR and \fBadduser\fR help topics.
|
||||
.P
|
||||
To un-deprecate a package, specify an empty string (\fB""\fR) for the \fBmessage\fR argument. Note that you must use double quotes with no space between them to format an empty string.
|
||||
.SS "Configuration"
|
||||
.SS "\fBregistry\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "https://registry.npmjs.org/"
|
||||
.IP \(bu 4
|
||||
Type: URL
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The base URL of the npm registry.
|
||||
.SS "\fBotp\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm access\fR.
|
||||
.P
|
||||
If not set, and a registry response fails with a challenge for a one-time password, npm will prompt on the command line for one.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help "package spec"
|
||||
.IP \(bu 4
|
||||
npm help publish
|
||||
.IP \(bu 4
|
||||
npm help registry
|
||||
.IP \(bu 4
|
||||
npm help owner
|
||||
.IP \(bu 4
|
||||
npm help adduser
|
||||
.RE 0
|
||||
310
Dependencies/NodeJS/node_modules/npm/man/man1/npm-diff.1
generated
vendored
Normal file
310
Dependencies/NodeJS/node_modules/npm/man/man1/npm-diff.1
generated
vendored
Normal file
@ -0,0 +1,310 @@
|
||||
.TH "NPM-DIFF" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-diff\fR - The registry diff command
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm diff \[lB]...<paths>\[rB]
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
Similar to its \fBgit diff\fR counterpart, this command will print diff patches of files for packages published to the npm registry.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
\fBnpm diff --diff=<spec-a> --diff=<spec-b>\fR
|
||||
.P
|
||||
Compares two package versions using their registry specifiers, e.g: \fBnpm diff --diff=pkg@1.0.0 --diff=pkg@^2.0.0\fR. It's also possible to compare across forks of any package, e.g: \fBnpm diff --diff=pkg@1.0.0 --diff=pkg-fork@1.0.0\fR.
|
||||
.P
|
||||
Any valid spec can be used, so that it's also possible to compare directories or git repositories, e.g: \fBnpm diff --diff=pkg@latest --diff=./packages/pkg\fR
|
||||
.P
|
||||
Here's an example comparing two different versions of a package named \fBabbrev\fR from the registry:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm diff --diff=abbrev@1.1.0 --diff=abbrev@1.1.1
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
On success, output looks like:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
diff --git a/package.json b/package.json
|
||||
index v1.1.0..v1.1.1 100644
|
||||
--- a/package.json
|
||||
+++ b/package.json
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "abbrev",
|
||||
- "version": "1.1.0",
|
||||
+ "version": "1.1.1",
|
||||
"description": "Like ruby's abbrev module, but in js",
|
||||
"author": "Isaac Z. Schlueter <i@izs.me>",
|
||||
"main": "abbrev.js",
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Given the flexible nature of npm specs, you can also target local directories or git repos just like when using \fBnpm install\fR:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm diff --diff=https://github.com/npm/libnpmdiff --diff=./local-path
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
In the example above we can compare the contents from the package installed from the git repo at \fBgithub.com/npm/libnpmdiff\fR with the contents of the \fB./local-path\fR that contains a valid package, such as a modified copy of the original.
|
||||
.IP \(bu 4
|
||||
\fBnpm diff\fR (in a package directory, no arguments):
|
||||
.P
|
||||
If the package is published to the registry, \fBnpm diff\fR will fetch the tarball version tagged as \fBlatest\fR (this value can be configured using the \fBtag\fR option) and proceed to compare the contents of files present in that tarball, with the current files in your local file system.
|
||||
.P
|
||||
This workflow provides a handy way for package authors to see what package-tracked files have been changed in comparison with the latest published version of that package.
|
||||
.IP \(bu 4
|
||||
\fBnpm diff --diff=<pkg-name>\fR (in a package directory):
|
||||
.P
|
||||
When using a single package name (with no version or tag specifier) as an argument, \fBnpm diff\fR will work in a similar way to \fB\fBnpm-outdated\fR\fR \fI\(lanpm-outdated\(ra\fR and reach for the registry to figure out what current published version of the package named \fB<pkg-name>\fR will satisfy its dependent declared semver-range. Once that specific version is known \fBnpm diff\fR will print diff patches comparing the current version of \fB<pkg-name>\fR found in the local file system with that specific version returned by the registry.
|
||||
.P
|
||||
Given a package named \fBabbrev\fR that is currently installed:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm diff --diff=abbrev
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
That will request from the registry its most up to date version and will print a diff output comparing the currently installed version to this newer one if the version numbers are not the same.
|
||||
.IP \(bu 4
|
||||
\fBnpm diff --diff=<spec-a>\fR (in a package directory):
|
||||
.P
|
||||
Similar to using only a single package name, it's also possible to declare a full registry specifier version if you wish to compare the local version of an installed package with the specific version/tag/semver-range provided in \fB<spec-a>\fR.
|
||||
.P
|
||||
An example: assuming \fBpkg@1.0.0\fR is installed in the current \fBnode_modules\fR folder, running:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm diff --diff=pkg@2.0.0
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
It will effectively be an alias to \fBnpm diff --diff=pkg@1.0.0 --diff=pkg@2.0.0\fR.
|
||||
.IP \(bu 4
|
||||
\fBnpm diff --diff=<semver-a> \[lB]--diff=<semver-b>\[rB]\fR (in a package directory):
|
||||
.P
|
||||
Using \fBnpm diff\fR along with semver-valid version numbers is a shorthand to compare different versions of the current package.
|
||||
.P
|
||||
It needs to be run from a package directory, such that for a package named \fBpkg\fR running \fBnpm diff --diff=1.0.0 --diff=1.0.1\fR is the same as running \fBnpm diff --diff=pkg@1.0.0 --diff=pkg@1.0.1\fR.
|
||||
.P
|
||||
If only a single argument \fB<version-a>\fR is provided, then the current local file system is going to be compared against that version.
|
||||
.P
|
||||
Here's an example comparing two specific versions (published to the configured registry) of the current project directory:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm diff --diff=1.0.0 --diff=1.1.0
|
||||
.fi
|
||||
.RE
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Note that tag names are not valid \fB--diff\fR argument values, if you wish to compare to a published tag, you must use the \fBpkg@tagname\fR syntax.
|
||||
.SS "Filtering files"
|
||||
.P
|
||||
It's possible to also specify positional arguments using file names or globs pattern matching in order to limit the result of diff patches to only a subset of files for a given package, e.g:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm diff --diff=pkg@2 ./lib/ CHANGELOG.md
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
In the example above the diff output is only going to print contents of files located within the folder \fB./lib/\fR and changed lines of code within the \fBCHANGELOG.md\fR file.
|
||||
.SS "Configuration"
|
||||
.SS "\fBdiff\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Define arguments to compare in \fBnpm diff\fR.
|
||||
.SS "\fBdiff-name-only\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Prints only filenames when using \fBnpm diff\fR.
|
||||
.SS "\fBdiff-unified\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: 3
|
||||
.IP \(bu 4
|
||||
Type: Number
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The number of lines of context to print in \fBnpm diff\fR.
|
||||
.SS "\fBdiff-ignore-all-space\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Ignore whitespace when comparing lines in \fBnpm diff\fR.
|
||||
.SS "\fBdiff-no-prefix\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Do not show any source or destination prefix in \fBnpm diff\fR output.
|
||||
.P
|
||||
Note: this causes \fBnpm diff\fR to ignore the \fB--diff-src-prefix\fR and \fB--diff-dst-prefix\fR configs.
|
||||
.SS "\fBdiff-src-prefix\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "a/"
|
||||
.IP \(bu 4
|
||||
Type: String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Source prefix to be used in \fBnpm diff\fR output.
|
||||
.SS "\fBdiff-dst-prefix\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "b/"
|
||||
.IP \(bu 4
|
||||
Type: String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Destination prefix to be used in \fBnpm diff\fR output.
|
||||
.SS "\fBdiff-text\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Treat all files as text in \fBnpm diff\fR.
|
||||
.SS "\fBglobal\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Operates in "global" mode, so that packages are installed into the \fBprefix\fR folder instead of the current working directory. See npm help folders for more on the differences in behavior.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
packages are installed into the \fB{prefix}/lib/node_modules\fR folder, instead of the current working directory.
|
||||
.IP \(bu 4
|
||||
bin files are linked to \fB{prefix}/bin\fR
|
||||
.IP \(bu 4
|
||||
man pages are linked to \fB{prefix}/share/man\fR
|
||||
.RE 0
|
||||
|
||||
.SS "\fBtag\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "latest"
|
||||
.IP \(bu 4
|
||||
Type: String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If you ask npm to install a package and don't tell it a specific version, then it will install the specified tag.
|
||||
.P
|
||||
It is the tag added to the package@version specified in the \fBnpm dist-tag
|
||||
add\fR command, if no explicit tag is given.
|
||||
.P
|
||||
When used by the \fBnpm diff\fR command, this is the tag used to fetch the tarball that will be compared with the local files by default.
|
||||
.P
|
||||
If used in the \fBnpm publish\fR command, this is the tag that will be added to the package submitted to the registry.
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinclude-workspace-root\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
.P
|
||||
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SH "SEE ALSO"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help outdated
|
||||
.IP \(bu 4
|
||||
npm help install
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help registry
|
||||
.RE 0
|
||||
144
Dependencies/NodeJS/node_modules/npm/man/man1/npm-dist-tag.1
generated
vendored
Normal file
144
Dependencies/NodeJS/node_modules/npm/man/man1/npm-dist-tag.1
generated
vendored
Normal file
@ -0,0 +1,144 @@
|
||||
.TH "NPM-DIST-TAG" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-dist-tag\fR - Modify package distribution tags
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm dist-tag add <package-spec (with version)> \[lB]<tag>\[rB]
|
||||
npm dist-tag rm <package-spec> <tag>
|
||||
npm dist-tag ls \[lB]<package-spec>\[rB]
|
||||
|
||||
alias: dist-tags
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
Add, remove, and enumerate distribution tags on a package:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
add: Tags the specified version of the package with the specified tag, or the \fB\fB--tag\fR config\fR \fI\(la/using-npm/config#tag\(ra\fR if not specified. If you have two-factor authentication on auth-and-writes then you\[cq]ll need to include a one-time password on the command line with \fB--otp <one-time password>\fR, or go through a second factor flow based on your \fBauthtype\fR.
|
||||
.IP \(bu 4
|
||||
rm: Clear a tag that is no longer in use from the package. If you have two-factor authentication on auth-and-writes then you\[cq]ll need to include a one-time password on the command line with \fB--otp <one-time password>\fR, or go through a second factor flow based on your \fBauthtype\fR
|
||||
.IP \(bu 4
|
||||
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.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
A tag can be used when installing packages as a reference to a version instead of using a specific version number:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm install <name>@<tag>
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
When installing dependencies, a preferred tagged version may be specified:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm install --tag <tag>
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
(This also applies to any other commands that resolve and install dependencies, such as \fBnpm dedupe\fR, \fBnpm update\fR, and \fBnpm audit fix\fR.)
|
||||
.P
|
||||
Publishing a package sets the \fBlatest\fR tag to the published version unless the \fB--tag\fR option is used. For example, \fBnpm publish --tag=beta\fR.
|
||||
.P
|
||||
By default, \fBnpm install <pkg>\fR (without any \fB@<version>\fR or \fB@<tag>\fR specifier) installs the \fBlatest\fR tag.
|
||||
.SS "Purpose"
|
||||
.P
|
||||
Tags can be used to provide an alias instead of version numbers.
|
||||
.P
|
||||
For example, a project might choose to have multiple streams of development and use a different tag for each stream, e.g., \fBstable\fR, \fBbeta\fR, \fBdev\fR, \fBcanary\fR.
|
||||
.P
|
||||
By default, the \fBlatest\fR tag is used by npm to identify the current version of a package, and \fBnpm install <pkg>\fR (without any \fB@<version>\fR or \fB@<tag>\fR specifier) installs the \fBlatest\fR tag. Typically, projects only use the \fBlatest\fR tag for stable release versions, and use other tags for unstable versions such as prereleases.
|
||||
.P
|
||||
The \fBnext\fR tag is used by some projects to identify the upcoming version.
|
||||
.P
|
||||
Other than \fBlatest\fR, no tag has any special significance to npm itself.
|
||||
.SS "Caveats"
|
||||
.P
|
||||
This command used to be known as \fBnpm tag\fR, which only created new tags, and so had a different syntax.
|
||||
.P
|
||||
Tags must share a namespace with version numbers, because they are specified in the same slot: \fBnpm install <pkg>@<version>\fR vs \fBnpm install <pkg>@<tag>\fR.
|
||||
.P
|
||||
Tags that can be interpreted as valid semver ranges will be rejected. For example, \fBv1.4\fR cannot be used as a tag, because it is interpreted by semver as \fB>=1.4.0 <1.5.0\fR. See \fI\(lahttps://github.com/npm/npm/issues/6082\(ra\fR.
|
||||
.P
|
||||
The simplest way to avoid semver problems with tags is to use tags that do not begin with a number or the letter \fBv\fR.
|
||||
.SS "Configuration"
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinclude-workspace-root\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
.P
|
||||
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help "package spec"
|
||||
.IP \(bu 4
|
||||
npm help publish
|
||||
.IP \(bu 4
|
||||
npm help install
|
||||
.IP \(bu 4
|
||||
npm help dedupe
|
||||
.IP \(bu 4
|
||||
npm help registry
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help npmrc
|
||||
.RE 0
|
||||
113
Dependencies/NodeJS/node_modules/npm/man/man1/npm-docs.1
generated
vendored
Normal file
113
Dependencies/NodeJS/node_modules/npm/man/man1/npm-docs.1
generated
vendored
Normal file
@ -0,0 +1,113 @@
|
||||
.TH "NPM-DOCS" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-docs\fR - Open documentation for a package in a web browser
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm docs \[lB]<pkgname> \[lB]<pkgname> ...\[rB]\[rB]
|
||||
|
||||
alias: home
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
This command tries to guess at the likely location of a package's documentation URL, and then tries to open it using the \fB\fB--browser\fR config\fR \fI\(la/using-npm/config#browser\(ra\fR param. You can pass multiple package names at once. If no package name is provided, it will search for a \fBpackage.json\fR in the current folder and use the \fBname\fR property.
|
||||
.SS "Configuration"
|
||||
.SS "\fBbrowser\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: OS X: \fB"open"\fR, Windows: \fB"start"\fR, Others: \fB"xdg-open"\fR
|
||||
.IP \(bu 4
|
||||
Type: null, Boolean, or String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The browser that is called by npm commands to open websites.
|
||||
.P
|
||||
Set to \fBfalse\fR to suppress browser behavior and instead print urls to terminal.
|
||||
.P
|
||||
Set to \fBtrue\fR to use default system URL opener.
|
||||
.SS "\fBregistry\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "https://registry.npmjs.org/"
|
||||
.IP \(bu 4
|
||||
Type: URL
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The base URL of the npm registry.
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinclude-workspace-root\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
.P
|
||||
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help view
|
||||
.IP \(bu 4
|
||||
npm help publish
|
||||
.IP \(bu 4
|
||||
npm help registry
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help npmrc
|
||||
.IP \(bu 4
|
||||
\fBpackage.json\fR \fI\(la/configuring-npm/package-json\(ra\fR
|
||||
.RE 0
|
||||
82
Dependencies/NodeJS/node_modules/npm/man/man1/npm-doctor.1
generated
vendored
Normal file
82
Dependencies/NodeJS/node_modules/npm/man/man1/npm-doctor.1
generated
vendored
Normal file
@ -0,0 +1,82 @@
|
||||
.TH "NPM-DOCTOR" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-doctor\fR - Check the health of your npm environment
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm doctor \[lB]connection\[rB] \[lB]registry\[rB] \[lB]versions\[rB] \[lB]environment\[rB] \[lB]permissions\[rB] \[lB]cache\[rB]
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Description"
|
||||
.P
|
||||
\fBnpm doctor\fR 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:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Node.js and git must be executable by npm.
|
||||
.IP \(bu 4
|
||||
The primary npm registry, \fBregistry.npmjs.com\fR, or another service that uses the registry API, is available.
|
||||
.IP \(bu 4
|
||||
The directories that npm uses, \fBnode_modules\fR (both locally and globally), exist and can be written by the current user.
|
||||
.IP \(bu 4
|
||||
The npm cache exists, and the package tarballs within it aren't corrupt.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
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 \fBnpm doctor\fR confirms that the npm installation is in a good state.
|
||||
.P
|
||||
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 \fBnpm@latest\fR is better than an old version.
|
||||
.P
|
||||
\fBnpm doctor\fR verifies the following items in your environment, and if there are any recommended changes, it will display them. By default npm runs all of these checks. You can limit what checks are ran by specifying them as extra arguments.
|
||||
.SS "\fBConnecting to the registry\fR"
|
||||
.P
|
||||
By default, npm installs from the primary npm registry, \fBregistry.npmjs.org\fR. \fBnpm doctor\fR hits a special connection testing endpoint within the registry. This can also be checked with \fBnpm ping\fR. 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 \fBregistry.npmjs.org\fR.
|
||||
.P
|
||||
This check is done against whichever registry you've configured (you can see what that is by running \fBnpm config get registry\fR), and if you're using a private registry that doesn't support the \fB/whoami\fR endpoint supported by the primary registry, this check may fail.
|
||||
.SS "\fBChecking npm version\fR"
|
||||
.P
|
||||
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 \fBnpm@latest\fR 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.
|
||||
.SS "\fBChecking node version\fR"
|
||||
.P
|
||||
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 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.
|
||||
.SS "\fBChecking configured npm registry\fR"
|
||||
.P
|
||||
You may be installing from private package registries for your project or company. That's great! Others 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 \fBnpm doctor\fR just lets you, and maybe whoever's helping you with support, know that you're not using the default registry.
|
||||
.SS "\fBChecking for git executable in PATH\fR"
|
||||
.P
|
||||
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 \[en] especially on Windows \[en] you may have Git set up in such a way that it's not accessible via your \fBPATH\fR so that npm can find it. This check ensures that Git is available.
|
||||
.SS "Permissions checks"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Your cache must be readable and writable by the user running npm.
|
||||
.IP \(bu 4
|
||||
Global package binaries must be writable by the user running npm.
|
||||
.IP \(bu 4
|
||||
Your local \fBnode_modules\fR path, if you're running \fBnpm doctor\fR with a project directory, must be readable and writable by the user running npm.
|
||||
.RE 0
|
||||
|
||||
.SS "Validate the checksums of cached packages"
|
||||
.P
|
||||
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. \fBnpm doctor\fR uses these checksums to validate the package tarballs in your local cache (you can see where that cache is located with \fBnpm config get cache\fR). In the event that there are corrupt packages in your cache, you should probably run \fBnpm cache clean -f\fR and reset the cache.
|
||||
.SS "Configuration"
|
||||
.SS "\fBregistry\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "https://registry.npmjs.org/"
|
||||
.IP \(bu 4
|
||||
Type: URL
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The base URL of the npm registry.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help bugs
|
||||
.IP \(bu 4
|
||||
npm help help
|
||||
.IP \(bu 4
|
||||
npm help ping
|
||||
.RE 0
|
||||
43
Dependencies/NodeJS/node_modules/npm/man/man1/npm-edit.1
generated
vendored
Normal file
43
Dependencies/NodeJS/node_modules/npm/man/man1/npm-edit.1
generated
vendored
Normal file
@ -0,0 +1,43 @@
|
||||
.TH "NPM-EDIT" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-edit\fR - Edit an installed package
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm edit <pkg>\[lB]/<subpkg>...\[rB]
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Description"
|
||||
.P
|
||||
Selects a dependency in the current project and opens the package folder in the default editor (or whatever you've configured as the npm \fBeditor\fR config -- see \fB\fBnpm-config\fR\fR \fI\(lanpm-config\(ra\fR.)
|
||||
.P
|
||||
After it has been edited, the package is rebuilt so as to pick up any changes in compiled packages.
|
||||
.P
|
||||
For instance, you can do \fBnpm install connect\fR to install connect into your package, and then \fBnpm edit connect\fR to make a few changes to your locally installed copy.
|
||||
.SS "Configuration"
|
||||
.SS "\fBeditor\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: The EDITOR or VISUAL environment variables, or '%SYSTEMROOT%\[rs]notepad.exe' on Windows, or 'vi' on Unix systems
|
||||
.IP \(bu 4
|
||||
Type: String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The command to run for \fBnpm edit\fR and \fBnpm config edit\fR.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help folders
|
||||
.IP \(bu 4
|
||||
npm help explore
|
||||
.IP \(bu 4
|
||||
npm help install
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help npmrc
|
||||
.RE 0
|
||||
350
Dependencies/NodeJS/node_modules/npm/man/man1/npm-exec.1
generated
vendored
Normal file
350
Dependencies/NodeJS/node_modules/npm/man/man1/npm-exec.1
generated
vendored
Normal file
@ -0,0 +1,350 @@
|
||||
.TH "NPM-EXEC" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-exec\fR - Run a command from a local or remote npm package
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm exec -- <pkg>\[lB]@<version>\[rB] \[lB]args...\[rB]
|
||||
npm exec --package=<pkg>\[lB]@<version>\[rB] -- <cmd> \[lB]args...\[rB]
|
||||
npm exec -c '<cmd> \[lB]args...\[rB]'
|
||||
npm exec --package=foo -c '<cmd> \[lB]args...\[rB]'
|
||||
|
||||
alias: x
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
This command allows you to run an arbitrary command from an npm package (either one installed locally, or fetched remotely), in a similar context as running it via \fBnpm run\fR.
|
||||
.P
|
||||
Run without positional arguments or \fB--call\fR, this allows you to interactively run commands in the same sort of shell environment that \fBpackage.json\fR scripts are run. Interactive mode is not supported in CI environments when standard input is a TTY, to prevent hangs.
|
||||
.P
|
||||
Whatever packages are specified by the \fB--package\fR option will be provided in the \fBPATH\fR of the executed command, along with any locally installed package executables. The \fB--package\fR option may be specified multiple times, to execute the supplied command in an environment where all specified packages are available.
|
||||
.P
|
||||
If any requested packages are not present in the local project dependencies, then a prompt is printed, which can be suppressed by providing either \fB--yes\fR or \fB--no\fR. When standard input is not a TTY or a CI environment is detected, \fB--yes\fR is assumed. The requested packages are installed to a folder in the npm cache, which is added to the \fBPATH\fR environment variable in the executed process.
|
||||
.P
|
||||
Package names provided without a specifier will be matched with whatever version exists in the local project. Package names with a specifier will only be considered a match if they have the exact same name and version as the local dependency.
|
||||
.P
|
||||
If no \fB-c\fR or \fB--call\fR option is provided, then the positional arguments are used to generate the command string. If no \fB--package\fR options are provided, then npm will attempt to determine the executable name from the package specifier provided as the first positional argument according to the following heuristic:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
If the package has a single entry in its \fBbin\fR field in \fBpackage.json\fR, or if all entries are aliases of the same command, then that command will be used.
|
||||
.IP \(bu 4
|
||||
If the package has multiple \fBbin\fR entries, and one of them matches the unscoped portion of the \fBname\fR field, then that command will be used.
|
||||
.IP \(bu 4
|
||||
If this does not result in exactly one option (either because there are no bin entries, or none of them match the \fBname\fR of the package), then \fBnpm exec\fR exits with an error.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
To run a binary \fIother than\fR the named binary, specify one or more \fB--package\fR options, which will prevent npm from inferring the package from the first command argument.
|
||||
.SS "\fBnpx\fR vs \fBnpm exec\fR"
|
||||
.P
|
||||
When run via the \fBnpx\fR binary, all flags and options \fImust\fR be set prior to any positional arguments. When run via \fBnpm exec\fR, a double-hyphen \fB--\fR flag can be used to suppress npm's parsing of switches and options that should be sent to the executed command.
|
||||
.P
|
||||
For example:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npx foo@latest bar --package=@npmcli/foo
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
In this case, npm will resolve the \fBfoo\fR package name, and run the following command:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ foo bar --package=@npmcli/foo
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Since the \fB--package\fR option comes \fIafter\fR the positional arguments, it is treated as an argument to the executed command.
|
||||
.P
|
||||
In contrast, due to npm's argument parsing logic, running this command is different:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm exec foo@latest bar --package=@npmcli/foo
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
In this case, npm will parse the \fB--package\fR option first, resolving the \fB@npmcli/foo\fR package. Then, it will execute the following command in that context:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ foo@latest bar
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
The double-hyphen character is recommended to explicitly tell npm to stop parsing command line options and switches. The following command would thus be equivalent to the \fBnpx\fR command above:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm exec -- foo@latest bar --package=@npmcli/foo
|
||||
.fi
|
||||
.RE
|
||||
.SS "Configuration"
|
||||
.SS "\fBpackage\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The package or packages to install for npm help exec
|
||||
.SS "\fBcall\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: ""
|
||||
.IP \(bu 4
|
||||
Type: String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Optional companion option for \fBnpm exec\fR, \fBnpx\fR that allows for specifying a custom command to be run along with the installed packages.
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm exec --package yo --package generator-node --call "yo node"
|
||||
.fi
|
||||
.RE
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinclude-workspace-root\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
.P
|
||||
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "Examples"
|
||||
.P
|
||||
Run the version of \fBtap\fR in the local dependencies, with the provided arguments:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm exec -- tap --bail test/foo.js
|
||||
$ npx tap --bail test/foo.js
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Run a command \fIother than\fR the command whose name matches the package name by specifying a \fB--package\fR option:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm exec --package=foo -- bar --bar-argument
|
||||
# ~ or ~
|
||||
$ npx --package=foo bar --bar-argument
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Run an arbitrary shell script, in the context of the current project:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm x -c 'eslint && say "hooray, lint passed"'
|
||||
$ npx -c 'eslint && say "hooray, lint passed"'
|
||||
.fi
|
||||
.RE
|
||||
.SS "Workspaces support"
|
||||
.P
|
||||
You may use the \fB\fBworkspace\fR\fR \fI\(la/using-npm/config#workspace\(ra\fR or \fB\fBworkspaces\fR\fR \fI\(la/using-npm/config#workspaces\(ra\fR configs in order to run an arbitrary command from an npm package (either one installed locally, or fetched remotely) in the context of the specified workspaces. If no positional argument or \fB--call\fR option is provided, it will open an interactive subshell in the context of each of these configured workspaces one at a time.
|
||||
.P
|
||||
Given a project with configured workspaces, e.g:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
.
|
||||
+-- package.json
|
||||
`-- packages
|
||||
+-- a
|
||||
| `-- package.json
|
||||
+-- b
|
||||
| `-- package.json
|
||||
`-- c
|
||||
`-- package.json
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Assuming the workspace configuration is properly set up at the root level \fBpackage.json\fR file. e.g:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
{
|
||||
"workspaces": \[lB] "./packages/*" \[rB]
|
||||
}
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
You can execute an arbitrary command from a package in the context of each of the configured workspaces when using the \fB\fBworkspaces\fR config options\fR \fI\(la/using-npm/config#workspace\(ra\fR, in this example we're using \fBeslint\fR to lint any js file found within each workspace folder:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm exec --ws -- eslint ./*.js
|
||||
.fi
|
||||
.RE
|
||||
.SS "Filtering workspaces"
|
||||
.P
|
||||
It's also possible to execute a command in a single workspace using the \fBworkspace\fR config along with a name or directory path:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm exec --workspace=a -- eslint ./*.js
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
The \fBworkspace\fR config can also be specified multiple times in order to run a specific script in the context of multiple workspaces. When defining values for the \fBworkspace\fR config in the command line, it also possible to use \fB-w\fR as a shorthand, e.g:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm exec -w a -w b -- eslint ./*.js
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
This last command will run the \fBeslint\fR command in both \fB./packages/a\fR and \fB./packages/b\fR folders.
|
||||
.SS "Compatibility with Older npx Versions"
|
||||
.P
|
||||
The \fBnpx\fR binary was rewritten in npm v7.0.0, and the standalone \fBnpx\fR package deprecated at that time. \fBnpx\fR uses the \fBnpm exec\fR command instead of a separate argument parser and install process, with some affordances to maintain backwards compatibility with the arguments it accepted in previous versions.
|
||||
.P
|
||||
This resulted in some shifts in its functionality:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Any \fBnpm\fR config value may be provided.
|
||||
.IP \(bu 4
|
||||
To prevent security and user-experience problems from mistyping package names, \fBnpx\fR prompts before installing anything. Suppress this prompt with the \fB-y\fR or \fB--yes\fR option.
|
||||
.IP \(bu 4
|
||||
The \fB--no-install\fR option is deprecated, and will be converted to \fB--no\fR.
|
||||
.IP \(bu 4
|
||||
Shell fallback functionality is removed, as it is not advisable.
|
||||
.IP \(bu 4
|
||||
The \fB-p\fR argument is a shorthand for \fB--parseable\fR in npm, but shorthand for \fB--package\fR in npx. This is maintained, but only for the \fBnpx\fR executable.
|
||||
.IP \(bu 4
|
||||
The \fB--ignore-existing\fR option is removed. Locally installed bins are always present in the executed process \fBPATH\fR.
|
||||
.IP \(bu 4
|
||||
The \fB--npm\fR option is removed. \fBnpx\fR will always use the \fBnpm\fR it ships with.
|
||||
.IP \(bu 4
|
||||
The \fB--node-arg\fR and \fB-n\fR options are removed.
|
||||
.IP \(bu 4
|
||||
The \fB--always-spawn\fR option is redundant, and thus removed.
|
||||
.IP \(bu 4
|
||||
The \fB--shell\fR option is replaced with \fB--script-shell\fR, but maintained in the \fBnpx\fR executable for backwards compatibility.
|
||||
.RE 0
|
||||
|
||||
.SS "A note on caching"
|
||||
.P
|
||||
The npm cli utilizes its internal package cache when using the package name specified. You can use the following to change how and when the cli uses this cache. See npm help cache for more on how the cache works.
|
||||
.SS "prefer-online"
|
||||
.P
|
||||
Forces staleness checks for packages, making the cli look for updates immediately even if the package is already in the cache.
|
||||
.SS "prefer-offline"
|
||||
.P
|
||||
Bypasses staleness checks for packages. Missing data will still be requested from the server. To force full offline mode, use \fBoffline\fR.
|
||||
.SS "offline"
|
||||
.P
|
||||
Forces full offline mode. Any packages not locally cached will result in an error.
|
||||
.SS "workspace"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result to selecting all of the nested workspaces)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "workspaces"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Alias: \fB--ws\fR
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.IP \(bu 4
|
||||
Default: \fBfalse\fR
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Run scripts in the context of all configured workspaces for the current project.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help run-script
|
||||
.IP \(bu 4
|
||||
npm help scripts
|
||||
.IP \(bu 4
|
||||
npm help test
|
||||
.IP \(bu 4
|
||||
npm help start
|
||||
.IP \(bu 4
|
||||
npm help restart
|
||||
.IP \(bu 4
|
||||
npm help stop
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help workspaces
|
||||
.IP \(bu 4
|
||||
npm help npx
|
||||
.RE 0
|
||||
118
Dependencies/NodeJS/node_modules/npm/man/man1/npm-explain.1
generated
vendored
Normal file
118
Dependencies/NodeJS/node_modules/npm/man/man1/npm-explain.1
generated
vendored
Normal file
@ -0,0 +1,118 @@
|
||||
.TH "NPM-EXPLAIN" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-explain\fR - Explain installed packages
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm explain <package-spec>
|
||||
|
||||
alias: why
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
This command will print the chain of dependencies causing a given package to be installed in the current project.
|
||||
.P
|
||||
If one or more package specs are provided, then only packages matching one of the specifiers will have their relationships explained.
|
||||
.P
|
||||
The package spec can also refer to a folder within \fB./node_modules\fR
|
||||
.P
|
||||
For example, running \fBnpm explain glob\fR within npm's source tree will show:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
glob@7.1.6
|
||||
node_modules/glob
|
||||
glob@"^7.1.4" from the root project
|
||||
|
||||
glob@7.1.1 dev
|
||||
node_modules/tacks/node_modules/glob
|
||||
glob@"^7.0.5" from rimraf@2.6.2
|
||||
node_modules/tacks/node_modules/rimraf
|
||||
rimraf@"^2.6.2" from tacks@1.3.0
|
||||
node_modules/tacks
|
||||
dev tacks@"^1.3.0" from the root project
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
To explain just the package residing at a specific folder, pass that as the argument to the command. This can be useful when trying to figure out exactly why a given dependency is being duplicated to satisfy conflicting version requirements within the project.
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm explain node_modules/nyc/node_modules/find-up
|
||||
find-up@3.0.0 dev
|
||||
node_modules/nyc/node_modules/find-up
|
||||
find-up@"^3.0.0" from nyc@14.1.1
|
||||
node_modules/nyc
|
||||
nyc@"^14.1.1" from tap@14.10.8
|
||||
node_modules/tap
|
||||
dev tap@"^14.10.8" from the root project
|
||||
.fi
|
||||
.RE
|
||||
.SS "Configuration"
|
||||
.SS "\fBjson\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Whether or not to output JSON data, rather than the normal output.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
In \fBnpm pkg set\fR it enables parsing set values with JSON.parse() before saving them to your \fBpackage.json\fR.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Not supported by all npm commands.
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help "package spec"
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help npmrc
|
||||
.IP \(bu 4
|
||||
npm help folders
|
||||
.IP \(bu 4
|
||||
npm help ls
|
||||
.IP \(bu 4
|
||||
npm help install
|
||||
.IP \(bu 4
|
||||
npm help link
|
||||
.IP \(bu 4
|
||||
npm help prune
|
||||
.IP \(bu 4
|
||||
npm help outdated
|
||||
.IP \(bu 4
|
||||
npm help update
|
||||
.RE 0
|
||||
49
Dependencies/NodeJS/node_modules/npm/man/man1/npm-explore.1
generated
vendored
Normal file
49
Dependencies/NodeJS/node_modules/npm/man/man1/npm-explore.1
generated
vendored
Normal file
@ -0,0 +1,49 @@
|
||||
.TH "NPM-EXPLORE" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-explore\fR - Browse an installed package
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm explore <pkg> \[lB] -- <command>\[rB]
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Description"
|
||||
.P
|
||||
Spawn a subshell in the directory of the installed package specified.
|
||||
.P
|
||||
If a command is specified, then it is run in the subshell, which then immediately terminates.
|
||||
.P
|
||||
This is particularly handy in the case of git submodules in the \fBnode_modules\fR folder:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm explore some-dependency -- git pull origin master
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note that the package is \fInot\fR automatically rebuilt afterwards, so be sure to use \fBnpm rebuild <pkg>\fR if you make any changes.
|
||||
.SS "Configuration"
|
||||
.SS "\fBshell\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: SHELL environment variable, or "bash" on Posix, or "cmd.exe" on Windows
|
||||
.IP \(bu 4
|
||||
Type: String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The shell to run for the \fBnpm explore\fR command.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help folders
|
||||
.IP \(bu 4
|
||||
npm help edit
|
||||
.IP \(bu 4
|
||||
npm help rebuild
|
||||
.IP \(bu 4
|
||||
npm help install
|
||||
.RE 0
|
||||
225
Dependencies/NodeJS/node_modules/npm/man/man1/npm-find-dupes.1
generated
vendored
Normal file
225
Dependencies/NodeJS/node_modules/npm/man/man1/npm-find-dupes.1
generated
vendored
Normal file
@ -0,0 +1,225 @@
|
||||
.TH "NPM-FIND-DUPES" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-find-dupes\fR - Find duplication in the package tree
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm find-dupes
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
Runs \fBnpm dedupe\fR in \fB--dry-run\fR mode, making npm only output the duplications, without actually changing the package tree.
|
||||
.SS "Configuration"
|
||||
.SS "\fBinstall-strategy\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "hoisted"
|
||||
.IP \(bu 4
|
||||
Type: "hoisted", "nested", "shallow", or "linked"
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Sets the strategy for installing packages in node_modules. hoisted (default): Install non-duplicated in top-level, and duplicated as necessary within directory structure. nested: (formerly --legacy-bundling) install in place, no hoisting. shallow (formerly --global-style) only install direct deps at top-level. linked: (experimental) install in node_modules/.store, link in place, unhoisted.
|
||||
.SS "\fBlegacy-bundling\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.IP \(bu 4
|
||||
DEPRECATED: This option has been deprecated in favor of \fB--install-strategy=nested\fR
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Instead of hoisting package installs in \fBnode_modules\fR, install packages in the same manner that they are depended on. This may cause very deep directory structures and duplicate package installs as there is no de-duplicating. Sets \fB--install-strategy=nested\fR.
|
||||
.SS "\fBglobal-style\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.IP \(bu 4
|
||||
DEPRECATED: This option has been deprecated in favor of \fB--install-strategy=shallow\fR
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Only install direct dependencies in the top level \fBnode_modules\fR, but hoist on deeper dependencies. Sets \fB--install-strategy=shallow\fR.
|
||||
.SS "\fBstrict-peer-deps\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If set to \fBtrue\fR, and \fB--legacy-peer-deps\fR is not set, then \fIany\fR conflicting \fBpeerDependencies\fR will be treated as an install failure, even if npm could reasonably guess the appropriate resolution based on non-peer dependency relationships.
|
||||
.P
|
||||
By default, conflicting \fBpeerDependencies\fR deep in the dependency graph will be resolved using the nearest non-peer dependency specification, even if doing so will result in some packages receiving a peer dependency outside the range set in their package's \fBpeerDependencies\fR object.
|
||||
.P
|
||||
When such an override is performed, a warning is printed, explaining the conflict and the packages involved. If \fB--strict-peer-deps\fR is set, then this warning is treated as a failure.
|
||||
.SS "\fBpackage-lock\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If set to false, then ignore \fBpackage-lock.json\fR files when installing. This will also prevent \fIwriting\fR \fBpackage-lock.json\fR if \fBsave\fR is true.
|
||||
.SS "\fBomit\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production', otherwise empty.
|
||||
.IP \(bu 4
|
||||
Type: "dev", "optional", or "peer" (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Dependency types to omit from the installation tree on disk.
|
||||
.P
|
||||
Note that these dependencies \fIare\fR still resolved and added to the \fBpackage-lock.json\fR or \fBnpm-shrinkwrap.json\fR file. They are just not physically installed on disk.
|
||||
.P
|
||||
If a package type appears in both the \fB--include\fR and \fB--omit\fR lists, then it will be included.
|
||||
.P
|
||||
If the resulting omit list includes \fB'dev'\fR, then the \fBNODE_ENV\fR environment variable will be set to \fB'production'\fR for all lifecycle scripts.
|
||||
.SS "\fBinclude\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Option that allows for defining which types of dependencies to install.
|
||||
.P
|
||||
This is the inverse of \fB--omit=<type>\fR.
|
||||
.P
|
||||
Dependency types specified in \fB--include\fR will not be omitted, regardless of the order in which omit/include are specified on the command-line.
|
||||
.SS "\fBignore-scripts\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If true, npm does not run scripts specified in package.json files.
|
||||
.P
|
||||
Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run-script\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts.
|
||||
.SS "\fBaudit\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When "true" submit audit reports alongside the current npm command to the default registry and all registries configured for scopes. See the documentation for npm help audit for details on what is submitted.
|
||||
.SS "\fBbin-links\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Tells npm to create symlinks (or \fB.cmd\fR shims on Windows) for package executables.
|
||||
.P
|
||||
Set to false to have it not do this. This can be used to work around the fact that some file systems don't support symlinks, even on ostensibly Unix systems.
|
||||
.SS "\fBfund\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When "true" displays the message at the end of each \fBnpm install\fR acknowledging the number of dependencies looking for funding. See npm help fund for details.
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinclude-workspace-root\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
.P
|
||||
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinstall-links\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set file: protocol dependencies will be packed and installed as regular dependencies instead of creating a symlink. This option has no effect on workspaces.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help dedupe
|
||||
.IP \(bu 4
|
||||
npm help ls
|
||||
.IP \(bu 4
|
||||
npm help update
|
||||
.IP \(bu 4
|
||||
npm help install
|
||||
.RE 0
|
||||
142
Dependencies/NodeJS/node_modules/npm/man/man1/npm-fund.1
generated
vendored
Normal file
142
Dependencies/NodeJS/node_modules/npm/man/man1/npm-fund.1
generated
vendored
Normal file
@ -0,0 +1,142 @@
|
||||
.TH "NPM-FUND" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-fund\fR - Retrieve funding information
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm fund \[lB]<package-spec>\[rB]
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
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, listing 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 \fB\fB--browser\fR config\fR \fI\(la/using-npm/config#browser\(ra\fR param; if there are multiple funding sources for the package, the user will be instructed to pass the \fB--which\fR option to disambiguate.
|
||||
.P
|
||||
The list will avoid duplicated entries and will stack all packages that share the same url as a single entry. Thus, the list does not have the same shape of the output from \fBnpm ls\fR.
|
||||
.SS "Example"
|
||||
.SS "Workspaces support"
|
||||
.P
|
||||
It's possible to filter the results to only include a single workspace and its dependencies using the \fB\fBworkspace\fR config\fR \fI\(la/using-npm/config#workspace\(ra\fR option.
|
||||
.SS "Example:"
|
||||
.P
|
||||
Here's an example running \fBnpm fund\fR in a project with a configured workspace \fBa\fR:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm fund
|
||||
test-workspaces-fund@1.0.0
|
||||
+-- https://example.com/a
|
||||
| | `-- a@1.0.0
|
||||
| `-- https://example.com/maintainer
|
||||
| `-- foo@1.0.0
|
||||
+-- https://example.com/npmcli-funding
|
||||
| `-- @npmcli/test-funding
|
||||
`-- https://example.com/org
|
||||
`-- bar@2.0.0
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
And here is an example of the expected result when filtering only by a specific workspace \fBa\fR in the same project:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm fund -w a
|
||||
test-workspaces-fund@1.0.0
|
||||
`-- https://example.com/a
|
||||
| `-- a@1.0.0
|
||||
`-- https://example.com/maintainer
|
||||
`-- foo@2.0.0
|
||||
.fi
|
||||
.RE
|
||||
.SS "Configuration"
|
||||
.SS "\fBjson\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Whether or not to output JSON data, rather than the normal output.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
In \fBnpm pkg set\fR it enables parsing set values with JSON.parse() before saving them to your \fBpackage.json\fR.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Not supported by all npm commands.
|
||||
.SS "\fBbrowser\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: OS X: \fB"open"\fR, Windows: \fB"start"\fR, Others: \fB"xdg-open"\fR
|
||||
.IP \(bu 4
|
||||
Type: null, Boolean, or String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The browser that is called by npm commands to open websites.
|
||||
.P
|
||||
Set to \fBfalse\fR to suppress browser behavior and instead print urls to terminal.
|
||||
.P
|
||||
Set to \fBtrue\fR to use default system URL opener.
|
||||
.SS "\fBunicode\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false on windows, true on mac/unix systems with a unicode locale, as defined by the \fBLC_ALL\fR, \fBLC_CTYPE\fR, or \fBLANG\fR environment variables.
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set to true, npm uses unicode characters in the tree output. When false, it uses ascii characters instead of unicode glyphs.
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBwhich\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Number
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If there are multiple funding sources, which 1-indexed source URL to open.
|
||||
.SH "SEE ALSO"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help "package spec"
|
||||
.IP \(bu 4
|
||||
npm help install
|
||||
.IP \(bu 4
|
||||
npm help docs
|
||||
.IP \(bu 4
|
||||
npm help ls
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help workspaces
|
||||
.RE 0
|
||||
37
Dependencies/NodeJS/node_modules/npm/man/man1/npm-help-search.1
generated
vendored
Normal file
37
Dependencies/NodeJS/node_modules/npm/man/man1/npm-help-search.1
generated
vendored
Normal file
@ -0,0 +1,37 @@
|
||||
.TH "NPM-HELP-SEARCH" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-help-search\fR - Search npm help documentation
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm help-search <text>
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Description"
|
||||
.P
|
||||
This command will search the npm markdown documentation files for the terms provided, and then list the results, sorted by relevance.
|
||||
.P
|
||||
If only one result is found, then it will show that help topic.
|
||||
.P
|
||||
If the argument to \fBnpm help\fR is not a known help topic, then it will call \fBhelp-search\fR. It is rarely if ever necessary to call this command directly.
|
||||
.SS "Configuration"
|
||||
.SS "\fBlong\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Show extended information in \fBls\fR, \fBsearch\fR, and \fBhelp-search\fR.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help npm
|
||||
.IP \(bu 4
|
||||
npm help help
|
||||
.RE 0
|
||||
47
Dependencies/NodeJS/node_modules/npm/man/man1/npm-help.1
generated
vendored
Normal file
47
Dependencies/NodeJS/node_modules/npm/man/man1/npm-help.1
generated
vendored
Normal file
@ -0,0 +1,47 @@
|
||||
.TH "NPM-HELP" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-help\fR - Get help on npm
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm help <term> \[lB]<terms..>\[rB]
|
||||
|
||||
alias: hlep
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Description"
|
||||
.P
|
||||
If supplied a topic, then show the appropriate documentation page.
|
||||
.P
|
||||
If the topic does not exist, or if multiple terms are provided, then npm will run the \fBhelp-search\fR command to find a match. Note that, if \fBhelp-search\fR finds a single subject, then it will run \fBhelp\fR on that topic, so unique matches are equivalent to specifying a topic name.
|
||||
.SS "Configuration"
|
||||
.SS "\fBviewer\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "man" on Posix, "browser" on Windows
|
||||
.IP \(bu 4
|
||||
Type: String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The program to use to view help content.
|
||||
.P
|
||||
Set to \fB"browser"\fR to view html help content in the default web browser.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help npm
|
||||
.IP \(bu 4
|
||||
npm help folders
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help npmrc
|
||||
.IP \(bu 4
|
||||
\fBpackage.json\fR \fI\(la/configuring-npm/package-json\(ra\fR
|
||||
.IP \(bu 4
|
||||
npm help help-search
|
||||
.RE 0
|
||||
115
Dependencies/NodeJS/node_modules/npm/man/man1/npm-hook.1
generated
vendored
Normal file
115
Dependencies/NodeJS/node_modules/npm/man/man1/npm-hook.1
generated
vendored
Normal file
@ -0,0 +1,115 @@
|
||||
.TH "NPM-HOOK" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-hook\fR - Manage registry hooks
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm hook add <pkg> <url> <secret> \[lB]--type=<type>\[rB]
|
||||
npm hook ls \[lB]pkg\[rB]
|
||||
npm hook rm <id>
|
||||
npm hook update <id> <url> <secret>
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Description"
|
||||
.P
|
||||
Allows you to manage \fBnpm hooks\fR \fI\(lahttps://blog.npmjs.org/post/145260155635/introducing-hooks-get-notifications-of-npm\(ra\fR, including adding, removing, listing, and updating.
|
||||
.P
|
||||
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.
|
||||
.P
|
||||
To create a package hook, simply reference the package name.
|
||||
.P
|
||||
To create an owner hook, prefix the owner name with \fB~\fR (as in, \fB~youruser\fR).
|
||||
.P
|
||||
To create a scope hook, prefix the scope name with \fB@\fR (as in, \fB@yourscope\fR).
|
||||
.P
|
||||
The hook \fBid\fR used by \fBupdate\fR and \fBrm\fR are the IDs listed in \fBnpm hook ls\fR for that particular hook.
|
||||
.P
|
||||
The shared secret will be sent along to the URL endpoint so you can verify the request came from your own configured hook.
|
||||
.SS "Example"
|
||||
.P
|
||||
Add a hook to watch a package for changes:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm hook add lodash https://example.com/ my-shared-secret
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Add a hook to watch packages belonging to the user \fBsubstack\fR:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm hook add ~substack https://example.com/ my-shared-secret
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Add a hook to watch packages in the scope \fB@npm\fR
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm hook add @npm https://example.com/ my-shared-secret
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
List all your active hooks:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm hook ls
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
List your active hooks for the \fBlodash\fR package:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm hook ls lodash
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Update an existing hook's url:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm hook update id-deadbeef https://my-new-website.here/
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Remove a hook:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm hook rm id-deadbeef
|
||||
.fi
|
||||
.RE
|
||||
.SS "Configuration"
|
||||
.SS "\fBregistry\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "https://registry.npmjs.org/"
|
||||
.IP \(bu 4
|
||||
Type: URL
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The base URL of the npm registry.
|
||||
.SS "\fBotp\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm access\fR.
|
||||
.P
|
||||
If not set, and a registry response fails with a challenge for a one-time password, npm will prompt on the command line for one.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
\fB"Introducing Hooks" blog post\fR \fI\(lahttps://blog.npmjs.org/post/145260155635/introducing-hooks-get-notifications-of-npm\(ra\fR
|
||||
.RE 0
|
||||
366
Dependencies/NodeJS/node_modules/npm/man/man1/npm-init.1
generated
vendored
Normal file
366
Dependencies/NodeJS/node_modules/npm/man/man1/npm-init.1
generated
vendored
Normal file
@ -0,0 +1,366 @@
|
||||
.TH "NPM-INIT" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-init\fR - Create a package.json file
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm init <package-spec> (same as `npx create-<package-spec>`)
|
||||
npm init <@scope> (same as `npx <@scope>/create`)
|
||||
|
||||
aliases: create, innit
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
\fBnpm init <initializer>\fR can be used to set up a new or existing npm package.
|
||||
.P
|
||||
\fBinitializer\fR in this case is an npm package named \fBcreate-<initializer>\fR, which will be installed by npm help npm-exec, and then have its main bin executed -- presumably creating or updating \fBpackage.json\fR and running any other initialization-related operations.
|
||||
.P
|
||||
The init command is transformed to a corresponding \fBnpm exec\fR operation as follows:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
\fBnpm init foo\fR -> \fBnpm exec create-foo\fR
|
||||
.IP \(bu 4
|
||||
\fBnpm init @usr/foo\fR -> \fBnpm exec @usr/create-foo\fR
|
||||
.IP \(bu 4
|
||||
\fBnpm init @usr\fR -> \fBnpm exec @usr/create\fR
|
||||
.IP \(bu 4
|
||||
\fBnpm init @usr@2.0.0\fR -> \fBnpm exec @usr/create@2.0.0\fR
|
||||
.IP \(bu 4
|
||||
\fBnpm init @usr/foo@2.0.0\fR -> \fBnpm exec @usr/create-foo@2.0.0\fR
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If the initializer is omitted (by just calling \fBnpm init\fR), 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 \fB-y\fR/\fB--yes\fR to skip the questionnaire altogether. If you pass \fB--scope\fR, it will create a scoped package.
|
||||
.P
|
||||
\fINote:\fR if a user already has the \fBcreate-<initializer>\fR package globally installed, that will be what \fBnpm init\fR uses. If you want npm to use the latest version, or another specific version you must specify it:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
\fBnpm init foo@latest\fR # fetches and runs the latest \fBcreate-foo\fR from the registry
|
||||
.IP \(bu 4
|
||||
\fBnpm init foo@1.2.3\fR # runs \fBcreate-foo@1.2.3\fR specifically
|
||||
.RE 0
|
||||
|
||||
.SS "Forwarding additional options"
|
||||
.P
|
||||
Any additional options will be passed directly to the command, so \fBnpm init
|
||||
foo -- --hello\fR will map to \fBnpm exec -- create-foo --hello\fR.
|
||||
.P
|
||||
To better illustrate how options are forwarded, here's a more evolved example showing options passed to both the \fBnpm cli\fR and a create package, both following commands are equivalent:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
\fBnpm init foo -y --registry=<url> -- --hello -a\fR
|
||||
.IP \(bu 4
|
||||
\fBnpm exec -y --registry=<url> -- create-foo --hello -a\fR
|
||||
.RE 0
|
||||
|
||||
.SS "Examples"
|
||||
.P
|
||||
Create a new React-based project using \fB\fBcreate-react-app\fR\fR \fI\(lahttps://npm.im/create-react-app\(ra\fR:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm init react-app ./my-react-app
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Create a new \fBesm\fR-compatible package using \fB\fBcreate-esm\fR\fR \fI\(lahttps://npm.im/create-esm\(ra\fR:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ mkdir my-esm-lib && cd my-esm-lib
|
||||
$ npm init esm --yes
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Generate a plain old package.json using legacy init:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ mkdir my-npm-pkg && cd my-npm-pkg
|
||||
$ git init
|
||||
$ npm init
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Generate it without having it ask any questions:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm init -y
|
||||
.fi
|
||||
.RE
|
||||
.SS "Workspaces support"
|
||||
.P
|
||||
It's possible to create a new workspace within your project by using the \fBworkspace\fR config option. When using \fBnpm init -w <dir>\fR the cli will create the folders and boilerplate expected while also adding a reference to your project \fBpackage.json\fR \fB"workspaces": \[lB]\[rB]\fR property in order to make sure that new generated \fBworkspace\fR is properly set up as such.
|
||||
.P
|
||||
Given a project with no workspaces, e.g:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
.
|
||||
+-- package.json
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
You may generate a new workspace using the legacy init:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm init -w packages/a
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
That will generate a new folder and \fBpackage.json\fR file, while also updating your top-level \fBpackage.json\fR to add the reference to this new workspace:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
.
|
||||
+-- package.json
|
||||
`-- packages
|
||||
`-- a
|
||||
`-- package.json
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
The workspaces init also supports the \fBnpm init <initializer> -w <dir>\fR syntax, following the same set of rules explained earlier in the initial \fBDescription\fR section of this page. Similar to the previous example of creating a new React-based project using \fB\fBcreate-react-app\fR\fR \fI\(lahttps://npm.im/create-react-app\(ra\fR, the following syntax will make sure to create the new react app as a nested \fBworkspace\fR within your project and configure your \fBpackage.json\fR to recognize it as such:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm init -w packages/my-react-app react-app .
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
This will make sure to generate your react app as expected, one important consideration to have in mind is that \fBnpm exec\fR is going to be run in the context of the newly created folder for that workspace, and that's the reason why in this example the initializer uses the initializer name followed with a dot to represent the current directory in that context, e.g: \fBreact-app .\fR:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
.
|
||||
+-- package.json
|
||||
`-- packages
|
||||
+-- a
|
||||
| `-- package.json
|
||||
`-- my-react-app
|
||||
+-- README
|
||||
+-- package.json
|
||||
`-- ...
|
||||
.fi
|
||||
.RE
|
||||
.SS "Configuration"
|
||||
.SS "\fBinit-author-name\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: ""
|
||||
.IP \(bu 4
|
||||
Type: String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The value \fBnpm init\fR should use by default for the package author's name.
|
||||
.SS "\fBinit-author-url\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: ""
|
||||
.IP \(bu 4
|
||||
Type: "" or URL
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The value \fBnpm init\fR should use by default for the package author's homepage.
|
||||
.SS "\fBinit-license\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "ISC"
|
||||
.IP \(bu 4
|
||||
Type: String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The value \fBnpm init\fR should use by default for the package license.
|
||||
.SS "\fBinit-module\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "~/.npm-init.js"
|
||||
.IP \(bu 4
|
||||
Type: Path
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
A module that will be loaded by the \fBnpm init\fR command. See the documentation for the \fBinit-package-json\fR \fI\(lahttps://github.com/npm/init-package-json\(ra\fR module for more information, or npm help init.
|
||||
.SS "\fBinit-version\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "1.0.0"
|
||||
.IP \(bu 4
|
||||
Type: SemVer string
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The value that \fBnpm init\fR should use by default for the package version number, if not already set in package.json.
|
||||
.SS "\fByes\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Automatically answer "yes" to any prompts that npm might print on the command line.
|
||||
.SS "\fBforce\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Removes various protections against unfortunate side effects, common mistakes, unnecessary performance degradation, and malicious input.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Allow clobbering non-npm files in global installs.
|
||||
.IP \(bu 4
|
||||
Allow the \fBnpm version\fR command to work on an unclean git repository.
|
||||
.IP \(bu 4
|
||||
Allow deleting the cache folder with \fBnpm cache clean\fR.
|
||||
.IP \(bu 4
|
||||
Allow installing packages that have an \fBengines\fR declaration requiring a different version of npm.
|
||||
.IP \(bu 4
|
||||
Allow installing packages that have an \fBengines\fR declaration requiring a different version of \fBnode\fR, even if \fB--engine-strict\fR is enabled.
|
||||
.IP \(bu 4
|
||||
Allow \fBnpm audit fix\fR to install modules outside your stated dependency range (including SemVer-major changes).
|
||||
.IP \(bu 4
|
||||
Allow unpublishing all versions of a published package.
|
||||
.IP \(bu 4
|
||||
Allow conflicting peerDependencies to be installed in the root project.
|
||||
.IP \(bu 4
|
||||
Implicitly set \fB--yes\fR during \fBnpm init\fR.
|
||||
.IP \(bu 4
|
||||
Allow clobbering existing values in \fBnpm pkg\fR
|
||||
.IP \(bu 4
|
||||
Allow unpublishing of entire packages (not just a single version).
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If you don't have a clear idea of what you want to do, it is strongly recommended that you do not use this option!
|
||||
.SS "\fBscope\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: the scope of the current project, if any, or ""
|
||||
.IP \(bu 4
|
||||
Type: String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Associate an operation with a scope for a scoped registry.
|
||||
.P
|
||||
Useful when logging in to or out of a private registry:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
# log in, linking the scope to the custom registry
|
||||
npm login --scope=@mycorp --registry=https://registry.mycorp.com
|
||||
|
||||
# log out, removing the link and the auth token
|
||||
npm logout --scope=@mycorp
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
This will cause \fB@mycorp\fR to be mapped to the registry for future installation of packages specified according to the pattern \fB@mycorp/package\fR.
|
||||
.P
|
||||
This will also cause \fBnpm init\fR to create a scoped package.
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
# accept all defaults, and create a package named "@foo/whatever",
|
||||
# instead of just named "whatever"
|
||||
npm init --scope=@foo --yes
|
||||
.fi
|
||||
.RE
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces-update\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If set to true, the npm cli will run an update after operations that may possibly change the workspaces installed to the \fBnode_modules\fR folder.
|
||||
.SS "\fBinclude-workspace-root\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
.P
|
||||
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help "package spec"
|
||||
.IP \(bu 4
|
||||
\fBinit-package-json module\fR \fI\(lahttp://npm.im/init-package-json\(ra\fR
|
||||
.IP \(bu 4
|
||||
\fBpackage.json\fR \fI\(la/configuring-npm/package-json\(ra\fR
|
||||
.IP \(bu 4
|
||||
npm help version
|
||||
.IP \(bu 4
|
||||
npm help scope
|
||||
.IP \(bu 4
|
||||
npm help exec
|
||||
.IP \(bu 4
|
||||
npm help workspaces
|
||||
.RE 0
|
||||
239
Dependencies/NodeJS/node_modules/npm/man/man1/npm-install-ci-test.1
generated
vendored
Normal file
239
Dependencies/NodeJS/node_modules/npm/man/man1/npm-install-ci-test.1
generated
vendored
Normal file
@ -0,0 +1,239 @@
|
||||
.TH "NPM-INSTALL-CI-TEST" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-install-ci-test\fR - Install a project with a clean slate and run tests
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm install-ci-test
|
||||
|
||||
aliases: cit, clean-install-test, sit
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
This command runs \fBnpm ci\fR followed immediately by \fBnpm test\fR.
|
||||
.SS "Configuration"
|
||||
.SS "\fBinstall-strategy\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "hoisted"
|
||||
.IP \(bu 4
|
||||
Type: "hoisted", "nested", "shallow", or "linked"
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Sets the strategy for installing packages in node_modules. hoisted (default): Install non-duplicated in top-level, and duplicated as necessary within directory structure. nested: (formerly --legacy-bundling) install in place, no hoisting. shallow (formerly --global-style) only install direct deps at top-level. linked: (experimental) install in node_modules/.store, link in place, unhoisted.
|
||||
.SS "\fBlegacy-bundling\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.IP \(bu 4
|
||||
DEPRECATED: This option has been deprecated in favor of \fB--install-strategy=nested\fR
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Instead of hoisting package installs in \fBnode_modules\fR, install packages in the same manner that they are depended on. This may cause very deep directory structures and duplicate package installs as there is no de-duplicating. Sets \fB--install-strategy=nested\fR.
|
||||
.SS "\fBglobal-style\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.IP \(bu 4
|
||||
DEPRECATED: This option has been deprecated in favor of \fB--install-strategy=shallow\fR
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Only install direct dependencies in the top level \fBnode_modules\fR, but hoist on deeper dependencies. Sets \fB--install-strategy=shallow\fR.
|
||||
.SS "\fBomit\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production', otherwise empty.
|
||||
.IP \(bu 4
|
||||
Type: "dev", "optional", or "peer" (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Dependency types to omit from the installation tree on disk.
|
||||
.P
|
||||
Note that these dependencies \fIare\fR still resolved and added to the \fBpackage-lock.json\fR or \fBnpm-shrinkwrap.json\fR file. They are just not physically installed on disk.
|
||||
.P
|
||||
If a package type appears in both the \fB--include\fR and \fB--omit\fR lists, then it will be included.
|
||||
.P
|
||||
If the resulting omit list includes \fB'dev'\fR, then the \fBNODE_ENV\fR environment variable will be set to \fB'production'\fR for all lifecycle scripts.
|
||||
.SS "\fBinclude\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Option that allows for defining which types of dependencies to install.
|
||||
.P
|
||||
This is the inverse of \fB--omit=<type>\fR.
|
||||
.P
|
||||
Dependency types specified in \fB--include\fR will not be omitted, regardless of the order in which omit/include are specified on the command-line.
|
||||
.SS "\fBstrict-peer-deps\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If set to \fBtrue\fR, and \fB--legacy-peer-deps\fR is not set, then \fIany\fR conflicting \fBpeerDependencies\fR will be treated as an install failure, even if npm could reasonably guess the appropriate resolution based on non-peer dependency relationships.
|
||||
.P
|
||||
By default, conflicting \fBpeerDependencies\fR deep in the dependency graph will be resolved using the nearest non-peer dependency specification, even if doing so will result in some packages receiving a peer dependency outside the range set in their package's \fBpeerDependencies\fR object.
|
||||
.P
|
||||
When such an override is performed, a warning is printed, explaining the conflict and the packages involved. If \fB--strict-peer-deps\fR is set, then this warning is treated as a failure.
|
||||
.SS "\fBforeground-scripts\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: \fBfalse\fR unless when using \fBnpm pack\fR or \fBnpm publish\fR where it defaults to \fBtrue\fR
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Run all build scripts (ie, \fBpreinstall\fR, \fBinstall\fR, and \fBpostinstall\fR) scripts for installed packages in the foreground process, sharing standard input, output, and error with the main npm process.
|
||||
.P
|
||||
Note that this will generally make installs run slower, and be much noisier, but can be useful for debugging.
|
||||
.SS "\fBignore-scripts\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If true, npm does not run scripts specified in package.json files.
|
||||
.P
|
||||
Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run-script\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts.
|
||||
.SS "\fBaudit\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When "true" submit audit reports alongside the current npm command to the default registry and all registries configured for scopes. See the documentation for npm help audit for details on what is submitted.
|
||||
.SS "\fBbin-links\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Tells npm to create symlinks (or \fB.cmd\fR shims on Windows) for package executables.
|
||||
.P
|
||||
Set to false to have it not do this. This can be used to work around the fact that some file systems don't support symlinks, even on ostensibly Unix systems.
|
||||
.SS "\fBfund\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When "true" displays the message at the end of each \fBnpm install\fR acknowledging the number of dependencies looking for funding. See npm help fund for details.
|
||||
.SS "\fBdry-run\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, \fBinstall\fR, \fBupdate\fR, \fBdedupe\fR, \fBuninstall\fR, as well as \fBpack\fR and \fBpublish\fR.
|
||||
.P
|
||||
Note: This is NOT honored by other network related commands, eg \fBdist-tags\fR, \fBowner\fR, etc.
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinclude-workspace-root\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
.P
|
||||
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinstall-links\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set file: protocol dependencies will be packed and installed as regular dependencies instead of creating a symlink. This option has no effect on workspaces.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help install-test
|
||||
.IP \(bu 4
|
||||
npm help ci
|
||||
.IP \(bu 4
|
||||
npm help test
|
||||
.RE 0
|
||||
346
Dependencies/NodeJS/node_modules/npm/man/man1/npm-install-test.1
generated
vendored
Normal file
346
Dependencies/NodeJS/node_modules/npm/man/man1/npm-install-test.1
generated
vendored
Normal file
@ -0,0 +1,346 @@
|
||||
.TH "NPM-INSTALL-TEST" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-install-test\fR - Install package(s) and run tests
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm install-test \[lB]<package-spec> ...\[rB]
|
||||
|
||||
alias: it
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
This command runs an \fBnpm install\fR followed immediately by an \fBnpm test\fR. It takes exactly the same arguments as \fBnpm install\fR.
|
||||
.SS "Configuration"
|
||||
.SS "\fBsave\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: \fBtrue\fR unless when using \fBnpm update\fR where it defaults to \fBfalse\fR
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Save installed packages to a \fBpackage.json\fR file as dependencies.
|
||||
.P
|
||||
When used with the \fBnpm rm\fR command, removes the dependency from \fBpackage.json\fR.
|
||||
.P
|
||||
Will also prevent writing to \fBpackage-lock.json\fR if set to \fBfalse\fR.
|
||||
.SS "\fBsave-exact\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Dependencies saved to package.json will be configured with an exact version rather than using npm's default semver range operator.
|
||||
.SS "\fBglobal\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Operates in "global" mode, so that packages are installed into the \fBprefix\fR folder instead of the current working directory. See npm help folders for more on the differences in behavior.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
packages are installed into the \fB{prefix}/lib/node_modules\fR folder, instead of the current working directory.
|
||||
.IP \(bu 4
|
||||
bin files are linked to \fB{prefix}/bin\fR
|
||||
.IP \(bu 4
|
||||
man pages are linked to \fB{prefix}/share/man\fR
|
||||
.RE 0
|
||||
|
||||
.SS "\fBinstall-strategy\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "hoisted"
|
||||
.IP \(bu 4
|
||||
Type: "hoisted", "nested", "shallow", or "linked"
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Sets the strategy for installing packages in node_modules. hoisted (default): Install non-duplicated in top-level, and duplicated as necessary within directory structure. nested: (formerly --legacy-bundling) install in place, no hoisting. shallow (formerly --global-style) only install direct deps at top-level. linked: (experimental) install in node_modules/.store, link in place, unhoisted.
|
||||
.SS "\fBlegacy-bundling\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.IP \(bu 4
|
||||
DEPRECATED: This option has been deprecated in favor of \fB--install-strategy=nested\fR
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Instead of hoisting package installs in \fBnode_modules\fR, install packages in the same manner that they are depended on. This may cause very deep directory structures and duplicate package installs as there is no de-duplicating. Sets \fB--install-strategy=nested\fR.
|
||||
.SS "\fBglobal-style\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.IP \(bu 4
|
||||
DEPRECATED: This option has been deprecated in favor of \fB--install-strategy=shallow\fR
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Only install direct dependencies in the top level \fBnode_modules\fR, but hoist on deeper dependencies. Sets \fB--install-strategy=shallow\fR.
|
||||
.SS "\fBomit\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production', otherwise empty.
|
||||
.IP \(bu 4
|
||||
Type: "dev", "optional", or "peer" (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Dependency types to omit from the installation tree on disk.
|
||||
.P
|
||||
Note that these dependencies \fIare\fR still resolved and added to the \fBpackage-lock.json\fR or \fBnpm-shrinkwrap.json\fR file. They are just not physically installed on disk.
|
||||
.P
|
||||
If a package type appears in both the \fB--include\fR and \fB--omit\fR lists, then it will be included.
|
||||
.P
|
||||
If the resulting omit list includes \fB'dev'\fR, then the \fBNODE_ENV\fR environment variable will be set to \fB'production'\fR for all lifecycle scripts.
|
||||
.SS "\fBinclude\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Option that allows for defining which types of dependencies to install.
|
||||
.P
|
||||
This is the inverse of \fB--omit=<type>\fR.
|
||||
.P
|
||||
Dependency types specified in \fB--include\fR will not be omitted, regardless of the order in which omit/include are specified on the command-line.
|
||||
.SS "\fBstrict-peer-deps\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If set to \fBtrue\fR, and \fB--legacy-peer-deps\fR is not set, then \fIany\fR conflicting \fBpeerDependencies\fR will be treated as an install failure, even if npm could reasonably guess the appropriate resolution based on non-peer dependency relationships.
|
||||
.P
|
||||
By default, conflicting \fBpeerDependencies\fR deep in the dependency graph will be resolved using the nearest non-peer dependency specification, even if doing so will result in some packages receiving a peer dependency outside the range set in their package's \fBpeerDependencies\fR object.
|
||||
.P
|
||||
When such an override is performed, a warning is printed, explaining the conflict and the packages involved. If \fB--strict-peer-deps\fR is set, then this warning is treated as a failure.
|
||||
.SS "\fBprefer-dedupe\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Prefer to deduplicate packages if possible, rather than choosing a newer version of a dependency.
|
||||
.SS "\fBpackage-lock\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If set to false, then ignore \fBpackage-lock.json\fR files when installing. This will also prevent \fIwriting\fR \fBpackage-lock.json\fR if \fBsave\fR is true.
|
||||
.SS "\fBpackage-lock-only\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If set to true, the current operation will only use the \fBpackage-lock.json\fR, ignoring \fBnode_modules\fR.
|
||||
.P
|
||||
For \fBupdate\fR this means only the \fBpackage-lock.json\fR will be updated, instead of checking \fBnode_modules\fR and downloading dependencies.
|
||||
.P
|
||||
For \fBlist\fR this means the output will be based on the tree described by the \fBpackage-lock.json\fR, rather than the contents of \fBnode_modules\fR.
|
||||
.SS "\fBforeground-scripts\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: \fBfalse\fR unless when using \fBnpm pack\fR or \fBnpm publish\fR where it defaults to \fBtrue\fR
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Run all build scripts (ie, \fBpreinstall\fR, \fBinstall\fR, and \fBpostinstall\fR) scripts for installed packages in the foreground process, sharing standard input, output, and error with the main npm process.
|
||||
.P
|
||||
Note that this will generally make installs run slower, and be much noisier, but can be useful for debugging.
|
||||
.SS "\fBignore-scripts\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If true, npm does not run scripts specified in package.json files.
|
||||
.P
|
||||
Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run-script\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts.
|
||||
.SS "\fBaudit\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When "true" submit audit reports alongside the current npm command to the default registry and all registries configured for scopes. See the documentation for npm help audit for details on what is submitted.
|
||||
.SS "\fBbin-links\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Tells npm to create symlinks (or \fB.cmd\fR shims on Windows) for package executables.
|
||||
.P
|
||||
Set to false to have it not do this. This can be used to work around the fact that some file systems don't support symlinks, even on ostensibly Unix systems.
|
||||
.SS "\fBfund\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When "true" displays the message at the end of each \fBnpm install\fR acknowledging the number of dependencies looking for funding. See npm help fund for details.
|
||||
.SS "\fBdry-run\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, \fBinstall\fR, \fBupdate\fR, \fBdedupe\fR, \fBuninstall\fR, as well as \fBpack\fR and \fBpublish\fR.
|
||||
.P
|
||||
Note: This is NOT honored by other network related commands, eg \fBdist-tags\fR, \fBowner\fR, etc.
|
||||
.SS "\fBcpu\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Override CPU architecture of native modules to install. Acceptable values are same as \fBcpu\fR field of package.json, which comes from \fBprocess.arch\fR.
|
||||
.SS "\fBos\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Override OS of native modules to install. Acceptable values are same as \fBos\fR field of package.json, which comes from \fBprocess.platform\fR.
|
||||
.SS "\fBlibc\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Override libc of native modules to install. Acceptable values are same as \fBlibc\fR field of package.json
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinclude-workspace-root\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
.P
|
||||
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinstall-links\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set file: protocol dependencies will be packed and installed as regular dependencies instead of creating a symlink. This option has no effect on workspaces.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help install
|
||||
.IP \(bu 4
|
||||
npm help install-ci-test
|
||||
.IP \(bu 4
|
||||
npm help test
|
||||
.RE 0
|
||||
762
Dependencies/NodeJS/node_modules/npm/man/man1/npm-install.1
generated
vendored
Normal file
762
Dependencies/NodeJS/node_modules/npm/man/man1/npm-install.1
generated
vendored
Normal file
@ -0,0 +1,762 @@
|
||||
.TH "NPM-INSTALL" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-install\fR - Install a package
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm install \[lB]<package-spec> ...\[rB]
|
||||
|
||||
aliases: add, i, in, ins, inst, insta, instal, isnt, isnta, isntal, isntall
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
This command installs a package and any packages that it depends on. If the package has a package-lock, or an npm shrinkwrap file, or a yarn lock file, the installation of dependencies will be driven by that, respecting the following order of precedence:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
\fBnpm-shrinkwrap.json\fR
|
||||
.IP \(bu 4
|
||||
\fBpackage-lock.json\fR
|
||||
.IP \(bu 4
|
||||
\fByarn.lock\fR
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
See \fBpackage-lock.json\fR \fI\(la/configuring-npm/package-lock-json\(ra\fR and npm help shrinkwrap.
|
||||
.P
|
||||
A \fBpackage\fR is:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
a) a folder containing a program described by a \fB\fBpackage.json\fR\fR \fI\(la/configuring-npm/package-json\(ra\fR file
|
||||
.IP \(bu 4
|
||||
b) a gzipped tarball containing (a)
|
||||
.IP \(bu 4
|
||||
c) a url that resolves to (b)
|
||||
.IP \(bu 4
|
||||
d) a \fB<name>@<version>\fR that is published on the registry (see npm help registry) with (c)
|
||||
.IP \(bu 4
|
||||
e) a \fB<name>@<tag>\fR (see npm help dist-tag) that points to (d)
|
||||
.IP \(bu 4
|
||||
f) a \fB<name>\fR that has a "latest" tag satisfying (e)
|
||||
.IP \(bu 4
|
||||
g) a \fB<git remote url>\fR that resolves to (a)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
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).
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
\fBnpm install\fR (in a package directory, no arguments):
|
||||
.P
|
||||
Install the dependencies to the local \fBnode_modules\fR folder.
|
||||
.P
|
||||
In global mode (ie, with \fB-g\fR or \fB--global\fR appended to the command), it installs the current package context (ie, the current working directory) as a global package.
|
||||
.P
|
||||
By default, \fBnpm install\fR will install all modules listed as dependencies in \fB\fBpackage.json\fR\fR \fI\(la/configuring-npm/package-json\(ra\fR.
|
||||
.P
|
||||
With the \fB--production\fR flag (or when the \fBNODE_ENV\fR environment variable is set to \fBproduction\fR), npm will not install modules listed in \fBdevDependencies\fR. To install all modules listed in both \fBdependencies\fR and \fBdevDependencies\fR when \fBNODE_ENV\fR environment variable is set to \fBproduction\fR, you can use \fB--production=false\fR.
|
||||
.RS 4
|
||||
.P
|
||||
NOTE: The \fB--production\fR flag has no particular meaning when adding a dependency to a project.
|
||||
.RE 0
|
||||
|
||||
.IP \(bu 4
|
||||
\fBnpm install <folder>\fR:
|
||||
.P
|
||||
If \fB<folder>\fR sits inside the root of your project, its dependencies will be installed and may be hoisted to the top-level \fBnode_modules\fR as they would for other types of dependencies. If \fB<folder>\fR sits outside the root of your project, \fInpm will not install the package dependencies\fR in the directory \fB<folder>\fR, but it will create a symlink to \fB<folder>\fR.
|
||||
.RS 4
|
||||
.P
|
||||
NOTE: If you want to install the content of a directory like a package from the registry instead of creating a link, you would need to use the \fB--install-links\fR option.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Example:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm install ../../other-package --install-links
|
||||
npm install ./sub-package
|
||||
.fi
|
||||
.RE
|
||||
.IP \(bu 4
|
||||
\fBnpm install <tarball file>\fR:
|
||||
.P
|
||||
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 help link.
|
||||
.P
|
||||
Tarball requirements:
|
||||
.RS 4
|
||||
.IP \(bu 4
|
||||
The filename \fImust\fR use \fB.tar\fR, \fB.tar.gz\fR, or \fB.tgz\fR as the extension.
|
||||
.IP \(bu 4
|
||||
The package contents should reside in a subfolder inside the tarball (usually it is called \fBpackage/\fR). npm strips one directory layer when installing the package (an equivalent of \fBtar x
|
||||
--strip-components=1\fR is run).
|
||||
.IP \(bu 4
|
||||
The package must contain a \fBpackage.json\fR file with \fBname\fR and \fBversion\fR properties.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Example:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm install ./package.tgz
|
||||
.fi
|
||||
.RE
|
||||
.IP \(bu 4
|
||||
\fBnpm install <tarball url>\fR:
|
||||
.P
|
||||
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://"
|
||||
.P
|
||||
Example:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm install https://github.com/indexzero/forever/tarball/v0.5.6
|
||||
.fi
|
||||
.RE
|
||||
.IP \(bu 4
|
||||
\fBnpm install \[lB]<@scope>/\[rB]<name>\fR:
|
||||
.P
|
||||
Do a \fB<name>@<tag>\fR install, where \fB<tag>\fR is the "tag" config. (See \fB\fBconfig\fR\fR \fI\(la/using-npm/config#tag\(ra\fR. The config's default value is \fBlatest\fR.)
|
||||
.P
|
||||
In most cases, this will install the version of the modules tagged as \fBlatest\fR on the npm registry.
|
||||
.P
|
||||
Example:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm install sax
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
\fBnpm install\fR saves any specified packages into \fBdependencies\fR by default. Additionally, you can control where and how they get saved with some additional flags:
|
||||
.RS 4
|
||||
.IP \(bu 4
|
||||
\fB-P, --save-prod\fR: Package will appear in your \fBdependencies\fR. This is the default unless \fB-D\fR or \fB-O\fR are present.
|
||||
.IP \(bu 4
|
||||
\fB-D, --save-dev\fR: Package will appear in your \fBdevDependencies\fR.
|
||||
.IP \(bu 4
|
||||
\fB--save-peer\fR: Package will appear in your \fBpeerDependencies\fR.
|
||||
.IP \(bu 4
|
||||
\fB-O, --save-optional\fR: Package will appear in your \fBoptionalDependencies\fR.
|
||||
.IP \(bu 4
|
||||
\fB--no-save\fR: Prevents saving to \fBdependencies\fR.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When using any of the above options to save dependencies to your package.json, there are two additional, optional flags:
|
||||
.RS 4
|
||||
.IP \(bu 4
|
||||
\fB-E, --save-exact\fR: Saved dependencies will be configured with an exact version rather than using npm's default semver range operator.
|
||||
.IP \(bu 4
|
||||
\fB-B, --save-bundle\fR: Saved dependencies will also be added to your \fBbundleDependencies\fR list.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Further, if you have an \fBnpm-shrinkwrap.json\fR or \fBpackage-lock.json\fR then it will be updated as well.
|
||||
.P
|
||||
\fB<scope>\fR 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 npm help scope.
|
||||
.P
|
||||
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.
|
||||
.P
|
||||
Examples:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
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
|
||||
.fi
|
||||
.RE
|
||||
.IP \(bu 4
|
||||
\fBnpm install <alias>@npm:<name>\fR:
|
||||
.P
|
||||
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 \fB\fBvalidate-npm-package-name\fR\fR \fI\(lahttps://www.npmjs.com/package/validate-npm-package-name#naming-rules\(ra\fR.
|
||||
.P
|
||||
Examples:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
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
|
||||
.fi
|
||||
.RE
|
||||
.IP \(bu 4
|
||||
\fBnpm install \[lB]<@scope>/\[rB]<name>@<tag>\fR:
|
||||
.P
|
||||
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.
|
||||
.P
|
||||
Example:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm install sax@latest
|
||||
npm install @myorg/mypackage@latest
|
||||
.fi
|
||||
.RE
|
||||
.IP \(bu 4
|
||||
\fBnpm install \[lB]<@scope>/\[rB]<name>@<version>\fR:
|
||||
.P
|
||||
Install the specified version of the package. This will fail if the version has not been published to the registry.
|
||||
.P
|
||||
Example:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm install sax@0.1.1
|
||||
npm install @myorg/privatepackage@1.5.0
|
||||
.fi
|
||||
.RE
|
||||
.IP \(bu 4
|
||||
\fBnpm install \[lB]<@scope>/\[rB]<name>@<version range>\fR:
|
||||
.P
|
||||
Install a version of the package matching the specified version range. This will follow the same rules for resolving dependencies described in \fB\fBpackage.json\fR\fR \fI\(la/configuring-npm/package-json\(ra\fR.
|
||||
.P
|
||||
Note that most version ranges must be put in quotes so that your shell will treat it as a single argument.
|
||||
.P
|
||||
Example:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm install sax@">=0.1.0 <0.2.0"
|
||||
npm install @myorg/privatepackage@"16 - 17"
|
||||
.fi
|
||||
.RE
|
||||
.IP \(bu 4
|
||||
\fBnpm install <git remote url>\fR:
|
||||
.P
|
||||
Installs the package from the hosted git provider, cloning it with \fBgit\fR. For a full git remote url, only that URL will be attempted.
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
<protocol>://\[lB]<user>\[lB]:<password>\[rB]@\[rB]<hostname>\[lB]:<port>\[rB]\[lB]:\[rB]\[lB]/\[rB]<path>\[lB]#<commit-ish> | #semver:<semver>\[rB]
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
\fB<protocol>\fR is one of \fBgit\fR, \fBgit+ssh\fR, \fBgit+http\fR, \fBgit+https\fR, or \fBgit+file\fR.
|
||||
.P
|
||||
If \fB#<commit-ish>\fR is provided, it will be used to clone exactly that commit. If the commit-ish has the format \fB#semver:<semver>\fR, \fB<semver>\fR 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 \fB#<commit-ish>\fR or \fB#semver:<semver>\fR is specified, then the default branch of the repository is used.
|
||||
.P
|
||||
If the repository makes use of submodules, those submodules will be cloned as well.
|
||||
.P
|
||||
If the package being installed contains a \fBprepare\fR script, its \fBdependencies\fR and \fBdevDependencies\fR will be installed, and the prepare script will be run, before the package is packaged and installed.
|
||||
.P
|
||||
The following git environment variables are recognized by npm and will be added to the environment when running git:
|
||||
.RS 4
|
||||
.IP \(bu 4
|
||||
\fBGIT_ASKPASS\fR
|
||||
.IP \(bu 4
|
||||
\fBGIT_EXEC_PATH\fR
|
||||
.IP \(bu 4
|
||||
\fBGIT_PROXY_COMMAND\fR
|
||||
.IP \(bu 4
|
||||
\fBGIT_SSH\fR
|
||||
.IP \(bu 4
|
||||
\fBGIT_SSH_COMMAND\fR
|
||||
.IP \(bu 4
|
||||
\fBGIT_SSL_CAINFO\fR
|
||||
.IP \(bu 4
|
||||
\fBGIT_SSL_NO_VERIFY\fR
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
See the git man page for details.
|
||||
.P
|
||||
Examples:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm install git+ssh://git@github.com:npm/cli.git#v1.0.27
|
||||
npm install git+ssh://git@github.com:npm/cli#pull/273
|
||||
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
|
||||
.fi
|
||||
.RE
|
||||
.IP \(bu 4
|
||||
\fBnpm install <githubname>/<githubrepo>\[lB]#<commit-ish>\[rB]\fR:
|
||||
.IP \(bu 4
|
||||
\fBnpm install github:<githubname>/<githubrepo>\[lB]#<commit-ish>\[rB]\fR:
|
||||
.P
|
||||
Install the package at \fBhttps://github.com/githubname/githubrepo\fR by attempting to clone it using \fBgit\fR.
|
||||
.P
|
||||
If \fB#<commit-ish>\fR is provided, it will be used to clone exactly that commit. If the commit-ish has the format \fB#semver:<semver>\fR, \fB<semver>\fR 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 \fB#<commit-ish>\fR or \fB#semver:<semver>\fR is specified, then the default branch is used.
|
||||
.P
|
||||
As with regular git dependencies, \fBdependencies\fR and \fBdevDependencies\fR will be installed if the package has a \fBprepare\fR script before the package is done installing.
|
||||
.P
|
||||
Examples:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm install mygithubuser/myproject
|
||||
npm install github:mygithubuser/myproject
|
||||
.fi
|
||||
.RE
|
||||
.IP \(bu 4
|
||||
\fBnpm install gist:\[lB]<githubname>/\[rB]<gistID>\[lB]#<commit-ish>|#semver:<semver>\[rB]\fR:
|
||||
.P
|
||||
Install the package at \fBhttps://gist.github.com/gistID\fR by attempting to clone it using \fBgit\fR. The GitHub username associated with the gist is optional and will not be saved in \fBpackage.json\fR.
|
||||
.P
|
||||
As with regular git dependencies, \fBdependencies\fR and \fBdevDependencies\fR will be installed if the package has a \fBprepare\fR script before the package is done installing.
|
||||
.P
|
||||
Example:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm install gist:101a11beef
|
||||
.fi
|
||||
.RE
|
||||
.IP \(bu 4
|
||||
\fBnpm install bitbucket:<bitbucketname>/<bitbucketrepo>\[lB]#<commit-ish>\[rB]\fR:
|
||||
.P
|
||||
Install the package at \fBhttps://bitbucket.org/bitbucketname/bitbucketrepo\fR by attempting to clone it using \fBgit\fR.
|
||||
.P
|
||||
If \fB#<commit-ish>\fR is provided, it will be used to clone exactly that commit. If the commit-ish has the format \fB#semver:<semver>\fR, \fB<semver>\fR 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 \fB#<commit-ish>\fR or \fB#semver:<semver>\fR is specified, then \fBmaster\fR is used.
|
||||
.P
|
||||
As with regular git dependencies, \fBdependencies\fR and \fBdevDependencies\fR will be installed if the package has a \fBprepare\fR script before the package is done installing.
|
||||
.P
|
||||
Example:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm install bitbucket:mybitbucketuser/myproject
|
||||
.fi
|
||||
.RE
|
||||
.IP \(bu 4
|
||||
\fBnpm install gitlab:<gitlabname>/<gitlabrepo>\[lB]#<commit-ish>\[rB]\fR:
|
||||
.P
|
||||
Install the package at \fBhttps://gitlab.com/gitlabname/gitlabrepo\fR by attempting to clone it using \fBgit\fR.
|
||||
.P
|
||||
If \fB#<commit-ish>\fR is provided, it will be used to clone exactly that commit. If the commit-ish has the format \fB#semver:<semver>\fR, \fB<semver>\fR 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 \fB#<commit-ish>\fR or \fB#semver:<semver>\fR is specified, then \fBmaster\fR is used.
|
||||
.P
|
||||
As with regular git dependencies, \fBdependencies\fR and \fBdevDependencies\fR will be installed if the package has a \fBprepare\fR script before the package is done installing.
|
||||
.P
|
||||
Example:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm install gitlab:mygitlabuser/myproject
|
||||
npm install gitlab:myusr/myproj#semver:^5.0
|
||||
.fi
|
||||
.RE
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
You may combine multiple arguments and even multiple types of arguments. For example:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm install sax@">=0.1.0 <0.2.0" bench supervisor
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
The \fB--tag\fR 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.
|
||||
.P
|
||||
The \fB--dry-run\fR argument will report in the usual way what the install would have done without actually installing anything.
|
||||
.P
|
||||
The \fB--package-lock-only\fR argument will only update the \fBpackage-lock.json\fR, instead of checking \fBnode_modules\fR and downloading dependencies.
|
||||
.P
|
||||
The \fB-f\fR or \fB--force\fR argument will force npm to fetch remote resources even if a local copy exists on disk.
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm install sax --force
|
||||
.fi
|
||||
.RE
|
||||
.SS "Configuration"
|
||||
.P
|
||||
See the npm help config help doc. Many of the configuration params have some effect on installation, since that's most of what npm does.
|
||||
.P
|
||||
These are some of the most common options related to installation.
|
||||
.SS "\fBsave\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: \fBtrue\fR unless when using \fBnpm update\fR where it defaults to \fBfalse\fR
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Save installed packages to a \fBpackage.json\fR file as dependencies.
|
||||
.P
|
||||
When used with the \fBnpm rm\fR command, removes the dependency from \fBpackage.json\fR.
|
||||
.P
|
||||
Will also prevent writing to \fBpackage-lock.json\fR if set to \fBfalse\fR.
|
||||
.SS "\fBsave-exact\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Dependencies saved to package.json will be configured with an exact version rather than using npm's default semver range operator.
|
||||
.SS "\fBglobal\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Operates in "global" mode, so that packages are installed into the \fBprefix\fR folder instead of the current working directory. See npm help folders for more on the differences in behavior.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
packages are installed into the \fB{prefix}/lib/node_modules\fR folder, instead of the current working directory.
|
||||
.IP \(bu 4
|
||||
bin files are linked to \fB{prefix}/bin\fR
|
||||
.IP \(bu 4
|
||||
man pages are linked to \fB{prefix}/share/man\fR
|
||||
.RE 0
|
||||
|
||||
.SS "\fBinstall-strategy\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "hoisted"
|
||||
.IP \(bu 4
|
||||
Type: "hoisted", "nested", "shallow", or "linked"
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Sets the strategy for installing packages in node_modules. hoisted (default): Install non-duplicated in top-level, and duplicated as necessary within directory structure. nested: (formerly --legacy-bundling) install in place, no hoisting. shallow (formerly --global-style) only install direct deps at top-level. linked: (experimental) install in node_modules/.store, link in place, unhoisted.
|
||||
.SS "\fBlegacy-bundling\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.IP \(bu 4
|
||||
DEPRECATED: This option has been deprecated in favor of \fB--install-strategy=nested\fR
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Instead of hoisting package installs in \fBnode_modules\fR, install packages in the same manner that they are depended on. This may cause very deep directory structures and duplicate package installs as there is no de-duplicating. Sets \fB--install-strategy=nested\fR.
|
||||
.SS "\fBglobal-style\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.IP \(bu 4
|
||||
DEPRECATED: This option has been deprecated in favor of \fB--install-strategy=shallow\fR
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Only install direct dependencies in the top level \fBnode_modules\fR, but hoist on deeper dependencies. Sets \fB--install-strategy=shallow\fR.
|
||||
.SS "\fBomit\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production', otherwise empty.
|
||||
.IP \(bu 4
|
||||
Type: "dev", "optional", or "peer" (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Dependency types to omit from the installation tree on disk.
|
||||
.P
|
||||
Note that these dependencies \fIare\fR still resolved and added to the \fBpackage-lock.json\fR or \fBnpm-shrinkwrap.json\fR file. They are just not physically installed on disk.
|
||||
.P
|
||||
If a package type appears in both the \fB--include\fR and \fB--omit\fR lists, then it will be included.
|
||||
.P
|
||||
If the resulting omit list includes \fB'dev'\fR, then the \fBNODE_ENV\fR environment variable will be set to \fB'production'\fR for all lifecycle scripts.
|
||||
.SS "\fBinclude\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Option that allows for defining which types of dependencies to install.
|
||||
.P
|
||||
This is the inverse of \fB--omit=<type>\fR.
|
||||
.P
|
||||
Dependency types specified in \fB--include\fR will not be omitted, regardless of the order in which omit/include are specified on the command-line.
|
||||
.SS "\fBstrict-peer-deps\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If set to \fBtrue\fR, and \fB--legacy-peer-deps\fR is not set, then \fIany\fR conflicting \fBpeerDependencies\fR will be treated as an install failure, even if npm could reasonably guess the appropriate resolution based on non-peer dependency relationships.
|
||||
.P
|
||||
By default, conflicting \fBpeerDependencies\fR deep in the dependency graph will be resolved using the nearest non-peer dependency specification, even if doing so will result in some packages receiving a peer dependency outside the range set in their package's \fBpeerDependencies\fR object.
|
||||
.P
|
||||
When such an override is performed, a warning is printed, explaining the conflict and the packages involved. If \fB--strict-peer-deps\fR is set, then this warning is treated as a failure.
|
||||
.SS "\fBprefer-dedupe\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Prefer to deduplicate packages if possible, rather than choosing a newer version of a dependency.
|
||||
.SS "\fBpackage-lock\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If set to false, then ignore \fBpackage-lock.json\fR files when installing. This will also prevent \fIwriting\fR \fBpackage-lock.json\fR if \fBsave\fR is true.
|
||||
.SS "\fBpackage-lock-only\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If set to true, the current operation will only use the \fBpackage-lock.json\fR, ignoring \fBnode_modules\fR.
|
||||
.P
|
||||
For \fBupdate\fR this means only the \fBpackage-lock.json\fR will be updated, instead of checking \fBnode_modules\fR and downloading dependencies.
|
||||
.P
|
||||
For \fBlist\fR this means the output will be based on the tree described by the \fBpackage-lock.json\fR, rather than the contents of \fBnode_modules\fR.
|
||||
.SS "\fBforeground-scripts\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: \fBfalse\fR unless when using \fBnpm pack\fR or \fBnpm publish\fR where it defaults to \fBtrue\fR
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Run all build scripts (ie, \fBpreinstall\fR, \fBinstall\fR, and \fBpostinstall\fR) scripts for installed packages in the foreground process, sharing standard input, output, and error with the main npm process.
|
||||
.P
|
||||
Note that this will generally make installs run slower, and be much noisier, but can be useful for debugging.
|
||||
.SS "\fBignore-scripts\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If true, npm does not run scripts specified in package.json files.
|
||||
.P
|
||||
Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run-script\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts.
|
||||
.SS "\fBaudit\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When "true" submit audit reports alongside the current npm command to the default registry and all registries configured for scopes. See the documentation for npm help audit for details on what is submitted.
|
||||
.SS "\fBbin-links\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Tells npm to create symlinks (or \fB.cmd\fR shims on Windows) for package executables.
|
||||
.P
|
||||
Set to false to have it not do this. This can be used to work around the fact that some file systems don't support symlinks, even on ostensibly Unix systems.
|
||||
.SS "\fBfund\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When "true" displays the message at the end of each \fBnpm install\fR acknowledging the number of dependencies looking for funding. See npm help fund for details.
|
||||
.SS "\fBdry-run\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, \fBinstall\fR, \fBupdate\fR, \fBdedupe\fR, \fBuninstall\fR, as well as \fBpack\fR and \fBpublish\fR.
|
||||
.P
|
||||
Note: This is NOT honored by other network related commands, eg \fBdist-tags\fR, \fBowner\fR, etc.
|
||||
.SS "\fBcpu\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Override CPU architecture of native modules to install. Acceptable values are same as \fBcpu\fR field of package.json, which comes from \fBprocess.arch\fR.
|
||||
.SS "\fBos\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Override OS of native modules to install. Acceptable values are same as \fBos\fR field of package.json, which comes from \fBprocess.platform\fR.
|
||||
.SS "\fBlibc\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Override libc of native modules to install. Acceptable values are same as \fBlibc\fR field of package.json
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinclude-workspace-root\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
.P
|
||||
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinstall-links\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set file: protocol dependencies will be packed and installed as regular dependencies instead of creating a symlink. This option has no effect on workspaces.
|
||||
.SS "Algorithm"
|
||||
.P
|
||||
Given a \fBpackage{dep}\fR structure: \fBA{B,C}, B{C}, C{D}\fR, the npm install algorithm produces:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
A
|
||||
+-- B
|
||||
+-- C
|
||||
+-- D
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
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.
|
||||
.P
|
||||
For \fBA{B,C}, B{C,D@1}, C{D@2}\fR, this algorithm produces:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
A
|
||||
+-- B
|
||||
+-- C
|
||||
`-- D@2
|
||||
+-- D@1
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
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.
|
||||
.P
|
||||
See npm help folders for a more detailed description of the specific folder structures that npm creates.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help folders
|
||||
.IP \(bu 4
|
||||
npm help update
|
||||
.IP \(bu 4
|
||||
npm help audit
|
||||
.IP \(bu 4
|
||||
npm help fund
|
||||
.IP \(bu 4
|
||||
npm help link
|
||||
.IP \(bu 4
|
||||
npm help rebuild
|
||||
.IP \(bu 4
|
||||
npm help scripts
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help npmrc
|
||||
.IP \(bu 4
|
||||
npm help registry
|
||||
.IP \(bu 4
|
||||
npm help dist-tag
|
||||
.IP \(bu 4
|
||||
npm help uninstall
|
||||
.IP \(bu 4
|
||||
npm help shrinkwrap
|
||||
.IP \(bu 4
|
||||
\fBpackage.json\fR \fI\(la/configuring-npm/package-json\(ra\fR
|
||||
.IP \(bu 4
|
||||
npm help workspaces
|
||||
.RE 0
|
||||
355
Dependencies/NodeJS/node_modules/npm/man/man1/npm-link.1
generated
vendored
Normal file
355
Dependencies/NodeJS/node_modules/npm/man/man1/npm-link.1
generated
vendored
Normal file
@ -0,0 +1,355 @@
|
||||
.TH "NPM-LINK" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-link\fR - Symlink a package folder
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm link \[lB]<package-spec>\[rB]
|
||||
|
||||
alias: ln
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
This is handy for installing your own stuff, so that you can work on it and test iteratively without having to continually rebuild.
|
||||
.P
|
||||
Package linking is a two-step process.
|
||||
.P
|
||||
First, \fBnpm link\fR in a package folder with no arguments will create a symlink in the global folder \fB{prefix}/lib/node_modules/<package>\fR that links to the package where the \fBnpm link\fR command was executed. It will also link any bins in the package to \fB{prefix}/bin/{name}\fR. Note that \fBnpm link\fR uses the global prefix (see \fBnpm prefix -g\fR for its value).
|
||||
.P
|
||||
Next, in some other location, \fBnpm link package-name\fR will create a symbolic link from globally-installed \fBpackage-name\fR to \fBnode_modules/\fR of the current folder.
|
||||
.P
|
||||
Note that \fBpackage-name\fR is taken from \fBpackage.json\fR, \fInot\fR from the directory name.
|
||||
.P
|
||||
The package name can be optionally prefixed with a scope. See npm help scope. The scope must be preceded by an @-symbol and followed by a slash.
|
||||
.P
|
||||
When creating tarballs for \fBnpm publish\fR, the linked packages are "snapshotted" to their current state by resolving the symbolic links, if they are included in \fBbundleDependencies\fR.
|
||||
.P
|
||||
For example:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
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
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Now, any changes to \fB~/projects/node-redis\fR will be reflected in \fB~/projects/node-bloggy/node_modules/node-redis/\fR. Note that the link should be to the package name, not the directory name for that package.
|
||||
.P
|
||||
You may also shortcut the two steps in one. For example, to do the above use-case in a shorter way:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
cd ~/projects/node-bloggy # go into the dir of your main project
|
||||
npm link ../node-redis # link the dir of your dependency
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
The second line is the equivalent of doing:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
(cd ../node-redis; npm link)
|
||||
npm link redis
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
That is, it first creates a global link, and then links the global installation target into your project's \fBnode_modules\fR folder.
|
||||
.P
|
||||
Note that in this case, you are referring to the directory name, \fBnode-redis\fR, rather than the package name \fBredis\fR.
|
||||
.P
|
||||
If your linked package is scoped (see npm help scope) your link command must include that scope, e.g.
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm link @myorg/privatepackage
|
||||
.fi
|
||||
.RE
|
||||
.SS "Caveat"
|
||||
.P
|
||||
Note that package dependencies linked in this way are \fInot\fR saved to \fBpackage.json\fR by default, on the assumption that the intention is to have a link stand in for a regular non-link dependency. Otherwise, for example, if you depend on \fBredis@^3.0.1\fR, and ran \fBnpm link redis\fR, it would replace the \fB^3.0.1\fR dependency with \fBfile:../path/to/node-redis\fR, which you probably don't want! Additionally, other users or developers on your project would run into issues if they do not have their folders set up exactly the same as yours.
|
||||
.P
|
||||
If you are adding a \fInew\fR dependency as a link, you should add it to the relevant metadata by running \fBnpm install <dep> --package-lock-only\fR.
|
||||
.P
|
||||
If you \fIwant\fR to save the \fBfile:\fR reference in your \fBpackage.json\fR and \fBpackage-lock.json\fR files, you can use \fBnpm link <dep> --save\fR to do so.
|
||||
.SS "Workspace Usage"
|
||||
.P
|
||||
\fBnpm link <pkg> --workspace <name>\fR will link the relevant package as a dependency of the specified workspace(s). Note that It may actually be linked into the parent project's \fBnode_modules\fR folder, if there are no conflicting dependencies.
|
||||
.P
|
||||
\fBnpm link --workspace <name>\fR will create a global link to the specified workspace(s).
|
||||
.SS "Configuration"
|
||||
.SS "\fBsave\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: \fBtrue\fR unless when using \fBnpm update\fR where it defaults to \fBfalse\fR
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Save installed packages to a \fBpackage.json\fR file as dependencies.
|
||||
.P
|
||||
When used with the \fBnpm rm\fR command, removes the dependency from \fBpackage.json\fR.
|
||||
.P
|
||||
Will also prevent writing to \fBpackage-lock.json\fR if set to \fBfalse\fR.
|
||||
.SS "\fBsave-exact\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Dependencies saved to package.json will be configured with an exact version rather than using npm's default semver range operator.
|
||||
.SS "\fBglobal\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Operates in "global" mode, so that packages are installed into the \fBprefix\fR folder instead of the current working directory. See npm help folders for more on the differences in behavior.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
packages are installed into the \fB{prefix}/lib/node_modules\fR folder, instead of the current working directory.
|
||||
.IP \(bu 4
|
||||
bin files are linked to \fB{prefix}/bin\fR
|
||||
.IP \(bu 4
|
||||
man pages are linked to \fB{prefix}/share/man\fR
|
||||
.RE 0
|
||||
|
||||
.SS "\fBinstall-strategy\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "hoisted"
|
||||
.IP \(bu 4
|
||||
Type: "hoisted", "nested", "shallow", or "linked"
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Sets the strategy for installing packages in node_modules. hoisted (default): Install non-duplicated in top-level, and duplicated as necessary within directory structure. nested: (formerly --legacy-bundling) install in place, no hoisting. shallow (formerly --global-style) only install direct deps at top-level. linked: (experimental) install in node_modules/.store, link in place, unhoisted.
|
||||
.SS "\fBlegacy-bundling\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.IP \(bu 4
|
||||
DEPRECATED: This option has been deprecated in favor of \fB--install-strategy=nested\fR
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Instead of hoisting package installs in \fBnode_modules\fR, install packages in the same manner that they are depended on. This may cause very deep directory structures and duplicate package installs as there is no de-duplicating. Sets \fB--install-strategy=nested\fR.
|
||||
.SS "\fBglobal-style\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.IP \(bu 4
|
||||
DEPRECATED: This option has been deprecated in favor of \fB--install-strategy=shallow\fR
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Only install direct dependencies in the top level \fBnode_modules\fR, but hoist on deeper dependencies. Sets \fB--install-strategy=shallow\fR.
|
||||
.SS "\fBstrict-peer-deps\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If set to \fBtrue\fR, and \fB--legacy-peer-deps\fR is not set, then \fIany\fR conflicting \fBpeerDependencies\fR will be treated as an install failure, even if npm could reasonably guess the appropriate resolution based on non-peer dependency relationships.
|
||||
.P
|
||||
By default, conflicting \fBpeerDependencies\fR deep in the dependency graph will be resolved using the nearest non-peer dependency specification, even if doing so will result in some packages receiving a peer dependency outside the range set in their package's \fBpeerDependencies\fR object.
|
||||
.P
|
||||
When such an override is performed, a warning is printed, explaining the conflict and the packages involved. If \fB--strict-peer-deps\fR is set, then this warning is treated as a failure.
|
||||
.SS "\fBpackage-lock\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If set to false, then ignore \fBpackage-lock.json\fR files when installing. This will also prevent \fIwriting\fR \fBpackage-lock.json\fR if \fBsave\fR is true.
|
||||
.SS "\fBomit\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production', otherwise empty.
|
||||
.IP \(bu 4
|
||||
Type: "dev", "optional", or "peer" (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Dependency types to omit from the installation tree on disk.
|
||||
.P
|
||||
Note that these dependencies \fIare\fR still resolved and added to the \fBpackage-lock.json\fR or \fBnpm-shrinkwrap.json\fR file. They are just not physically installed on disk.
|
||||
.P
|
||||
If a package type appears in both the \fB--include\fR and \fB--omit\fR lists, then it will be included.
|
||||
.P
|
||||
If the resulting omit list includes \fB'dev'\fR, then the \fBNODE_ENV\fR environment variable will be set to \fB'production'\fR for all lifecycle scripts.
|
||||
.SS "\fBinclude\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Option that allows for defining which types of dependencies to install.
|
||||
.P
|
||||
This is the inverse of \fB--omit=<type>\fR.
|
||||
.P
|
||||
Dependency types specified in \fB--include\fR will not be omitted, regardless of the order in which omit/include are specified on the command-line.
|
||||
.SS "\fBignore-scripts\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If true, npm does not run scripts specified in package.json files.
|
||||
.P
|
||||
Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run-script\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts.
|
||||
.SS "\fBaudit\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When "true" submit audit reports alongside the current npm command to the default registry and all registries configured for scopes. See the documentation for npm help audit for details on what is submitted.
|
||||
.SS "\fBbin-links\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Tells npm to create symlinks (or \fB.cmd\fR shims on Windows) for package executables.
|
||||
.P
|
||||
Set to false to have it not do this. This can be used to work around the fact that some file systems don't support symlinks, even on ostensibly Unix systems.
|
||||
.SS "\fBfund\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When "true" displays the message at the end of each \fBnpm install\fR acknowledging the number of dependencies looking for funding. See npm help fund for details.
|
||||
.SS "\fBdry-run\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, \fBinstall\fR, \fBupdate\fR, \fBdedupe\fR, \fBuninstall\fR, as well as \fBpack\fR and \fBpublish\fR.
|
||||
.P
|
||||
Note: This is NOT honored by other network related commands, eg \fBdist-tags\fR, \fBowner\fR, etc.
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinclude-workspace-root\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
.P
|
||||
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinstall-links\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set file: protocol dependencies will be packed and installed as regular dependencies instead of creating a symlink. This option has no effect on workspaces.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help "package spec"
|
||||
.IP \(bu 4
|
||||
npm help developers
|
||||
.IP \(bu 4
|
||||
\fBpackage.json\fR \fI\(la/configuring-npm/package-json\(ra\fR
|
||||
.IP \(bu 4
|
||||
npm help install
|
||||
.IP \(bu 4
|
||||
npm help folders
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help npmrc
|
||||
.RE 0
|
||||
95
Dependencies/NodeJS/node_modules/npm/man/man1/npm-login.1
generated
vendored
Normal file
95
Dependencies/NodeJS/node_modules/npm/man/man1/npm-login.1
generated
vendored
Normal file
@ -0,0 +1,95 @@
|
||||
.TH "NPM-LOGIN" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-login\fR - Login to a registry user account
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm login
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Description"
|
||||
.P
|
||||
Verify a user in the specified registry, and save the credentials to the \fB.npmrc\fR file. If no registry is specified, the default registry will be used (see npm help config).
|
||||
.P
|
||||
When using \fBlegacy\fR for your \fBauth-type\fR, the username and password, are read in from prompts.
|
||||
.P
|
||||
To reset your password, go to \fI\(lahttps://www.npmjs.com/forgot\(ra\fR
|
||||
.P
|
||||
To change your email address, go to \fI\(lahttps://www.npmjs.com/email-edit\(ra\fR
|
||||
.P
|
||||
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.
|
||||
.SS "Configuration"
|
||||
.SS "\fBregistry\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "https://registry.npmjs.org/"
|
||||
.IP \(bu 4
|
||||
Type: URL
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The base URL of the npm registry.
|
||||
.SS "\fBscope\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: the scope of the current project, if any, or ""
|
||||
.IP \(bu 4
|
||||
Type: String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Associate an operation with a scope for a scoped registry.
|
||||
.P
|
||||
Useful when logging in to or out of a private registry:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
# log in, linking the scope to the custom registry
|
||||
npm login --scope=@mycorp --registry=https://registry.mycorp.com
|
||||
|
||||
# log out, removing the link and the auth token
|
||||
npm logout --scope=@mycorp
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
This will cause \fB@mycorp\fR to be mapped to the registry for future installation of packages specified according to the pattern \fB@mycorp/package\fR.
|
||||
.P
|
||||
This will also cause \fBnpm init\fR to create a scoped package.
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
# accept all defaults, and create a package named "@foo/whatever",
|
||||
# instead of just named "whatever"
|
||||
npm init --scope=@foo --yes
|
||||
.fi
|
||||
.RE
|
||||
.SS "\fBauth-type\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "web"
|
||||
.IP \(bu 4
|
||||
Type: "legacy" or "web"
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
What authentication strategy to use with \fBlogin\fR. Note that if an \fBotp\fR config is given, this value will always be set to \fBlegacy\fR.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help registry
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help npmrc
|
||||
.IP \(bu 4
|
||||
npm help owner
|
||||
.IP \(bu 4
|
||||
npm help whoami
|
||||
.IP \(bu 4
|
||||
npm help token
|
||||
.IP \(bu 4
|
||||
npm help profile
|
||||
.RE 0
|
||||
75
Dependencies/NodeJS/node_modules/npm/man/man1/npm-logout.1
generated
vendored
Normal file
75
Dependencies/NodeJS/node_modules/npm/man/man1/npm-logout.1
generated
vendored
Normal file
@ -0,0 +1,75 @@
|
||||
.TH "NPM-LOGOUT" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-logout\fR - Log out of the registry
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm logout
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Description"
|
||||
.P
|
||||
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.
|
||||
.P
|
||||
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 \fIonly\fR affect the current environment.
|
||||
.P
|
||||
If \fB--scope\fR is provided, this will find the credentials for the registry connected to that scope, if set.
|
||||
.SS "Configuration"
|
||||
.SS "\fBregistry\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "https://registry.npmjs.org/"
|
||||
.IP \(bu 4
|
||||
Type: URL
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The base URL of the npm registry.
|
||||
.SS "\fBscope\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: the scope of the current project, if any, or ""
|
||||
.IP \(bu 4
|
||||
Type: String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Associate an operation with a scope for a scoped registry.
|
||||
.P
|
||||
Useful when logging in to or out of a private registry:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
# log in, linking the scope to the custom registry
|
||||
npm login --scope=@mycorp --registry=https://registry.mycorp.com
|
||||
|
||||
# log out, removing the link and the auth token
|
||||
npm logout --scope=@mycorp
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
This will cause \fB@mycorp\fR to be mapped to the registry for future installation of packages specified according to the pattern \fB@mycorp/package\fR.
|
||||
.P
|
||||
This will also cause \fBnpm init\fR to create a scoped package.
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
# accept all defaults, and create a package named "@foo/whatever",
|
||||
# instead of just named "whatever"
|
||||
npm init --scope=@foo --yes
|
||||
.fi
|
||||
.RE
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help adduser
|
||||
.IP \(bu 4
|
||||
npm help registry
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help whoami
|
||||
.RE 0
|
||||
283
Dependencies/NodeJS/node_modules/npm/man/man1/npm-ls.1
generated
vendored
Normal file
283
Dependencies/NodeJS/node_modules/npm/man/man1/npm-ls.1
generated
vendored
Normal file
@ -0,0 +1,283 @@
|
||||
.TH "NPM-LS" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-ls\fR - List installed packages
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm ls <package-spec>
|
||||
|
||||
alias: list
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
This command will print to stdout all the versions of packages that are installed, as well as their dependencies when \fB--all\fR is specified, in a tree structure.
|
||||
.P
|
||||
Note: to get a "bottoms up" view of why a given package is included in the tree at all, use npm help explain.
|
||||
.P
|
||||
Positional arguments are \fBname@version-range\fR identifiers, which will limit the results to only the paths to the packages named. Note that nested packages will \fIalso\fR show the paths to the specified packages. For example, running \fBnpm ls promzard\fR in npm's source tree will show:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm@10.9.2 /path/to/npm
|
||||
└─┬ init-package-json@0.0.4
|
||||
└── promzard@0.1.5
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
It will print out extraneous, missing, and invalid packages.
|
||||
.P
|
||||
If a project specifies git urls for dependencies these are shown in parentheses after the \fBname@version\fR to make it easier for users to recognize potential forks of a project.
|
||||
.P
|
||||
The tree shown is the logical dependency tree, based on package dependencies, not the physical layout of your \fBnode_modules\fR folder.
|
||||
.P
|
||||
When run as \fBll\fR or \fBla\fR, it shows extended information by default.
|
||||
.SS "Note: Design Changes Pending"
|
||||
.P
|
||||
The \fBnpm ls\fR command's output and behavior made a \fIton\fR of sense when npm created a \fBnode_modules\fR folder that naively nested every dependency. In such a case, the logical dependency graph and physical tree of packages on disk would be roughly identical.
|
||||
.P
|
||||
With the advent of automatic install-time deduplication of dependencies in npm v3, the \fBls\fR output was modified to display the logical dependency graph as a tree structure, since this was more useful to most users. However, without using \fBnpm ls -l\fR, it became impossible to show \fIwhere\fR a package was actually installed much of the time!
|
||||
.P
|
||||
With the advent of automatic installation of \fBpeerDependencies\fR in npm v7, this gets even more curious, as \fBpeerDependencies\fR are logically "underneath" their dependents in the dependency graph, but are always physically at or above their location on disk.
|
||||
.P
|
||||
Also, in the years since npm got an \fBls\fR command (in version 0.0.2!), dependency graphs have gotten much larger as a general rule. Therefore, in order to avoid dumping an excessive amount of content to the terminal, \fBnpm
|
||||
ls\fR now only shows the \fItop\fR level dependencies, unless \fB--all\fR is provided.
|
||||
.P
|
||||
A thorough re-examination of the use cases, intention, behavior, and output of this command, is currently underway. Expect significant changes to at least the default human-readable \fBnpm ls\fR output in npm v8.
|
||||
.SS "Configuration"
|
||||
.SS "\fBall\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When running \fBnpm outdated\fR and \fBnpm ls\fR, setting \fB--all\fR will show all outdated or installed packages, rather than only those directly depended upon by the current project.
|
||||
.SS "\fBjson\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Whether or not to output JSON data, rather than the normal output.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
In \fBnpm pkg set\fR it enables parsing set values with JSON.parse() before saving them to your \fBpackage.json\fR.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Not supported by all npm commands.
|
||||
.SS "\fBlong\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Show extended information in \fBls\fR, \fBsearch\fR, and \fBhelp-search\fR.
|
||||
.SS "\fBparseable\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Output parseable results from commands that write to standard output. For \fBnpm search\fR, this will be tab-separated table format.
|
||||
.SS "\fBglobal\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Operates in "global" mode, so that packages are installed into the \fBprefix\fR folder instead of the current working directory. See npm help folders for more on the differences in behavior.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
packages are installed into the \fB{prefix}/lib/node_modules\fR folder, instead of the current working directory.
|
||||
.IP \(bu 4
|
||||
bin files are linked to \fB{prefix}/bin\fR
|
||||
.IP \(bu 4
|
||||
man pages are linked to \fB{prefix}/share/man\fR
|
||||
.RE 0
|
||||
|
||||
.SS "\fBdepth\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: \fBInfinity\fR if \fB--all\fR is set, otherwise \fB1\fR
|
||||
.IP \(bu 4
|
||||
Type: null or Number
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The depth to go when recursing packages for \fBnpm ls\fR.
|
||||
.P
|
||||
If not set, \fBnpm ls\fR will show only the immediate dependencies of the root project. If \fB--all\fR is set, then npm will show all dependencies by default.
|
||||
.SS "\fBomit\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production', otherwise empty.
|
||||
.IP \(bu 4
|
||||
Type: "dev", "optional", or "peer" (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Dependency types to omit from the installation tree on disk.
|
||||
.P
|
||||
Note that these dependencies \fIare\fR still resolved and added to the \fBpackage-lock.json\fR or \fBnpm-shrinkwrap.json\fR file. They are just not physically installed on disk.
|
||||
.P
|
||||
If a package type appears in both the \fB--include\fR and \fB--omit\fR lists, then it will be included.
|
||||
.P
|
||||
If the resulting omit list includes \fB'dev'\fR, then the \fBNODE_ENV\fR environment variable will be set to \fB'production'\fR for all lifecycle scripts.
|
||||
.SS "\fBinclude\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Option that allows for defining which types of dependencies to install.
|
||||
.P
|
||||
This is the inverse of \fB--omit=<type>\fR.
|
||||
.P
|
||||
Dependency types specified in \fB--include\fR will not be omitted, regardless of the order in which omit/include are specified on the command-line.
|
||||
.SS "\fBlink\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Used with \fBnpm ls\fR, limiting output to only those packages that are linked.
|
||||
.SS "\fBpackage-lock-only\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If set to true, the current operation will only use the \fBpackage-lock.json\fR, ignoring \fBnode_modules\fR.
|
||||
.P
|
||||
For \fBupdate\fR this means only the \fBpackage-lock.json\fR will be updated, instead of checking \fBnode_modules\fR and downloading dependencies.
|
||||
.P
|
||||
For \fBlist\fR this means the output will be based on the tree described by the \fBpackage-lock.json\fR, rather than the contents of \fBnode_modules\fR.
|
||||
.SS "\fBunicode\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false on windows, true on mac/unix systems with a unicode locale, as defined by the \fBLC_ALL\fR, \fBLC_CTYPE\fR, or \fBLANG\fR environment variables.
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set to true, npm uses unicode characters in the tree output. When false, it uses ascii characters instead of unicode glyphs.
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinclude-workspace-root\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
.P
|
||||
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinstall-links\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set file: protocol dependencies will be packed and installed as regular dependencies instead of creating a symlink. This option has no effect on workspaces.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help "package spec"
|
||||
.IP \(bu 4
|
||||
npm help explain
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help npmrc
|
||||
.IP \(bu 4
|
||||
npm help folders
|
||||
.IP \(bu 4
|
||||
npm help explain
|
||||
.IP \(bu 4
|
||||
npm help install
|
||||
.IP \(bu 4
|
||||
npm help link
|
||||
.IP \(bu 4
|
||||
npm help prune
|
||||
.IP \(bu 4
|
||||
npm help outdated
|
||||
.IP \(bu 4
|
||||
npm help update
|
||||
.RE 0
|
||||
125
Dependencies/NodeJS/node_modules/npm/man/man1/npm-org.1
generated
vendored
Normal file
125
Dependencies/NodeJS/node_modules/npm/man/man1/npm-org.1
generated
vendored
Normal file
@ -0,0 +1,125 @@
|
||||
.TH "NPM-ORG" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-org\fR - Manage orgs
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm org set orgname username \[lB]developer | admin | owner\[rB]
|
||||
npm org rm orgname username
|
||||
npm org ls orgname \[lB]<username>\[rB]
|
||||
|
||||
alias: ogr
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Example"
|
||||
.P
|
||||
Add a new developer to an org:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm org set my-org @mx-smith
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Add a new admin to an org (or change a developer to an admin):
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm org set my-org @mx-santos admin
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Remove a user from an org:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm org rm my-org mx-santos
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
List all users in an org:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm org ls my-org
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
List all users in JSON format:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm org ls my-org --json
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
See what role a user has in an org:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm org ls my-org @mx-santos
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
You can use the \fBnpm org\fR 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.
|
||||
.SS "Configuration"
|
||||
.SS "\fBregistry\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "https://registry.npmjs.org/"
|
||||
.IP \(bu 4
|
||||
Type: URL
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The base URL of the npm registry.
|
||||
.SS "\fBotp\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm access\fR.
|
||||
.P
|
||||
If not set, and a registry response fails with a challenge for a one-time password, npm will prompt on the command line for one.
|
||||
.SS "\fBjson\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Whether or not to output JSON data, rather than the normal output.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
In \fBnpm pkg set\fR it enables parsing set values with JSON.parse() before saving them to your \fBpackage.json\fR.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Not supported by all npm commands.
|
||||
.SS "\fBparseable\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Output parseable results from commands that write to standard output. For \fBnpm search\fR, this will be tab-separated table format.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help "using orgs"
|
||||
.IP \(bu 4
|
||||
\fBDocumentation on npm Orgs\fR \fI\(lahttps://docs.npmjs.com/orgs/\(ra\fR
|
||||
.RE 0
|
||||
182
Dependencies/NodeJS/node_modules/npm/man/man1/npm-outdated.1
generated
vendored
Normal file
182
Dependencies/NodeJS/node_modules/npm/man/man1/npm-outdated.1
generated
vendored
Normal file
@ -0,0 +1,182 @@
|
||||
.TH "NPM-OUTDATED" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-outdated\fR - Check for outdated packages
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm outdated \[lB]<package-spec> ...\[rB]
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
This command will check the registry to see if any (or, specific) installed packages are currently outdated.
|
||||
.P
|
||||
By default, only the direct dependencies of the root project and direct dependencies of your configured \fIworkspaces\fR are shown. Use \fB--all\fR to find all outdated meta-dependencies as well.
|
||||
.P
|
||||
In the output:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
\fBwanted\fR is the maximum version of the package that satisfies the semver range specified in \fBpackage.json\fR. If there's no available semver range (i.e. you're running \fBnpm outdated --global\fR, or the package isn't included in \fBpackage.json\fR), then \fBwanted\fR shows the currently-installed version.
|
||||
.IP \(bu 4
|
||||
\fBlatest\fR is the version of the package tagged as latest in the registry. Running \fBnpm publish\fR with no special configuration will publish the package with a dist-tag of \fBlatest\fR. 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 npm help dist-tag.
|
||||
.IP \(bu 4
|
||||
\fBlocation\fR is where in the physical tree the package is located.
|
||||
.IP \(bu 4
|
||||
\fBdepended by\fR shows which package depends on the displayed dependency
|
||||
.IP \(bu 4
|
||||
\fBpackage type\fR (when using \fB--long\fR / \fB-l\fR) tells you whether this package is a \fBdependency\fR or a dev/peer/optional dependency. Packages not included in \fBpackage.json\fR are always marked \fBdependencies\fR.
|
||||
.IP \(bu 4
|
||||
\fBhomepage\fR (when using \fB--long\fR / \fB-l\fR) is the \fBhomepage\fR value contained in the package's packument
|
||||
.IP \(bu 4
|
||||
Red means there's a newer version matching your semver requirements, so you should update now.
|
||||
.IP \(bu 4
|
||||
Yellow indicates that there's a newer version \fIabove\fR your semver requirements (usually new major, or new 0.x minor) so proceed with caution.
|
||||
.RE 0
|
||||
|
||||
.SS "An example"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm outdated
|
||||
Package Current Wanted Latest Location Depended by
|
||||
glob 5.0.15 5.0.15 6.0.1 node_modules/glob dependent-package-name
|
||||
nothingness 0.0.3 git git node_modules/nothingness dependent-package-name
|
||||
npm 3.5.1 3.5.2 3.5.1 node_modules/npm dependent-package-name
|
||||
local-dev 0.0.3 linked linked local-dev dependent-package-name
|
||||
once 1.3.2 1.3.3 1.3.3 node_modules/once dependent-package-name
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
With these \fBdependencies\fR:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
{
|
||||
"glob": "^5.0.15",
|
||||
"nothingness": "github:othiym23/nothingness#master",
|
||||
"npm": "^3.5.1",
|
||||
"once": "^1.3.1"
|
||||
}
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
A few things to note:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
\fBglob\fR requires \fB^5\fR, which prevents npm from installing \fBglob@6\fR, which is outside the semver range.
|
||||
.IP \(bu 4
|
||||
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 \fBnpm outdated\fR and \fBnpm update\fR 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.
|
||||
.IP \(bu 4
|
||||
\fBnpm@3.5.2\fR is marked as "wanted", but "latest" is \fBnpm@3.5.1\fR because npm uses dist-tags to manage its \fBlatest\fR and \fBnext\fR release channels. \fBnpm update\fR will install the \fInewest\fR version, but \fBnpm install npm\fR (with no semver range) will install whatever's tagged as \fBlatest\fR.
|
||||
.IP \(bu 4
|
||||
\fBonce\fR is just plain out of date. Reinstalling \fBnode_modules\fR from scratch or running \fBnpm update\fR will bring it up to spec.
|
||||
.RE 0
|
||||
|
||||
.SS "Configuration"
|
||||
.SS "\fBall\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When running \fBnpm outdated\fR and \fBnpm ls\fR, setting \fB--all\fR will show all outdated or installed packages, rather than only those directly depended upon by the current project.
|
||||
.SS "\fBjson\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Whether or not to output JSON data, rather than the normal output.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
In \fBnpm pkg set\fR it enables parsing set values with JSON.parse() before saving them to your \fBpackage.json\fR.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Not supported by all npm commands.
|
||||
.SS "\fBlong\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Show extended information in \fBls\fR, \fBsearch\fR, and \fBhelp-search\fR.
|
||||
.SS "\fBparseable\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Output parseable results from commands that write to standard output. For \fBnpm search\fR, this will be tab-separated table format.
|
||||
.SS "\fBglobal\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Operates in "global" mode, so that packages are installed into the \fBprefix\fR folder instead of the current working directory. See npm help folders for more on the differences in behavior.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
packages are installed into the \fB{prefix}/lib/node_modules\fR folder, instead of the current working directory.
|
||||
.IP \(bu 4
|
||||
bin files are linked to \fB{prefix}/bin\fR
|
||||
.IP \(bu 4
|
||||
man pages are linked to \fB{prefix}/share/man\fR
|
||||
.RE 0
|
||||
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help "package spec"
|
||||
.IP \(bu 4
|
||||
npm help update
|
||||
.IP \(bu 4
|
||||
npm help dist-tag
|
||||
.IP \(bu 4
|
||||
npm help registry
|
||||
.IP \(bu 4
|
||||
npm help folders
|
||||
.IP \(bu 4
|
||||
npm help workspaces
|
||||
.RE 0
|
||||
110
Dependencies/NodeJS/node_modules/npm/man/man1/npm-owner.1
generated
vendored
Normal file
110
Dependencies/NodeJS/node_modules/npm/man/man1/npm-owner.1
generated
vendored
Normal file
@ -0,0 +1,110 @@
|
||||
.TH "NPM-OWNER" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-owner\fR - Manage package owners
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm owner add <user> <package-spec>
|
||||
npm owner rm <user> <package-spec>
|
||||
npm owner ls <package-spec>
|
||||
|
||||
alias: author
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
Manage ownership of published packages.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
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.
|
||||
.IP \(bu 4
|
||||
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.
|
||||
.IP \(bu 4
|
||||
rm: Remove a user from the package owner list. This immediately revokes their privileges.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
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.
|
||||
.P
|
||||
If you have two-factor authentication enabled with \fBauth-and-writes\fR (see npm help npm-profile) then you'll need to go through a second factor flow when changing ownership or include an otp on the command line with \fB--otp\fR.
|
||||
.SS "Configuration"
|
||||
.SS "\fBregistry\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "https://registry.npmjs.org/"
|
||||
.IP \(bu 4
|
||||
Type: URL
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The base URL of the npm registry.
|
||||
.SS "\fBotp\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm access\fR.
|
||||
.P
|
||||
If not set, and a registry response fails with a challenge for a one-time password, npm will prompt on the command line for one.
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help "package spec"
|
||||
.IP \(bu 4
|
||||
npm help profile
|
||||
.IP \(bu 4
|
||||
npm help publish
|
||||
.IP \(bu 4
|
||||
npm help registry
|
||||
.IP \(bu 4
|
||||
npm help adduser
|
||||
.RE 0
|
||||
130
Dependencies/NodeJS/node_modules/npm/man/man1/npm-pack.1
generated
vendored
Normal file
130
Dependencies/NodeJS/node_modules/npm/man/man1/npm-pack.1
generated
vendored
Normal file
@ -0,0 +1,130 @@
|
||||
.TH "NPM-PACK" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-pack\fR - Create a tarball from a package
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm pack <package-spec>
|
||||
.fi
|
||||
.RE
|
||||
.SS "Configuration"
|
||||
.SS "\fBdry-run\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, \fBinstall\fR, \fBupdate\fR, \fBdedupe\fR, \fBuninstall\fR, as well as \fBpack\fR and \fBpublish\fR.
|
||||
.P
|
||||
Note: This is NOT honored by other network related commands, eg \fBdist-tags\fR, \fBowner\fR, etc.
|
||||
.SS "\fBjson\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Whether or not to output JSON data, rather than the normal output.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
In \fBnpm pkg set\fR it enables parsing set values with JSON.parse() before saving them to your \fBpackage.json\fR.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Not supported by all npm commands.
|
||||
.SS "\fBpack-destination\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "."
|
||||
.IP \(bu 4
|
||||
Type: String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Directory in which \fBnpm pack\fR will save tarballs.
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinclude-workspace-root\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
.P
|
||||
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "Description"
|
||||
.P
|
||||
For anything that's installable (that is, a package folder, tarball, tarball url, git url, name@tag, name@version, name, or scoped name), this command will fetch it to the cache, copy the tarball to the current working directory as \fB<name>-<version>.tgz\fR, and then write the filenames out to stdout.
|
||||
.P
|
||||
If the same package is specified multiple times, then the file will be overwritten the second time.
|
||||
.P
|
||||
If no arguments are supplied, then npm packs the current package folder.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help "package spec"
|
||||
.IP \(bu 4
|
||||
\fBnpm-packlist package\fR \fI\(lahttp://npm.im/npm-packlist\(ra\fR
|
||||
.IP \(bu 4
|
||||
npm help cache
|
||||
.IP \(bu 4
|
||||
npm help publish
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help npmrc
|
||||
.RE 0
|
||||
52
Dependencies/NodeJS/node_modules/npm/man/man1/npm-ping.1
generated
vendored
Normal file
52
Dependencies/NodeJS/node_modules/npm/man/man1/npm-ping.1
generated
vendored
Normal file
@ -0,0 +1,52 @@
|
||||
.TH "NPM-PING" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-ping\fR - Ping npm registry
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm ping
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Description"
|
||||
.P
|
||||
Ping the configured or given npm registry and verify authentication. If it works it will output something like:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm notice PING https://registry.npmjs.org/
|
||||
npm notice PONG 255ms
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
otherwise you will get an error:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm notice PING http://foo.com/
|
||||
npm ERR! code E404
|
||||
npm ERR! 404 Not Found - GET http://www.foo.com/-/ping?write=true
|
||||
.fi
|
||||
.RE
|
||||
.SS "Configuration"
|
||||
.SS "\fBregistry\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "https://registry.npmjs.org/"
|
||||
.IP \(bu 4
|
||||
Type: URL
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The base URL of the npm registry.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help doctor
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help npmrc
|
||||
.RE 0
|
||||
286
Dependencies/NodeJS/node_modules/npm/man/man1/npm-pkg.1
generated
vendored
Normal file
286
Dependencies/NodeJS/node_modules/npm/man/man1/npm-pkg.1
generated
vendored
Normal file
@ -0,0 +1,286 @@
|
||||
.TH "NPM-PKG" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-pkg\fR - Manages your package.json
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm pkg set <key>=<value> \[lB]<key>=<value> ...\[rB]
|
||||
npm pkg get \[lB]<key> \[lB]<key> ...\[rB]\[rB]
|
||||
npm pkg delete <key> \[lB]<key> ...\[rB]
|
||||
npm pkg set \[lB]<array>\[lB]<index>\[rB].<key>=<value> ...\[rB]
|
||||
npm pkg set \[lB]<array>\[lB]\[rB].<key>=<value> ...\[rB]
|
||||
npm pkg fix
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
A command that automates the management of \fBpackage.json\fR files. \fBnpm pkg\fR provide 3 different sub commands that allow you to modify or retrieve values for given object keys in your \fBpackage.json\fR.
|
||||
.P
|
||||
The syntax to retrieve and set fields is a dot separated representation of the nested object properties to be found within your \fBpackage.json\fR, it's the same notation used in npm help view to retrieve information from the registry manifest, below you can find more examples on how to use it.
|
||||
.P
|
||||
Returned values are always in \fBjson\fR format.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
\fBnpm pkg get <field>\fR
|
||||
.P
|
||||
Retrieves a value \fBkey\fR, defined in your \fBpackage.json\fR file.
|
||||
.P
|
||||
For example, in order to retrieve the name of the current package, you can run:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm pkg get name
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
It's also possible to retrieve multiple values at once:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm pkg get name version
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
You can view child fields by separating them with a period. To retrieve the value of a test \fBscript\fR value, you would run the following command:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm pkg get scripts.test
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
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 emails for a package, you would run:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm pkg get contributors.email
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
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 run:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm pkg get contributors\[lB]0\[rB].email
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
For complex fields you can also name a property in square brackets to specifically select a child field. This is especially helpful with the exports object:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm pkg get "exports\[lB].\[rB].require"
|
||||
.fi
|
||||
.RE
|
||||
.IP \(bu 4
|
||||
\fBnpm pkg set <field>=<value>\fR
|
||||
.P
|
||||
Sets a \fBvalue\fR in your \fBpackage.json\fR based on the \fBfield\fR value. When saving to your \fBpackage.json\fR file the same set of rules used during \fBnpm install\fR and other cli commands that touches the \fBpackage.json\fR file are used, making sure to respect the existing indentation and possibly applying some validation prior to saving values to the file.
|
||||
.P
|
||||
The same syntax used to retrieve values from your package can also be used to define new properties or overriding existing ones, below are some examples of how the dot separated syntax can be used to edit your \fBpackage.json\fR file.
|
||||
.P
|
||||
Defining a new bin named \fBmynewcommand\fR in your \fBpackage.json\fR that points to a file \fBcli.js\fR:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm pkg set bin.mynewcommand=cli.js
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Setting multiple fields at once is also possible:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm pkg set description='Awesome package' engines.node='>=10'
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
It's also possible to add to array values, for example to add a new contributor entry:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm pkg set contributors\[lB]0\[rB].name='Foo' contributors\[lB]0\[rB].email='foo@bar.ca'
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
You may also append items to the end of an array using the special empty bracket notation:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm pkg set contributors\[lB]\[rB].name='Foo' contributors\[lB]\[rB].name='Bar'
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
It's also possible to parse values as json prior to saving them to your \fBpackage.json\fR file, for example in order to set a \fB"private": true\fR property:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm pkg set private=true --json
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
It also enables saving values as numbers:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm pkg set tap.timeout=60 --json
|
||||
.fi
|
||||
.RE
|
||||
.IP \(bu 4
|
||||
\fBnpm pkg delete <key>\fR
|
||||
.P
|
||||
Deletes a \fBkey\fR from your \fBpackage.json\fR
|
||||
.P
|
||||
The same syntax used to set values from your package can also be used to remove existing ones. For example, in order to remove a script named build:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm pkg delete scripts.build
|
||||
.fi
|
||||
.RE
|
||||
.IP \(bu 4
|
||||
\fBnpm pkg fix\fR
|
||||
.P
|
||||
Auto corrects common errors in your \fBpackage.json\fR. npm already does this during \fBpublish\fR, which leads to subtle (mostly harmless) differences between the contents of your \fBpackage.json\fR file and the manifest that npm uses during installation.
|
||||
.RE 0
|
||||
|
||||
.SS "Workspaces support"
|
||||
.P
|
||||
You can set/get/delete items across your configured workspaces by using the \fB\fBworkspace\fR\fR \fI\(la/using-npm/config#workspace\(ra\fR or \fB\fBworkspaces\fR\fR \fI\(la/using-npm/config#workspaces\(ra\fR config options.
|
||||
.P
|
||||
For example, setting a \fBfunding\fR value across all configured workspaces of a project:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm pkg set funding=https://example.com --ws
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
When using \fBnpm pkg get\fR to retrieve info from your configured workspaces, the returned result will be in a json format in which top level keys are the names of each workspace, the values of these keys will be the result values returned from each of the configured workspaces, e.g:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm pkg get name version --ws
|
||||
{
|
||||
"a": {
|
||||
"name": "a",
|
||||
"version": "1.0.0"
|
||||
},
|
||||
"b": {
|
||||
"name": "b",
|
||||
"version": "1.0.0"
|
||||
}
|
||||
}
|
||||
.fi
|
||||
.RE
|
||||
.SS "Configuration"
|
||||
.SS "\fBforce\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Removes various protections against unfortunate side effects, common mistakes, unnecessary performance degradation, and malicious input.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Allow clobbering non-npm files in global installs.
|
||||
.IP \(bu 4
|
||||
Allow the \fBnpm version\fR command to work on an unclean git repository.
|
||||
.IP \(bu 4
|
||||
Allow deleting the cache folder with \fBnpm cache clean\fR.
|
||||
.IP \(bu 4
|
||||
Allow installing packages that have an \fBengines\fR declaration requiring a different version of npm.
|
||||
.IP \(bu 4
|
||||
Allow installing packages that have an \fBengines\fR declaration requiring a different version of \fBnode\fR, even if \fB--engine-strict\fR is enabled.
|
||||
.IP \(bu 4
|
||||
Allow \fBnpm audit fix\fR to install modules outside your stated dependency range (including SemVer-major changes).
|
||||
.IP \(bu 4
|
||||
Allow unpublishing all versions of a published package.
|
||||
.IP \(bu 4
|
||||
Allow conflicting peerDependencies to be installed in the root project.
|
||||
.IP \(bu 4
|
||||
Implicitly set \fB--yes\fR during \fBnpm init\fR.
|
||||
.IP \(bu 4
|
||||
Allow clobbering existing values in \fBnpm pkg\fR
|
||||
.IP \(bu 4
|
||||
Allow unpublishing of entire packages (not just a single version).
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If you don't have a clear idea of what you want to do, it is strongly recommended that you do not use this option!
|
||||
.SS "\fBjson\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Whether or not to output JSON data, rather than the normal output.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
In \fBnpm pkg set\fR it enables parsing set values with JSON.parse() before saving them to your \fBpackage.json\fR.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Not supported by all npm commands.
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SH "SEE ALSO"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help install
|
||||
.IP \(bu 4
|
||||
npm help init
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help workspaces
|
||||
.RE 0
|
||||
63
Dependencies/NodeJS/node_modules/npm/man/man1/npm-prefix.1
generated
vendored
Normal file
63
Dependencies/NodeJS/node_modules/npm/man/man1/npm-prefix.1
generated
vendored
Normal file
@ -0,0 +1,63 @@
|
||||
.TH "NPM-PREFIX" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-prefix\fR - Display prefix
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm prefix \[lB]-g\[rB]
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Description"
|
||||
.P
|
||||
Print the local prefix to standard output. This is the closest parent directory to contain a \fBpackage.json\fR file or \fBnode_modules\fR directory, unless \fB-g\fR is also specified.
|
||||
.P
|
||||
If \fB-g\fR is specified, this will be the value of the global prefix. See npm help config for more detail.
|
||||
.SS "Example"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm prefix
|
||||
/usr/local/projects/foo
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm prefix -g
|
||||
/usr/local
|
||||
.fi
|
||||
.RE
|
||||
.SS "Configuration"
|
||||
.SS "\fBglobal\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Operates in "global" mode, so that packages are installed into the \fBprefix\fR folder instead of the current working directory. See npm help folders for more on the differences in behavior.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
packages are installed into the \fB{prefix}/lib/node_modules\fR folder, instead of the current working directory.
|
||||
.IP \(bu 4
|
||||
bin files are linked to \fB{prefix}/bin\fR
|
||||
.IP \(bu 4
|
||||
man pages are linked to \fB{prefix}/share/man\fR
|
||||
.RE 0
|
||||
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help root
|
||||
.IP \(bu 4
|
||||
npm help folders
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help npmrc
|
||||
.RE 0
|
||||
126
Dependencies/NodeJS/node_modules/npm/man/man1/npm-profile.1
generated
vendored
Normal file
126
Dependencies/NodeJS/node_modules/npm/man/man1/npm-profile.1
generated
vendored
Normal file
@ -0,0 +1,126 @@
|
||||
.TH "NPM-PROFILE" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-profile\fR - Change settings on your registry profile
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm profile enable-2fa \[lB]auth-only|auth-and-writes\[rB]
|
||||
npm profile disable-2fa
|
||||
npm profile get \[lB]<key>\[rB]
|
||||
npm profile set <key> <value>
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Description"
|
||||
.P
|
||||
Change your profile information on the registry. Note that this command depends on the registry implementation, so third-party registries may not support this interface.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
\fBnpm profile get \[lB]<property>\[rB]\fR: Display all of the properties of your profile, or one or more specific properties. It looks like:
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
name: example
|
||||
email: e@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
|
||||
.fi
|
||||
.RE
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
\fBnpm profile set <property> <value>\fR: Set the value of a profile property. You can set the following properties this way: email, fullname, homepage, freenode, twitter, github
|
||||
.IP \(bu 4
|
||||
\fBnpm profile set password\fR: 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.
|
||||
.IP \(bu 4
|
||||
\fBnpm profile enable-2fa \[lB]auth-and-writes|auth-only\[rB]\fR: Enables two-factor authentication. Defaults to \fBauth-and-writes\fR mode. Modes are:
|
||||
.RS 4
|
||||
.IP \(bu 4
|
||||
\fBauth-only\fR: 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.
|
||||
.IP \(bu 4
|
||||
\fBauth-and-writes\fR: Requires an OTP at all the times \fBauth-only\fR does, and also requires one when publishing a module, setting the \fBlatest\fR dist-tag, or changing access via \fBnpm access\fR and \fBnpm owner\fR.
|
||||
.RE 0
|
||||
|
||||
.IP \(bu 4
|
||||
\fBnpm profile disable-2fa\fR: Disables two-factor authentication.
|
||||
.RE 0
|
||||
|
||||
.SS "Details"
|
||||
.P
|
||||
Some of these commands may not be available on non npmjs.com registries.
|
||||
.SS "Configuration"
|
||||
.SS "\fBregistry\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "https://registry.npmjs.org/"
|
||||
.IP \(bu 4
|
||||
Type: URL
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The base URL of the npm registry.
|
||||
.SS "\fBjson\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Whether or not to output JSON data, rather than the normal output.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
In \fBnpm pkg set\fR it enables parsing set values with JSON.parse() before saving them to your \fBpackage.json\fR.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Not supported by all npm commands.
|
||||
.SS "\fBparseable\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Output parseable results from commands that write to standard output. For \fBnpm search\fR, this will be tab-separated table format.
|
||||
.SS "\fBotp\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm access\fR.
|
||||
.P
|
||||
If not set, and a registry response fails with a challenge for a one-time password, npm will prompt on the command line for one.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help adduser
|
||||
.IP \(bu 4
|
||||
npm help registry
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help npmrc
|
||||
.IP \(bu 4
|
||||
npm help owner
|
||||
.IP \(bu 4
|
||||
npm help whoami
|
||||
.IP \(bu 4
|
||||
npm help token
|
||||
.RE 0
|
||||
184
Dependencies/NodeJS/node_modules/npm/man/man1/npm-prune.1
generated
vendored
Normal file
184
Dependencies/NodeJS/node_modules/npm/man/man1/npm-prune.1
generated
vendored
Normal file
@ -0,0 +1,184 @@
|
||||
.TH "NPM-PRUNE" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-prune\fR - Remove extraneous packages
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm prune \[lB]\[lB]<@scope>/\[rB]<pkg>...\[rB]
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
This command removes "extraneous" packages. If a package name is provided, then only packages matching one of the supplied names are removed.
|
||||
.P
|
||||
Extraneous packages are those present in the \fBnode_modules\fR folder that are not listed as any package's dependency list.
|
||||
.P
|
||||
If the \fB--omit=dev\fR flag is specified or the \fBNODE_ENV\fR environment variable is set to \fBproduction\fR, this command will remove the packages specified in your \fBdevDependencies\fR.
|
||||
.P
|
||||
If the \fB--dry-run\fR flag is used then no changes will actually be made.
|
||||
.P
|
||||
If the \fB--json\fR flag is used, then the changes \fBnpm prune\fR made (or would have made with \fB--dry-run\fR) are printed as a JSON object.
|
||||
.P
|
||||
In normal operation, extraneous modules are pruned automatically, so you'll only need this command with the \fB--production\fR flag. However, in the real world, operation is not always "normal". When crashes or mistakes happen, this command can help clean up any resulting garbage.
|
||||
.SS "Configuration"
|
||||
.SS "\fBomit\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production', otherwise empty.
|
||||
.IP \(bu 4
|
||||
Type: "dev", "optional", or "peer" (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Dependency types to omit from the installation tree on disk.
|
||||
.P
|
||||
Note that these dependencies \fIare\fR still resolved and added to the \fBpackage-lock.json\fR or \fBnpm-shrinkwrap.json\fR file. They are just not physically installed on disk.
|
||||
.P
|
||||
If a package type appears in both the \fB--include\fR and \fB--omit\fR lists, then it will be included.
|
||||
.P
|
||||
If the resulting omit list includes \fB'dev'\fR, then the \fBNODE_ENV\fR environment variable will be set to \fB'production'\fR for all lifecycle scripts.
|
||||
.SS "\fBinclude\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Option that allows for defining which types of dependencies to install.
|
||||
.P
|
||||
This is the inverse of \fB--omit=<type>\fR.
|
||||
.P
|
||||
Dependency types specified in \fB--include\fR will not be omitted, regardless of the order in which omit/include are specified on the command-line.
|
||||
.SS "\fBdry-run\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, \fBinstall\fR, \fBupdate\fR, \fBdedupe\fR, \fBuninstall\fR, as well as \fBpack\fR and \fBpublish\fR.
|
||||
.P
|
||||
Note: This is NOT honored by other network related commands, eg \fBdist-tags\fR, \fBowner\fR, etc.
|
||||
.SS "\fBjson\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Whether or not to output JSON data, rather than the normal output.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
In \fBnpm pkg set\fR it enables parsing set values with JSON.parse() before saving them to your \fBpackage.json\fR.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Not supported by all npm commands.
|
||||
.SS "\fBforeground-scripts\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: \fBfalse\fR unless when using \fBnpm pack\fR or \fBnpm publish\fR where it defaults to \fBtrue\fR
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Run all build scripts (ie, \fBpreinstall\fR, \fBinstall\fR, and \fBpostinstall\fR) scripts for installed packages in the foreground process, sharing standard input, output, and error with the main npm process.
|
||||
.P
|
||||
Note that this will generally make installs run slower, and be much noisier, but can be useful for debugging.
|
||||
.SS "\fBignore-scripts\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If true, npm does not run scripts specified in package.json files.
|
||||
.P
|
||||
Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run-script\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts.
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinclude-workspace-root\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
.P
|
||||
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinstall-links\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set file: protocol dependencies will be packed and installed as regular dependencies instead of creating a symlink. This option has no effect on workspaces.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help uninstall
|
||||
.IP \(bu 4
|
||||
npm help folders
|
||||
.IP \(bu 4
|
||||
npm help ls
|
||||
.RE 0
|
||||
224
Dependencies/NodeJS/node_modules/npm/man/man1/npm-publish.1
generated
vendored
Normal file
224
Dependencies/NodeJS/node_modules/npm/man/man1/npm-publish.1
generated
vendored
Normal file
@ -0,0 +1,224 @@
|
||||
.TH "NPM-PUBLISH" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-publish\fR - Publish a package
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm publish <package-spec>
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
Publishes a package to the registry so that it can be installed by name.
|
||||
.P
|
||||
By default npm will publish to the public registry. This can be overridden by specifying a different default registry or using a npm help scope in the name, combined with a scope-configured registry (see \fB\fBpackage.json\fR\fR \fI\(la/configuring-npm/package-json\(ra\fR).
|
||||
.P
|
||||
A \fBpackage\fR is interpreted the same way as other commands (like \fBnpm install\fR) and can be:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
a) a folder containing a program described by a \fB\fBpackage.json\fR\fR \fI\(la/configuring-npm/package-json\(ra\fR file
|
||||
.IP \(bu 4
|
||||
b) a gzipped tarball containing (a)
|
||||
.IP \(bu 4
|
||||
c) a url that resolves to (b)
|
||||
.IP \(bu 4
|
||||
d) a \fB<name>@<version>\fR that is published on the registry (see npm help registry) with (c)
|
||||
.IP \(bu 4
|
||||
e) a \fB<name>@<tag>\fR (see npm help dist-tag) that points to (d)
|
||||
.IP \(bu 4
|
||||
f) a \fB<name>\fR that has a "latest" tag satisfying (e)
|
||||
.IP \(bu 4
|
||||
g) a \fB<git remote url>\fR that resolves to (a)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The publish will fail if the package name and version combination already exists in the specified registry.
|
||||
.P
|
||||
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 help unpublish.
|
||||
.P
|
||||
As of \fBnpm@5\fR, 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.
|
||||
.P
|
||||
Similar to \fB--dry-run\fR see npm help pack, which figures out the files to be included and packs them into a tarball to be uploaded to the registry.
|
||||
.SS "Files included in package"
|
||||
.P
|
||||
To see what will be included in your package, run \fBnpm pack --dry-run\fR. All files are included by default, with the following exceptions:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Certain files that are relevant to package installation and distribution are always included. For example, \fBpackage.json\fR, \fBREADME.md\fR, \fBLICENSE\fR, and so on.
|
||||
.IP \(bu 4
|
||||
If there is a "files" list in \fB\fBpackage.json\fR\fR \fI\(la/configuring-npm/package-json\(ra\fR, then only the files specified will be included. (If directories are specified, then they will be walked recursively and their contents included, subject to the same ignore rules.)
|
||||
.IP \(bu 4
|
||||
If there is a \fB.gitignore\fR or \fB.npmignore\fR file, then ignored files in that and all child directories will be excluded from the package. If \fIboth\fR files exist, then the \fB.gitignore\fR is ignored, and only the \fB.npmignore\fR is used.
|
||||
.P
|
||||
\fB.npmignore\fR files follow the \fBsame pattern rules\fR \fI\(lahttps://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository#_ignoring\(ra\fR as \fB.gitignore\fR files
|
||||
.IP \(bu 4
|
||||
If the file matches certain patterns, then it will \fInever\fR be included, unless explicitly added to the \fB"files"\fR list in \fBpackage.json\fR, or un-ignored with a \fB!\fR rule in a \fB.npmignore\fR or \fB.gitignore\fR file.
|
||||
.IP \(bu 4
|
||||
Symbolic links are never included in npm packages.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
See npm help developers for full details on what's included in the published package, as well as details on how the package is built.
|
||||
.SS "Configuration"
|
||||
.SS "\fBtag\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "latest"
|
||||
.IP \(bu 4
|
||||
Type: String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If you ask npm to install a package and don't tell it a specific version, then it will install the specified tag.
|
||||
.P
|
||||
It is the tag added to the package@version specified in the \fBnpm dist-tag
|
||||
add\fR command, if no explicit tag is given.
|
||||
.P
|
||||
When used by the \fBnpm diff\fR command, this is the tag used to fetch the tarball that will be compared with the local files by default.
|
||||
.P
|
||||
If used in the \fBnpm publish\fR command, this is the tag that will be added to the package submitted to the registry.
|
||||
.SS "\fBaccess\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: 'public' for new packages, existing packages it will not change the current level
|
||||
.IP \(bu 4
|
||||
Type: null, "restricted", or "public"
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If you do not want your scoped package to be publicly viewable (and installable) set \fB--access=restricted\fR.
|
||||
.P
|
||||
Unscoped packages can not be set to \fBrestricted\fR.
|
||||
.P
|
||||
Note: This defaults to not changing the current access level for existing packages. Specifying a value of \fBrestricted\fR or \fBpublic\fR during publish will change the access for an existing package the same way that \fBnpm access set
|
||||
status\fR would.
|
||||
.SS "\fBdry-run\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, \fBinstall\fR, \fBupdate\fR, \fBdedupe\fR, \fBuninstall\fR, as well as \fBpack\fR and \fBpublish\fR.
|
||||
.P
|
||||
Note: This is NOT honored by other network related commands, eg \fBdist-tags\fR, \fBowner\fR, etc.
|
||||
.SS "\fBotp\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm access\fR.
|
||||
.P
|
||||
If not set, and a registry response fails with a challenge for a one-time password, npm will prompt on the command line for one.
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinclude-workspace-root\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
.P
|
||||
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBprovenance\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When publishing from a supported cloud CI/CD system, the package will be publicly linked to where it was built and published from.
|
||||
.P
|
||||
This config can not be used with: \fBprovenance-file\fR
|
||||
.SS "\fBprovenance-file\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: Path
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When publishing, the provenance bundle at the given path will be used.
|
||||
.P
|
||||
This config can not be used with: \fBprovenance\fR
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help "package spec"
|
||||
.IP \(bu 4
|
||||
\fBnpm-packlist package\fR \fI\(lahttp://npm.im/npm-packlist\(ra\fR
|
||||
.IP \(bu 4
|
||||
npm help registry
|
||||
.IP \(bu 4
|
||||
npm help scope
|
||||
.IP \(bu 4
|
||||
npm help adduser
|
||||
.IP \(bu 4
|
||||
npm help owner
|
||||
.IP \(bu 4
|
||||
npm help deprecate
|
||||
.IP \(bu 4
|
||||
npm help dist-tag
|
||||
.IP \(bu 4
|
||||
npm help pack
|
||||
.IP \(bu 4
|
||||
npm help profile
|
||||
.RE 0
|
||||
281
Dependencies/NodeJS/node_modules/npm/man/man1/npm-query.1
generated
vendored
Normal file
281
Dependencies/NodeJS/node_modules/npm/man/man1/npm-query.1
generated
vendored
Normal file
@ -0,0 +1,281 @@
|
||||
.TH "NPM-QUERY" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-query\fR - Dependency selector query
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm query <selector>
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
The \fBnpm query\fR command allows for usage of css selectors in order to retrieve an array of dependency objects.
|
||||
.SS "Piping npm query to other commands"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
# find all dependencies with postinstall scripts & uninstall them
|
||||
npm query ":attr(scripts, \[lB]postinstall\[rB])" | jq 'map(.name)|join("\[rs]n")' -r | xargs -I {} npm uninstall {}
|
||||
|
||||
# find all git dependencies & explain who requires them
|
||||
npm query ":type(git)" | jq 'map(.name)' | xargs -I {} npm why {}
|
||||
.fi
|
||||
.RE
|
||||
.SS "Extended Use Cases & Queries"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
// all deps
|
||||
*
|
||||
|
||||
// all direct deps
|
||||
:root > *
|
||||
|
||||
// direct production deps
|
||||
:root > .prod
|
||||
|
||||
// direct development deps
|
||||
:root > .dev
|
||||
|
||||
// any peer dep of a direct deps
|
||||
:root > * > .peer
|
||||
|
||||
// any workspace dep
|
||||
.workspace
|
||||
|
||||
// all workspaces that depend on another workspace
|
||||
.workspace > .workspace
|
||||
|
||||
// all workspaces that have peer deps
|
||||
.workspace:has(.peer)
|
||||
|
||||
// any dep named "lodash"
|
||||
// equivalent to \[lB]name="lodash"\[rB]
|
||||
#lodash
|
||||
|
||||
// any deps named "lodash" & within semver range ^"1.2.3"
|
||||
#lodash@^1.2.3
|
||||
// equivalent to...
|
||||
\[lB]name="lodash"\[rB]:semver(^1.2.3)
|
||||
|
||||
// get the hoisted node for a given semver range
|
||||
#lodash@^1.2.3:not(:deduped)
|
||||
|
||||
// querying deps with a specific version
|
||||
#lodash@2.1.5
|
||||
// equivalent to...
|
||||
\[lB]name="lodash"\[rB]\[lB]version="2.1.5"\[rB]
|
||||
|
||||
// has any deps
|
||||
:has(*)
|
||||
|
||||
// deps with no other deps (ie. "leaf" nodes)
|
||||
:empty
|
||||
|
||||
// manually querying git dependencies
|
||||
\[lB]repository^=github:\[rB],
|
||||
\[lB]repository^=git:\[rB],
|
||||
\[lB]repository^=https://github.com\[rB],
|
||||
\[lB]repository^=http://github.com\[rB],
|
||||
\[lB]repository^=https://github.com\[rB],
|
||||
\[lB]repository^=+git:...\[rB]
|
||||
|
||||
// querying for all git dependencies
|
||||
:type(git)
|
||||
|
||||
// get production dependencies that aren't also dev deps
|
||||
.prod:not(.dev)
|
||||
|
||||
// get dependencies with specific licenses
|
||||
\[lB]license=MIT\[rB], \[lB]license=ISC\[rB]
|
||||
|
||||
// find all packages that have @ruyadorno as a contributor
|
||||
:attr(contributors, \[lB]email=ruyadorno@github.com\[rB])
|
||||
.fi
|
||||
.RE
|
||||
.SS "Example Response Output"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
an array of dependency objects is returned which can contain multiple copies of the same package which may or may not have been linked or deduped
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
\[lB]
|
||||
{
|
||||
"name": "",
|
||||
"version": "",
|
||||
"description": "",
|
||||
"homepage": "",
|
||||
"bugs": {},
|
||||
"author": {},
|
||||
"license": {},
|
||||
"funding": {},
|
||||
"files": \[lB]\[rB],
|
||||
"main": "",
|
||||
"browser": "",
|
||||
"bin": {},
|
||||
"man": \[lB]\[rB],
|
||||
"directories": {},
|
||||
"repository": {},
|
||||
"scripts": {},
|
||||
"config": {},
|
||||
"dependencies": {},
|
||||
"devDependencies": {},
|
||||
"optionalDependencies": {},
|
||||
"bundledDependencies": {},
|
||||
"peerDependencies": {},
|
||||
"peerDependenciesMeta": {},
|
||||
"engines": {},
|
||||
"os": \[lB]\[rB],
|
||||
"cpu": \[lB]\[rB],
|
||||
"workspaces": {},
|
||||
"keywords": \[lB]\[rB],
|
||||
...
|
||||
},
|
||||
...
|
||||
.fi
|
||||
.RE
|
||||
.SS "Expecting a certain number of results"
|
||||
.P
|
||||
One common use of \fBnpm query\fR is to make sure there is only one version of a certain dependency in your tree. This is especially common for ecosystems like that rely on \fBtypescript\fR where having state split across two different but identically-named packages causes bugs. You can use the \fB--expect-results\fR or \fB--expect-result-count\fR in your setup to ensure that npm will exit with an exit code if your tree doesn't look like you want it to.
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm query '#react' --expect-result-count=1
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Perhaps you want to quickly check if there are any production dependencies that could be updated:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm query ':root>:outdated(in-range).prod' --no-expect-results
|
||||
.fi
|
||||
.RE
|
||||
.SS "Package lock only mode"
|
||||
.P
|
||||
If package-lock-only is enabled, only the information in the package lock (or shrinkwrap) is loaded. This means that information from the package.json files of your dependencies will not be included in the result set (e.g. description, homepage, engines).
|
||||
.SS "Configuration"
|
||||
.SS "\fBglobal\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Operates in "global" mode, so that packages are installed into the \fBprefix\fR folder instead of the current working directory. See npm help folders for more on the differences in behavior.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
packages are installed into the \fB{prefix}/lib/node_modules\fR folder, instead of the current working directory.
|
||||
.IP \(bu 4
|
||||
bin files are linked to \fB{prefix}/bin\fR
|
||||
.IP \(bu 4
|
||||
man pages are linked to \fB{prefix}/share/man\fR
|
||||
.RE 0
|
||||
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinclude-workspace-root\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
.P
|
||||
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBpackage-lock-only\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If set to true, the current operation will only use the \fBpackage-lock.json\fR, ignoring \fBnode_modules\fR.
|
||||
.P
|
||||
For \fBupdate\fR this means only the \fBpackage-lock.json\fR will be updated, instead of checking \fBnode_modules\fR and downloading dependencies.
|
||||
.P
|
||||
For \fBlist\fR this means the output will be based on the tree described by the \fBpackage-lock.json\fR, rather than the contents of \fBnode_modules\fR.
|
||||
.SS "\fBexpect-results\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Tells npm whether or not to expect results from the command. Can be either true (expect some results) or false (expect no results).
|
||||
.P
|
||||
This config can not be used with: \fBexpect-result-count\fR
|
||||
.SS "\fBexpect-result-count\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Number
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Tells to expect a specific number of results from the command.
|
||||
.P
|
||||
This config can not be used with: \fBexpect-results\fR
|
||||
.SH "SEE ALSO"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help "dependency selectors"
|
||||
.RE 0
|
||||
178
Dependencies/NodeJS/node_modules/npm/man/man1/npm-rebuild.1
generated
vendored
Normal file
178
Dependencies/NodeJS/node_modules/npm/man/man1/npm-rebuild.1
generated
vendored
Normal file
@ -0,0 +1,178 @@
|
||||
.TH "NPM-REBUILD" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-rebuild\fR - Rebuild a package
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm rebuild \[lB]<package-spec>\[rB] ...\[rB]
|
||||
|
||||
alias: rb
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
This command does the following:
|
||||
.RS 0
|
||||
.IP 1. 4
|
||||
Execute lifecycle scripts (\fBpreinstall\fR, \fBinstall\fR, \fBpostinstall\fR, \fBprepare\fR)
|
||||
.IP 2. 4
|
||||
Links bins depending on whether bin links are enabled
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This command is particularly useful in scenarios including but not limited to:
|
||||
.RS 0
|
||||
.IP 1. 4
|
||||
Installing a new version of \fBnode.js\fR, where you need to recompile all your C++ add-ons with the updated binary.
|
||||
.IP 2. 4
|
||||
Installing with \fB--ignore-scripts\fR and \fB--no-bin-links\fR, to explicitly choose which packages to build and/or link bins.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If one or more package specs are provided, then only packages with a name and version matching one of the specifiers will be rebuilt.
|
||||
.P
|
||||
Usually, you should not need to run \fBnpm rebuild\fR as it is already done for you as part of npm install (unless you suppressed these steps with \fB--ignore-scripts\fR or \fB--no-bin-links\fR).
|
||||
.P
|
||||
If there is a \fBbinding.gyp\fR file in the root of your package, then npm will use a default install hook:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
"scripts": {
|
||||
"install": "node-gyp rebuild"
|
||||
}
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
This default behavior is suppressed if the \fBpackage.json\fR has its own \fBinstall\fR or \fBpreinstall\fR scripts. It is also suppressed if the package specifies \fB"gypfile": false\fR
|
||||
.SS "Configuration"
|
||||
.SS "\fBglobal\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Operates in "global" mode, so that packages are installed into the \fBprefix\fR folder instead of the current working directory. See npm help folders for more on the differences in behavior.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
packages are installed into the \fB{prefix}/lib/node_modules\fR folder, instead of the current working directory.
|
||||
.IP \(bu 4
|
||||
bin files are linked to \fB{prefix}/bin\fR
|
||||
.IP \(bu 4
|
||||
man pages are linked to \fB{prefix}/share/man\fR
|
||||
.RE 0
|
||||
|
||||
.SS "\fBbin-links\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Tells npm to create symlinks (or \fB.cmd\fR shims on Windows) for package executables.
|
||||
.P
|
||||
Set to false to have it not do this. This can be used to work around the fact that some file systems don't support symlinks, even on ostensibly Unix systems.
|
||||
.SS "\fBforeground-scripts\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: \fBfalse\fR unless when using \fBnpm pack\fR or \fBnpm publish\fR where it defaults to \fBtrue\fR
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Run all build scripts (ie, \fBpreinstall\fR, \fBinstall\fR, and \fBpostinstall\fR) scripts for installed packages in the foreground process, sharing standard input, output, and error with the main npm process.
|
||||
.P
|
||||
Note that this will generally make installs run slower, and be much noisier, but can be useful for debugging.
|
||||
.SS "\fBignore-scripts\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If true, npm does not run scripts specified in package.json files.
|
||||
.P
|
||||
Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run-script\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts.
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinclude-workspace-root\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
.P
|
||||
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinstall-links\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set file: protocol dependencies will be packed and installed as regular dependencies instead of creating a symlink. This option has no effect on workspaces.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help "package spec"
|
||||
.IP \(bu 4
|
||||
npm help install
|
||||
.RE 0
|
||||
103
Dependencies/NodeJS/node_modules/npm/man/man1/npm-repo.1
generated
vendored
Normal file
103
Dependencies/NodeJS/node_modules/npm/man/man1/npm-repo.1
generated
vendored
Normal file
@ -0,0 +1,103 @@
|
||||
.TH "NPM-REPO" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-repo\fR - Open package repository page in the browser
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm repo \[lB]<pkgname> \[lB]<pkgname> ...\[rB]\[rB]
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
This command tries to guess at the likely location of a package's repository URL, and then tries to open it using the \fB\fB--browser\fR config\fR \fI\(la/using-npm/config#browser\(ra\fR param. If no package name is provided, it will search for a \fBpackage.json\fR in the current folder and use the \fBrepository\fR property.
|
||||
.SS "Configuration"
|
||||
.SS "\fBbrowser\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: OS X: \fB"open"\fR, Windows: \fB"start"\fR, Others: \fB"xdg-open"\fR
|
||||
.IP \(bu 4
|
||||
Type: null, Boolean, or String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The browser that is called by npm commands to open websites.
|
||||
.P
|
||||
Set to \fBfalse\fR to suppress browser behavior and instead print urls to terminal.
|
||||
.P
|
||||
Set to \fBtrue\fR to use default system URL opener.
|
||||
.SS "\fBregistry\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "https://registry.npmjs.org/"
|
||||
.IP \(bu 4
|
||||
Type: URL
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The base URL of the npm registry.
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinclude-workspace-root\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
.P
|
||||
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help docs
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.RE 0
|
||||
85
Dependencies/NodeJS/node_modules/npm/man/man1/npm-restart.1
generated
vendored
Normal file
85
Dependencies/NodeJS/node_modules/npm/man/man1/npm-restart.1
generated
vendored
Normal file
@ -0,0 +1,85 @@
|
||||
.TH "NPM-RESTART" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-restart\fR - Restart a package
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm restart \[lB]-- <args>\[rB]
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
This restarts a project. It is equivalent to running \fBnpm run-script
|
||||
restart\fR.
|
||||
.P
|
||||
If the current project has a \fB"restart"\fR script specified in \fBpackage.json\fR, then the following scripts will be run:
|
||||
.RS 0
|
||||
.IP 1. 4
|
||||
prerestart
|
||||
.IP 2. 4
|
||||
restart
|
||||
.IP 3. 4
|
||||
postrestart
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If it does \fInot\fR have a \fB"restart"\fR script specified, but it does have \fBstop\fR and/or \fBstart\fR scripts, then the following scripts will be run:
|
||||
.RS 0
|
||||
.IP 1. 4
|
||||
prerestart
|
||||
.IP 2. 4
|
||||
prestop
|
||||
.IP 3. 4
|
||||
stop
|
||||
.IP 4. 4
|
||||
poststop
|
||||
.IP 5. 4
|
||||
prestart
|
||||
.IP 6. 4
|
||||
start
|
||||
.IP 7. 4
|
||||
poststart
|
||||
.IP 8. 4
|
||||
postrestart
|
||||
.RE 0
|
||||
|
||||
.SS "Configuration"
|
||||
.SS "\fBignore-scripts\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If true, npm does not run scripts specified in package.json files.
|
||||
.P
|
||||
Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run-script\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts.
|
||||
.SS "\fBscript-shell\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows
|
||||
.IP \(bu 4
|
||||
Type: null or String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The shell to use for scripts run with the \fBnpm exec\fR, \fBnpm run\fR and \fBnpm
|
||||
init <package-spec>\fR commands.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help run-script
|
||||
.IP \(bu 4
|
||||
npm help scripts
|
||||
.IP \(bu 4
|
||||
npm help test
|
||||
.IP \(bu 4
|
||||
npm help start
|
||||
.IP \(bu 4
|
||||
npm help stop
|
||||
.IP \(bu 4
|
||||
npm help restart
|
||||
.RE 0
|
||||
56
Dependencies/NodeJS/node_modules/npm/man/man1/npm-root.1
generated
vendored
Normal file
56
Dependencies/NodeJS/node_modules/npm/man/man1/npm-root.1
generated
vendored
Normal file
@ -0,0 +1,56 @@
|
||||
.TH "NPM-ROOT" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-root\fR - Display npm root
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm root
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Description"
|
||||
.P
|
||||
Print the effective \fBnode_modules\fR folder to standard out.
|
||||
.P
|
||||
Useful for using npm in shell scripts that do things with the \fBnode_modules\fR folder. For example:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
#!/bin/bash
|
||||
global_node_modules="$(npm root --global)"
|
||||
echo "Global packages installed in: ${global_node_modules}"
|
||||
.fi
|
||||
.RE
|
||||
.SS "Configuration"
|
||||
.SS "\fBglobal\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Operates in "global" mode, so that packages are installed into the \fBprefix\fR folder instead of the current working directory. See npm help folders for more on the differences in behavior.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
packages are installed into the \fB{prefix}/lib/node_modules\fR folder, instead of the current working directory.
|
||||
.IP \(bu 4
|
||||
bin files are linked to \fB{prefix}/bin\fR
|
||||
.IP \(bu 4
|
||||
man pages are linked to \fB{prefix}/share/man\fR
|
||||
.RE 0
|
||||
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help prefix
|
||||
.IP \(bu 4
|
||||
npm help folders
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help npmrc
|
||||
.RE 0
|
||||
234
Dependencies/NodeJS/node_modules/npm/man/man1/npm-run-script.1
generated
vendored
Normal file
234
Dependencies/NodeJS/node_modules/npm/man/man1/npm-run-script.1
generated
vendored
Normal file
@ -0,0 +1,234 @@
|
||||
.TH "NPM-RUN-SCRIPT" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-run-script\fR - Run arbitrary package scripts
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm run-script <command> \[lB]-- <args>\[rB]
|
||||
|
||||
aliases: run, rum, urn
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
This runs an arbitrary command from a package's \fB"scripts"\fR object. If no \fB"command"\fR is provided, it will list the available scripts.
|
||||
.P
|
||||
\fBrun\[lB]-script\[rB]\fR 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.
|
||||
.P
|
||||
Any positional arguments are passed to the specified script. Use \fB--\fR to pass \fB-\fR-prefixed flags and options which would otherwise be parsed by npm.
|
||||
.P
|
||||
For example:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm run test -- --grep="pattern"
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
The arguments will only be passed to the script specified after \fBnpm run\fR and not to any \fBpre\fR or \fBpost\fR script.
|
||||
.P
|
||||
The \fBenv\fR 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.
|
||||
.P
|
||||
In addition to the shell's pre-existing \fBPATH\fR, \fBnpm run\fR adds \fBnode_modules/.bin\fR to the \fBPATH\fR provided to scripts. Any binaries provided by locally-installed dependencies can be used without the \fBnode_modules/.bin\fR prefix. For example, if there is a \fBdevDependency\fR on \fBtap\fR in your package, you should write:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
"scripts": {"test": "tap test/*.js"}
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
instead of
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
"scripts": {"test": "node_modules/.bin/tap test/*.js"}
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
The actual shell your script is run within is platform dependent. By default, on Unix-like systems it is the \fB/bin/sh\fR command, on Windows it is \fBcmd.exe\fR. The actual shell referred to by \fB/bin/sh\fR also depends on the system. You can customize the shell with the \fB\fBscript-shell\fR config\fR \fI\(la/using-npm/config#script-shell\(ra\fR.
|
||||
.P
|
||||
Scripts are run from the root of the package folder, regardless of what the current working directory is when \fBnpm run\fR is called. If you want your script to use different behavior based on what subdirectory you're in, you can use the \fBINIT_CWD\fR environment variable, which holds the full path you were in when you ran \fBnpm run\fR.
|
||||
.P
|
||||
\fBnpm run\fR sets the \fBNODE\fR environment variable to the \fBnode\fR executable with which \fBnpm\fR is executed.
|
||||
.P
|
||||
If you try to run a script without having a \fBnode_modules\fR directory and it fails, you will be given a warning to run \fBnpm install\fR, just in case you've forgotten.
|
||||
.SS "Workspaces support"
|
||||
.P
|
||||
You may use the \fB\fBworkspace\fR\fR \fI\(la/using-npm/config#workspace\(ra\fR or \fB\fBworkspaces\fR\fR \fI\(la/using-npm/config#workspaces\(ra\fR configs in order to run an arbitrary command from a package's \fB"scripts"\fR object in the context of the specified workspaces. If no \fB"command"\fR is provided, it will list the available scripts for each of these configured workspaces.
|
||||
.P
|
||||
Given a project with configured workspaces, e.g:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
.
|
||||
+-- package.json
|
||||
`-- packages
|
||||
+-- a
|
||||
| `-- package.json
|
||||
+-- b
|
||||
| `-- package.json
|
||||
`-- c
|
||||
`-- package.json
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Assuming the workspace configuration is properly set up at the root level \fBpackage.json\fR file. e.g:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
{
|
||||
"workspaces": \[lB] "./packages/*" \[rB]
|
||||
}
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
And that each of the configured workspaces has a configured \fBtest\fR script, we can run tests in all of them using the \fB\fBworkspaces\fR config\fR \fI\(la/using-npm/config#workspaces\(ra\fR:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm test --workspaces
|
||||
.fi
|
||||
.RE
|
||||
.SS "Filtering workspaces"
|
||||
.P
|
||||
It's also possible to run a script in a single workspace using the \fBworkspace\fR config along with a name or directory path:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm test --workspace=a
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
The \fBworkspace\fR config can also be specified multiple times in order to run a specific script in the context of multiple workspaces. When defining values for the \fBworkspace\fR config in the command line, it also possible to use \fB-w\fR as a shorthand, e.g:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm test -w a -w b
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
This last command will run \fBtest\fR in both \fB./packages/a\fR and \fB./packages/b\fR packages.
|
||||
.SS "Configuration"
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinclude-workspace-root\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
.P
|
||||
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBif-present\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If true, npm will not exit with an error code when \fBrun-script\fR is invoked for a script that isn't defined in the \fBscripts\fR section of \fBpackage.json\fR. This option can be used when it's desirable to optionally run a script when it's present and fail if the script fails. This is useful, for example, when running scripts that may only apply for some builds in an otherwise generic CI setup.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBignore-scripts\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If true, npm does not run scripts specified in package.json files.
|
||||
.P
|
||||
Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run-script\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts.
|
||||
.SS "\fBforeground-scripts\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: \fBfalse\fR unless when using \fBnpm pack\fR or \fBnpm publish\fR where it defaults to \fBtrue\fR
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Run all build scripts (ie, \fBpreinstall\fR, \fBinstall\fR, and \fBpostinstall\fR) scripts for installed packages in the foreground process, sharing standard input, output, and error with the main npm process.
|
||||
.P
|
||||
Note that this will generally make installs run slower, and be much noisier, but can be useful for debugging.
|
||||
.SS "\fBscript-shell\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows
|
||||
.IP \(bu 4
|
||||
Type: null or String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The shell to use for scripts run with the \fBnpm exec\fR, \fBnpm run\fR and \fBnpm
|
||||
init <package-spec>\fR commands.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help scripts
|
||||
.IP \(bu 4
|
||||
npm help test
|
||||
.IP \(bu 4
|
||||
npm help start
|
||||
.IP \(bu 4
|
||||
npm help restart
|
||||
.IP \(bu 4
|
||||
npm help stop
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help workspaces
|
||||
.RE 0
|
||||
314
Dependencies/NodeJS/node_modules/npm/man/man1/npm-sbom.1
generated
vendored
Normal file
314
Dependencies/NodeJS/node_modules/npm/man/man1/npm-sbom.1
generated
vendored
Normal file
@ -0,0 +1,314 @@
|
||||
.TH "NPM-SBOM" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-sbom\fR - Generate a Software Bill of Materials (SBOM)
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm sbom
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
The \fBnpm sbom\fR command generates a Software Bill of Materials (SBOM) listing the dependencies for the current project. SBOMs can be generated in either \fBSPDX\fR \fI\(lahttps://spdx.dev/\(ra\fR or \fBCycloneDX\fR \fI\(lahttps://cyclonedx.org/\(ra\fR format.
|
||||
.SS "Example CycloneDX SBOM"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
{
|
||||
"$schema": "http://cyclonedx.org/schema/bom-1.5.schema.json",
|
||||
"bomFormat": "CycloneDX",
|
||||
"specVersion": "1.5",
|
||||
"serialNumber": "urn:uuid:09f55116-97e1-49cf-b3b8-44d0207e7730",
|
||||
"version": 1,
|
||||
"metadata": {
|
||||
"timestamp": "2023-09-01T00:00:00.001Z",
|
||||
"lifecycles": \[lB]
|
||||
{
|
||||
"phase": "build"
|
||||
}
|
||||
\[rB],
|
||||
"tools": \[lB]
|
||||
{
|
||||
"vendor": "npm",
|
||||
"name": "cli",
|
||||
"version": "10.1.0"
|
||||
}
|
||||
\[rB],
|
||||
"component": {
|
||||
"bom-ref": "simple@1.0.0",
|
||||
"type": "library",
|
||||
"name": "simple",
|
||||
"version": "1.0.0",
|
||||
"scope": "required",
|
||||
"author": "John Doe",
|
||||
"description": "simple react app",
|
||||
"purl": "pkg:npm/simple@1.0.0",
|
||||
"properties": \[lB]
|
||||
{
|
||||
"name": "cdx:npm:package:path",
|
||||
"value": ""
|
||||
}
|
||||
\[rB],
|
||||
"externalReferences": \[lB]\[rB],
|
||||
"licenses": \[lB]
|
||||
{
|
||||
"license": {
|
||||
"id": "MIT"
|
||||
}
|
||||
}
|
||||
\[rB]
|
||||
}
|
||||
},
|
||||
"components": \[lB]
|
||||
{
|
||||
"bom-ref": "lodash@4.17.21",
|
||||
"type": "library",
|
||||
"name": "lodash",
|
||||
"version": "4.17.21",
|
||||
"scope": "required",
|
||||
"author": "John-David Dalton",
|
||||
"description": "Lodash modular utilities.",
|
||||
"purl": "pkg:npm/lodash@4.17.21",
|
||||
"properties": \[lB]
|
||||
{
|
||||
"name": "cdx:npm:package:path",
|
||||
"value": "node_modules/lodash"
|
||||
}
|
||||
\[rB],
|
||||
"externalReferences": \[lB]
|
||||
{
|
||||
"type": "distribution",
|
||||
"url": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz"
|
||||
},
|
||||
{
|
||||
"type": "vcs",
|
||||
"url": "git+https://github.com/lodash/lodash.git"
|
||||
},
|
||||
{
|
||||
"type": "website",
|
||||
"url": "https://lodash.com/"
|
||||
},
|
||||
{
|
||||
"type": "issue-tracker",
|
||||
"url": "https://github.com/lodash/lodash/issues"
|
||||
}
|
||||
\[rB],
|
||||
"hashes": \[lB]
|
||||
{
|
||||
"alg": "SHA-512",
|
||||
"content": "bf690311ee7b95e713ba568322e3533f2dd1cb880b189e99d4edef13592b81764daec43e2c54c61d5c558dc5cfb35ecb85b65519e74026ff17675b6f8f916f4a"
|
||||
}
|
||||
\[rB],
|
||||
"licenses": \[lB]
|
||||
{
|
||||
"license": {
|
||||
"id": "MIT"
|
||||
}
|
||||
}
|
||||
\[rB]
|
||||
}
|
||||
\[rB],
|
||||
"dependencies": \[lB]
|
||||
{
|
||||
"ref": "simple@1.0.0",
|
||||
"dependsOn": \[lB]
|
||||
"lodash@4.17.21"
|
||||
\[rB]
|
||||
},
|
||||
{
|
||||
"ref": "lodash@4.17.21",
|
||||
"dependsOn": \[lB]\[rB]
|
||||
}
|
||||
\[rB]
|
||||
}
|
||||
.fi
|
||||
.RE
|
||||
.SS "Example SPDX SBOM"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
{
|
||||
"spdxVersion": "SPDX-2.3",
|
||||
"dataLicense": "CC0-1.0",
|
||||
"SPDXID": "SPDXRef-DOCUMENT",
|
||||
"name": "simple@1.0.0",
|
||||
"documentNamespace": "http://spdx.org/spdxdocs/simple-1.0.0-bf81090e-8bbc-459d-bec9-abeb794e096a",
|
||||
"creationInfo": {
|
||||
"created": "2023-09-01T00:00:00.001Z",
|
||||
"creators": \[lB]
|
||||
"Tool: npm/cli-10.1.0"
|
||||
\[rB]
|
||||
},
|
||||
"documentDescribes": \[lB]
|
||||
"SPDXRef-Package-simple-1.0.0"
|
||||
\[rB],
|
||||
"packages": \[lB]
|
||||
{
|
||||
"name": "simple",
|
||||
"SPDXID": "SPDXRef-Package-simple-1.0.0",
|
||||
"versionInfo": "1.0.0",
|
||||
"packageFileName": "",
|
||||
"description": "simple react app",
|
||||
"primaryPackagePurpose": "LIBRARY",
|
||||
"downloadLocation": "NOASSERTION",
|
||||
"filesAnalyzed": false,
|
||||
"homepage": "NOASSERTION",
|
||||
"licenseDeclared": "MIT",
|
||||
"externalRefs": \[lB]
|
||||
{
|
||||
"referenceCategory": "PACKAGE-MANAGER",
|
||||
"referenceType": "purl",
|
||||
"referenceLocator": "pkg:npm/simple@1.0.0"
|
||||
}
|
||||
\[rB]
|
||||
},
|
||||
{
|
||||
"name": "lodash",
|
||||
"SPDXID": "SPDXRef-Package-lodash-4.17.21",
|
||||
"versionInfo": "4.17.21",
|
||||
"packageFileName": "node_modules/lodash",
|
||||
"description": "Lodash modular utilities.",
|
||||
"downloadLocation": "https://registry.npmjs.org/lodash/-/lodash-4.17.21.tgz",
|
||||
"filesAnalyzed": false,
|
||||
"homepage": "https://lodash.com/",
|
||||
"licenseDeclared": "MIT",
|
||||
"externalRefs": \[lB]
|
||||
{
|
||||
"referenceCategory": "PACKAGE-MANAGER",
|
||||
"referenceType": "purl",
|
||||
"referenceLocator": "pkg:npm/lodash@4.17.21"
|
||||
}
|
||||
\[rB],
|
||||
"checksums": \[lB]
|
||||
{
|
||||
"algorithm": "SHA512",
|
||||
"checksumValue": "bf690311ee7b95e713ba568322e3533f2dd1cb880b189e99d4edef13592b81764daec43e2c54c61d5c558dc5cfb35ecb85b65519e74026ff17675b6f8f916f4a"
|
||||
}
|
||||
\[rB]
|
||||
}
|
||||
\[rB],
|
||||
"relationships": \[lB]
|
||||
{
|
||||
"spdxElementId": "SPDXRef-DOCUMENT",
|
||||
"relatedSpdxElement": "SPDXRef-Package-simple-1.0.0",
|
||||
"relationshipType": "DESCRIBES"
|
||||
},
|
||||
{
|
||||
"spdxElementId": "SPDXRef-Package-simple-1.0.0",
|
||||
"relatedSpdxElement": "SPDXRef-Package-lodash-4.17.21",
|
||||
"relationshipType": "DEPENDS_ON"
|
||||
}
|
||||
\[rB]
|
||||
}
|
||||
.fi
|
||||
.RE
|
||||
.SS "Package lock only mode"
|
||||
.P
|
||||
If package-lock-only is enabled, only the information in the package lock (or shrinkwrap) is loaded. This means that information from the package.json files of your dependencies will not be included in the result set (e.g. description, homepage, engines).
|
||||
.SS "Configuration"
|
||||
.SS "\fBomit\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production', otherwise empty.
|
||||
.IP \(bu 4
|
||||
Type: "dev", "optional", or "peer" (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Dependency types to omit from the installation tree on disk.
|
||||
.P
|
||||
Note that these dependencies \fIare\fR still resolved and added to the \fBpackage-lock.json\fR or \fBnpm-shrinkwrap.json\fR file. They are just not physically installed on disk.
|
||||
.P
|
||||
If a package type appears in both the \fB--include\fR and \fB--omit\fR lists, then it will be included.
|
||||
.P
|
||||
If the resulting omit list includes \fB'dev'\fR, then the \fBNODE_ENV\fR environment variable will be set to \fB'production'\fR for all lifecycle scripts.
|
||||
.SS "\fBpackage-lock-only\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If set to true, the current operation will only use the \fBpackage-lock.json\fR, ignoring \fBnode_modules\fR.
|
||||
.P
|
||||
For \fBupdate\fR this means only the \fBpackage-lock.json\fR will be updated, instead of checking \fBnode_modules\fR and downloading dependencies.
|
||||
.P
|
||||
For \fBlist\fR this means the output will be based on the tree described by the \fBpackage-lock.json\fR, rather than the contents of \fBnode_modules\fR.
|
||||
.SS "\fBsbom-format\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: "cyclonedx" or "spdx"
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
SBOM format to use when generating SBOMs.
|
||||
.SS "\fBsbom-type\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "library"
|
||||
.IP \(bu 4
|
||||
Type: "library", "application", or "framework"
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The type of package described by the generated SBOM. For SPDX, this is the value for the \fBprimaryPackagePurpose\fR field. For CycloneDX, this is the value for the \fBtype\fR field.
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SH "SEE ALSO"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help "package spec"
|
||||
.IP \(bu 4
|
||||
npm help "dependency selectors"
|
||||
.IP \(bu 4
|
||||
\fBpackage.json\fR \fI\(la/configuring-npm/package-json\(ra\fR
|
||||
.IP \(bu 4
|
||||
npm help workspaces
|
||||
.RE 0
|
||||
156
Dependencies/NodeJS/node_modules/npm/man/man1/npm-search.1
generated
vendored
Normal file
156
Dependencies/NodeJS/node_modules/npm/man/man1/npm-search.1
generated
vendored
Normal file
@ -0,0 +1,156 @@
|
||||
.TH "NPM-SEARCH" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-search\fR - Search for packages
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm search <search term> \[lB]<search term> ...\[rB]
|
||||
|
||||
aliases: find, s, se
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Description"
|
||||
.P
|
||||
Search the registry for packages matching the search terms. \fBnpm search\fR performs a linear, incremental, lexically-ordered search through package metadata for all files in the registry. If your terminal has color support, it will further highlight the matches in the results. This can be disabled with the config item \fBcolor\fR
|
||||
.P
|
||||
Additionally, using the \fB--searchopts\fR and \fB--searchexclude\fR options paired with more search terms will include and exclude further patterns. The main difference between \fB--searchopts\fR and the standard search terms is that the former does not highlight results in the output and you can use them more fine-grained filtering. Additionally, you can add both of these to your config to change default search filtering behavior.
|
||||
.P
|
||||
Search also allows targeting of maintainers in search results, by prefixing their npm username with \fB=\fR.
|
||||
.P
|
||||
If a term starts with \fB/\fR, then it's interpreted as a regular expression and supports standard JavaScript RegExp syntax. In this case search will ignore a trailing \fB/\fR . (Note you must escape or quote many regular expression characters in most shells.)
|
||||
.SS "Configuration"
|
||||
.SS "\fBjson\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Whether or not to output JSON data, rather than the normal output.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
In \fBnpm pkg set\fR it enables parsing set values with JSON.parse() before saving them to your \fBpackage.json\fR.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Not supported by all npm commands.
|
||||
.SS "\fBcolor\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true unless the NO_COLOR environ is set to something other than '0'
|
||||
.IP \(bu 4
|
||||
Type: "always" or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If false, never shows colors. If \fB"always"\fR then always shows colors. If true, then only prints color codes for tty file descriptors.
|
||||
.SS "\fBparseable\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Output parseable results from commands that write to standard output. For \fBnpm search\fR, this will be tab-separated table format.
|
||||
.SS "\fBdescription\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Show the description in \fBnpm search\fR
|
||||
.SS "\fBsearchlimit\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: 20
|
||||
.IP \(bu 4
|
||||
Type: Number
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Number of items to limit search results to. Will not apply at all to legacy searches.
|
||||
.SS "\fBsearchopts\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: ""
|
||||
.IP \(bu 4
|
||||
Type: String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Space-separated options that are always passed to search.
|
||||
.SS "\fBsearchexclude\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: ""
|
||||
.IP \(bu 4
|
||||
Type: String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Space-separated options that limit the results from search.
|
||||
.SS "\fBregistry\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "https://registry.npmjs.org/"
|
||||
.IP \(bu 4
|
||||
Type: URL
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The base URL of the npm registry.
|
||||
.SS "\fBprefer-online\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If true, staleness checks for cached data will be forced, making the CLI look for updates immediately even for fresh package data.
|
||||
.SS "\fBprefer-offline\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If true, staleness checks for cached data will be bypassed, but missing data will be requested from the server. To force full offline mode, use \fB--offline\fR.
|
||||
.SS "\fBoffline\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Force offline mode: no network requests will be done during install. To allow the CLI to fill in missing cache data, see \fB--prefer-offline\fR.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help registry
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help npmrc
|
||||
.IP \(bu 4
|
||||
npm help view
|
||||
.IP \(bu 4
|
||||
npm help cache
|
||||
.IP \(bu 4
|
||||
https://npm.im/npm-registry-fetch
|
||||
.RE 0
|
||||
32
Dependencies/NodeJS/node_modules/npm/man/man1/npm-shrinkwrap.1
generated
vendored
Normal file
32
Dependencies/NodeJS/node_modules/npm/man/man1/npm-shrinkwrap.1
generated
vendored
Normal file
@ -0,0 +1,32 @@
|
||||
.TH "NPM-SHRINKWRAP" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-shrinkwrap\fR - Lock down dependency versions for publication
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm shrinkwrap
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Description"
|
||||
.P
|
||||
This command repurposes \fBpackage-lock.json\fR into a publishable \fBnpm-shrinkwrap.json\fR or simply creates a new one. The file created and updated by this command will then take precedence over any other existing or future \fBpackage-lock.json\fR files. For a detailed explanation of the design and purpose of package locks in npm, see npm help package-lock-json.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help install
|
||||
.IP \(bu 4
|
||||
npm help run-script
|
||||
.IP \(bu 4
|
||||
npm help scripts
|
||||
.IP \(bu 4
|
||||
\fBpackage.json\fR \fI\(la/configuring-npm/package-json\(ra\fR
|
||||
.IP \(bu 4
|
||||
\fBpackage-lock.json\fR \fI\(la/configuring-npm/package-lock-json\(ra\fR
|
||||
.IP \(bu 4
|
||||
\fBnpm-shrinkwrap.json\fR \fI\(la/configuring-npm/npm-shrinkwrap-json\(ra\fR
|
||||
.IP \(bu 4
|
||||
npm help ls
|
||||
.RE 0
|
||||
76
Dependencies/NodeJS/node_modules/npm/man/man1/npm-star.1
generated
vendored
Normal file
76
Dependencies/NodeJS/node_modules/npm/man/man1/npm-star.1
generated
vendored
Normal file
@ -0,0 +1,76 @@
|
||||
.TH "NPM-STAR" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-star\fR - Mark your favorite packages
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm star \[lB]<package-spec>...\[rB]
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Description"
|
||||
.P
|
||||
"Starring" a package means that you have some interest in it. It's a vaguely positive way to show that you care.
|
||||
.P
|
||||
It's a boolean thing. Starring repeatedly has no additional effect.
|
||||
.SS "More"
|
||||
.P
|
||||
There's also these extra commands to help you manage your favorite packages:
|
||||
.SS "Unstar"
|
||||
.P
|
||||
You can also "unstar" a package using npm help unstar
|
||||
.P
|
||||
"Unstarring" is the same thing, but in reverse.
|
||||
.SS "Listing stars"
|
||||
.P
|
||||
You can see all your starred packages using npm help stars
|
||||
.SS "Configuration"
|
||||
.SS "\fBregistry\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "https://registry.npmjs.org/"
|
||||
.IP \(bu 4
|
||||
Type: URL
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The base URL of the npm registry.
|
||||
.SS "\fBunicode\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false on windows, true on mac/unix systems with a unicode locale, as defined by the \fBLC_ALL\fR, \fBLC_CTYPE\fR, or \fBLANG\fR environment variables.
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set to true, npm uses unicode characters in the tree output. When false, it uses ascii characters instead of unicode glyphs.
|
||||
.SS "\fBotp\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm access\fR.
|
||||
.P
|
||||
If not set, and a registry response fails with a challenge for a one-time password, npm will prompt on the command line for one.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help "package spec"
|
||||
.IP \(bu 4
|
||||
npm help unstar
|
||||
.IP \(bu 4
|
||||
npm help stars
|
||||
.IP \(bu 4
|
||||
npm help view
|
||||
.IP \(bu 4
|
||||
npm help whoami
|
||||
.IP \(bu 4
|
||||
npm help adduser
|
||||
.RE 0
|
||||
41
Dependencies/NodeJS/node_modules/npm/man/man1/npm-stars.1
generated
vendored
Normal file
41
Dependencies/NodeJS/node_modules/npm/man/man1/npm-stars.1
generated
vendored
Normal file
@ -0,0 +1,41 @@
|
||||
.TH "NPM-STARS" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-stars\fR - View packages marked as favorites
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm stars \[lB]<user>\[rB]
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Description"
|
||||
.P
|
||||
If you have starred a lot of neat things and want to find them again quickly this command lets you do just that.
|
||||
.P
|
||||
You may also want to see your friend's favorite packages, in this case you will most certainly enjoy this command.
|
||||
.SS "Configuration"
|
||||
.SS "\fBregistry\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "https://registry.npmjs.org/"
|
||||
.IP \(bu 4
|
||||
Type: URL
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The base URL of the npm registry.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help star
|
||||
.IP \(bu 4
|
||||
npm help unstar
|
||||
.IP \(bu 4
|
||||
npm help view
|
||||
.IP \(bu 4
|
||||
npm help whoami
|
||||
.IP \(bu 4
|
||||
npm help adduser
|
||||
.RE 0
|
||||
79
Dependencies/NodeJS/node_modules/npm/man/man1/npm-start.1
generated
vendored
Normal file
79
Dependencies/NodeJS/node_modules/npm/man/man1/npm-start.1
generated
vendored
Normal file
@ -0,0 +1,79 @@
|
||||
.TH "NPM-START" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-start\fR - Start a package
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm start \[lB]-- <args>\[rB]
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
This runs a predefined command specified in the \fB"start"\fR property of a package's \fB"scripts"\fR object.
|
||||
.P
|
||||
If the \fB"scripts"\fR object does not define a \fB"start"\fR property, npm will run \fBnode server.js\fR.
|
||||
.P
|
||||
Note that this is different from the default node behavior of running the file specified in a package's \fB"main"\fR attribute when evoking with \fBnode .\fR
|
||||
.P
|
||||
As of \fB\fBnpm@2.0.0\fR\fR \fI\(lahttps://blog.npmjs.org/post/98131109725/npm-2-0-0\(ra\fR, you can use custom arguments when executing scripts. Refer to npm help run-script for more details.
|
||||
.SS "Example"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
{
|
||||
"scripts": {
|
||||
"start": "node foo.js"
|
||||
}
|
||||
}
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm start
|
||||
|
||||
> npm@x.x.x start
|
||||
> node foo.js
|
||||
|
||||
(foo.js output would be here)
|
||||
|
||||
.fi
|
||||
.RE
|
||||
.SS "Configuration"
|
||||
.SS "\fBignore-scripts\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If true, npm does not run scripts specified in package.json files.
|
||||
.P
|
||||
Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run-script\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts.
|
||||
.SS "\fBscript-shell\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows
|
||||
.IP \(bu 4
|
||||
Type: null or String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The shell to use for scripts run with the \fBnpm exec\fR, \fBnpm run\fR and \fBnpm
|
||||
init <package-spec>\fR commands.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help run-script
|
||||
.IP \(bu 4
|
||||
npm help scripts
|
||||
.IP \(bu 4
|
||||
npm help test
|
||||
.IP \(bu 4
|
||||
npm help restart
|
||||
.IP \(bu 4
|
||||
npm help stop
|
||||
.RE 0
|
||||
75
Dependencies/NodeJS/node_modules/npm/man/man1/npm-stop.1
generated
vendored
Normal file
75
Dependencies/NodeJS/node_modules/npm/man/man1/npm-stop.1
generated
vendored
Normal file
@ -0,0 +1,75 @@
|
||||
.TH "NPM-STOP" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-stop\fR - Stop a package
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm stop \[lB]-- <args>\[rB]
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
This runs a predefined command specified in the "stop" property of a package's "scripts" object.
|
||||
.P
|
||||
Unlike with npm help start, there is no default script that will run if the \fB"stop"\fR property is not defined.
|
||||
.SS "Example"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
{
|
||||
"scripts": {
|
||||
"stop": "node bar.js"
|
||||
}
|
||||
}
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm stop
|
||||
|
||||
> npm@x.x.x stop
|
||||
> node bar.js
|
||||
|
||||
(bar.js output would be here)
|
||||
|
||||
.fi
|
||||
.RE
|
||||
.SS "Configuration"
|
||||
.SS "\fBignore-scripts\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If true, npm does not run scripts specified in package.json files.
|
||||
.P
|
||||
Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run-script\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts.
|
||||
.SS "\fBscript-shell\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows
|
||||
.IP \(bu 4
|
||||
Type: null or String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The shell to use for scripts run with the \fBnpm exec\fR, \fBnpm run\fR and \fBnpm
|
||||
init <package-spec>\fR commands.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help run-script
|
||||
.IP \(bu 4
|
||||
npm help scripts
|
||||
.IP \(bu 4
|
||||
npm help test
|
||||
.IP \(bu 4
|
||||
npm help start
|
||||
.IP \(bu 4
|
||||
npm help restart
|
||||
.RE 0
|
||||
148
Dependencies/NodeJS/node_modules/npm/man/man1/npm-team.1
generated
vendored
Normal file
148
Dependencies/NodeJS/node_modules/npm/man/man1/npm-team.1
generated
vendored
Normal file
@ -0,0 +1,148 @@
|
||||
.TH "NPM-TEAM" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-team\fR - Manage organization teams and team memberships
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm team create <scope:team> \[lB]--otp <otpcode>\[rB]
|
||||
npm team destroy <scope:team> \[lB]--otp <otpcode>\[rB]
|
||||
npm team add <scope:team> <user> \[lB]--otp <otpcode>\[rB]
|
||||
npm team rm <scope:team> <user> \[lB]--otp <otpcode>\[rB]
|
||||
npm team ls <scope>|<scope:team>
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Description"
|
||||
.P
|
||||
Used to manage teams in organizations, and change team memberships. Does not handle permissions for packages.
|
||||
.P
|
||||
Teams must always be fully qualified with the organization/scope they belong to when operating on them, separated by a colon (\fB:\fR). That is, if you have a \fBnewteam\fR team in an \fBorg\fR organization, you must always refer to that team as \fB@org:newteam\fR in these commands.
|
||||
.P
|
||||
If you have two-factor authentication enabled in \fBauth-and-writes\fR mode, then you can provide a code from your authenticator with \fB\[lB]--otp <otpcode>\[rB]\fR. If you don't include this then you will be taken through a second factor flow based on your \fBauthtype\fR.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
create / destroy: Create a new team, or destroy an existing one. Note: You cannot remove the \fBdevelopers\fR team, \fBlearn more.\fR \fI\(lahttps://docs.npmjs.com/about-developers-team\(ra\fR
|
||||
.P
|
||||
Here's how to create a new team \fBnewteam\fR under the \fBorg\fR org:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm team create @org:newteam
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
You should see a confirming message such as: \fB+@org:newteam\fR once the new team has been created.
|
||||
.IP \(bu 4
|
||||
add: Add a user to an existing team.
|
||||
.P
|
||||
Adding a new user \fBusername\fR to a team named \fBnewteam\fR under the \fBorg\fR org:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm team add @org:newteam username
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
On success, you should see a message: \fBusername added to @org:newteam\fR
|
||||
.IP \(bu 4
|
||||
rm: Using \fBnpm team rm\fR you can also remove users from a team they belong to.
|
||||
.P
|
||||
Here's an example removing user \fBusername\fR from \fBnewteam\fR team in \fBorg\fR organization:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm team rm @org:newteam username
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Once the user is removed a confirmation message is displayed: \fBusername removed from @org:newteam\fR
|
||||
.IP \(bu 4
|
||||
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.
|
||||
.P
|
||||
Here's an example of how to list all teams from an org named \fBorg\fR:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm team ls @org
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Example listing all members of a team named \fBnewteam\fR:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm team ls @org:newteam
|
||||
.fi
|
||||
.RE
|
||||
.RE 0
|
||||
|
||||
.SS "Details"
|
||||
.P
|
||||
\fBnpm team\fR always operates directly on the current registry, configurable from the command line using \fB--registry=<registry url>\fR.
|
||||
.P
|
||||
You must be a \fIteam admin\fR to create teams and manage team membership, under the given organization. Listing teams and team memberships may be done by any member of the organization.
|
||||
.P
|
||||
Organization creation and management of team admins and \fIorganization\fR members is done through the website, not the npm CLI.
|
||||
.P
|
||||
To use teams to manage permissions on packages belonging to your organization, use the \fBnpm access\fR command to grant or revoke the appropriate permissions.
|
||||
.SS "Configuration"
|
||||
.SS "\fBregistry\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "https://registry.npmjs.org/"
|
||||
.IP \(bu 4
|
||||
Type: URL
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The base URL of the npm registry.
|
||||
.SS "\fBotp\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm access\fR.
|
||||
.P
|
||||
If not set, and a registry response fails with a challenge for a one-time password, npm will prompt on the command line for one.
|
||||
.SS "\fBparseable\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Output parseable results from commands that write to standard output. For \fBnpm search\fR, this will be tab-separated table format.
|
||||
.SS "\fBjson\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Whether or not to output JSON data, rather than the normal output.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
In \fBnpm pkg set\fR it enables parsing set values with JSON.parse() before saving them to your \fBpackage.json\fR.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Not supported by all npm commands.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help access
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help registry
|
||||
.RE 0
|
||||
73
Dependencies/NodeJS/node_modules/npm/man/man1/npm-test.1
generated
vendored
Normal file
73
Dependencies/NodeJS/node_modules/npm/man/man1/npm-test.1
generated
vendored
Normal file
@ -0,0 +1,73 @@
|
||||
.TH "NPM-TEST" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-test\fR - Test a package
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm test \[lB]-- <args>\[rB]
|
||||
|
||||
aliases: tst, t
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
This runs a predefined command specified in the \fB"test"\fR property of a package's \fB"scripts"\fR object.
|
||||
.SS "Example"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
{
|
||||
"scripts": {
|
||||
"test": "node test.js"
|
||||
}
|
||||
}
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm test
|
||||
> npm@x.x.x test
|
||||
> node test.js
|
||||
|
||||
(test.js output would be here)
|
||||
.fi
|
||||
.RE
|
||||
.SS "Configuration"
|
||||
.SS "\fBignore-scripts\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If true, npm does not run scripts specified in package.json files.
|
||||
.P
|
||||
Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run-script\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts.
|
||||
.SS "\fBscript-shell\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: '/bin/sh' on POSIX systems, 'cmd.exe' on Windows
|
||||
.IP \(bu 4
|
||||
Type: null or String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The shell to use for scripts run with the \fBnpm exec\fR, \fBnpm run\fR and \fBnpm
|
||||
init <package-spec>\fR commands.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help run-script
|
||||
.IP \(bu 4
|
||||
npm help scripts
|
||||
.IP \(bu 4
|
||||
npm help start
|
||||
.IP \(bu 4
|
||||
npm help restart
|
||||
.IP \(bu 4
|
||||
npm help stop
|
||||
.RE 0
|
||||
112
Dependencies/NodeJS/node_modules/npm/man/man1/npm-token.1
generated
vendored
Normal file
112
Dependencies/NodeJS/node_modules/npm/man/man1/npm-token.1
generated
vendored
Normal file
@ -0,0 +1,112 @@
|
||||
.TH "NPM-TOKEN" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-token\fR - Manage your authentication tokens
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm token list
|
||||
npm token revoke <id|token>
|
||||
npm token create \[lB]--read-only\[rB] \[lB]--cidr=list\[rB]
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Description"
|
||||
.P
|
||||
This lets you list, create and revoke authentication tokens.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
\fBnpm token list\fR: Shows a table of all active authentication tokens. You can request this as JSON with \fB--json\fR or tab-separated values with \fB--parseable\fR.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
Read only token npm_1f… with id 7f3134 created 2017-10-21
|
||||
|
||||
Publish token npm_af… with id c03241 created 2017-10-02
|
||||
with IP Whitelist: 192.168.0.1/24
|
||||
|
||||
Publish token npm_… with id e0cf92 created 2017-10-02
|
||||
|
||||
.fi
|
||||
.RE
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
\fBnpm token create \[lB]--read-only\[rB] \[lB]--cidr=<cidr-ranges>\[rB]\fR: Create a new authentication token. It can be \fB--read-only\fR, or accept a list of \fBCIDR\fR \fI\(lahttps://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing\(ra\fR ranges with which to limit use of this token. This will prompt you for your password, and, if you have two-factor authentication enabled, an otp.
|
||||
.P
|
||||
Currently, the cli can not generate automation tokens. Please refer to the \fBdocs website\fR \fI\(lahttps://docs.npmjs.com/creating-and-viewing-access-tokens\(ra\fR for more information on generating automation tokens.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
Created publish token a73c9572-f1b9-8983-983d-ba3ac3cc913d
|
||||
.fi
|
||||
.RE
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
\fBnpm token revoke <token|id>\fR: Immediately removes an authentication token from the registry. You will no longer be able to use it. This can accept both complete tokens (such as those you get back from \fBnpm token create\fR, and those found in your \fB.npmrc\fR), and ids as seen in the parseable or json output of \fBnpm token list\fR. This will NOT accept the truncated token found in the normal \fBnpm token list\fR output.
|
||||
.RE 0
|
||||
|
||||
.SS "Configuration"
|
||||
.SS "\fBread-only\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This is used to mark a token as unable to publish when configuring limited access tokens with the \fBnpm token create\fR command.
|
||||
.SS "\fBcidr\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This is a list of CIDR address to be used when configuring limited access tokens with the \fBnpm token create\fR command.
|
||||
.SS "\fBregistry\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "https://registry.npmjs.org/"
|
||||
.IP \(bu 4
|
||||
Type: URL
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The base URL of the npm registry.
|
||||
.SS "\fBotp\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm access\fR.
|
||||
.P
|
||||
If not set, and a registry response fails with a challenge for a one-time password, npm will prompt on the command line for one.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help adduser
|
||||
.IP \(bu 4
|
||||
npm help registry
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help npmrc
|
||||
.IP \(bu 4
|
||||
npm help owner
|
||||
.IP \(bu 4
|
||||
npm help whoami
|
||||
.IP \(bu 4
|
||||
npm help profile
|
||||
.RE 0
|
||||
159
Dependencies/NodeJS/node_modules/npm/man/man1/npm-uninstall.1
generated
vendored
Normal file
159
Dependencies/NodeJS/node_modules/npm/man/man1/npm-uninstall.1
generated
vendored
Normal file
@ -0,0 +1,159 @@
|
||||
.TH "NPM-UNINSTALL" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-uninstall\fR - Remove a package
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm uninstall \[lB]<@scope>/\[rB]<pkg>...
|
||||
|
||||
aliases: unlink, remove, rm, r, un
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
This uninstalls a package, completely removing everything npm installed on its behalf.
|
||||
.P
|
||||
It also removes the package from the \fBdependencies\fR, \fBdevDependencies\fR, \fBoptionalDependencies\fR, and \fBpeerDependencies\fR objects in your \fBpackage.json\fR.
|
||||
.P
|
||||
Further, if you have an \fBnpm-shrinkwrap.json\fR or \fBpackage-lock.json\fR, npm will update those files as well.
|
||||
.P
|
||||
\fB--no-save\fR will tell npm not to remove the package from your \fBpackage.json\fR, \fBnpm-shrinkwrap.json\fR, or \fBpackage-lock.json\fR files.
|
||||
.P
|
||||
\fB--save\fR or \fB-S\fR will tell npm to remove the package from your \fBpackage.json\fR, \fBnpm-shrinkwrap.json\fR, and \fBpackage-lock.json\fR files. This is the default, but you may need to use this if you have for instance \fBsave=false\fR in your \fBnpmrc\fR file
|
||||
.P
|
||||
In global mode (ie, with \fB-g\fR or \fB--global\fR appended to the command), it uninstalls the current package context as a global package. \fB--no-save\fR is ignored in this case.
|
||||
.P
|
||||
Scope is optional and follows the usual rules for npm help scope.
|
||||
.SS "Examples"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm uninstall sax
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
\fBsax\fR will no longer be in your \fBpackage.json\fR, \fBnpm-shrinkwrap.json\fR, or \fBpackage-lock.json\fR files.
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm uninstall lodash --no-save
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
\fBlodash\fR will not be removed from your \fBpackage.json\fR, \fBnpm-shrinkwrap.json\fR, or \fBpackage-lock.json\fR files.
|
||||
.SS "Configuration"
|
||||
.SS "\fBsave\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: \fBtrue\fR unless when using \fBnpm update\fR where it defaults to \fBfalse\fR
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Save installed packages to a \fBpackage.json\fR file as dependencies.
|
||||
.P
|
||||
When used with the \fBnpm rm\fR command, removes the dependency from \fBpackage.json\fR.
|
||||
.P
|
||||
Will also prevent writing to \fBpackage-lock.json\fR if set to \fBfalse\fR.
|
||||
.SS "\fBglobal\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Operates in "global" mode, so that packages are installed into the \fBprefix\fR folder instead of the current working directory. See npm help folders for more on the differences in behavior.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
packages are installed into the \fB{prefix}/lib/node_modules\fR folder, instead of the current working directory.
|
||||
.IP \(bu 4
|
||||
bin files are linked to \fB{prefix}/bin\fR
|
||||
.IP \(bu 4
|
||||
man pages are linked to \fB{prefix}/share/man\fR
|
||||
.RE 0
|
||||
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinclude-workspace-root\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
.P
|
||||
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinstall-links\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set file: protocol dependencies will be packed and installed as regular dependencies instead of creating a symlink. This option has no effect on workspaces.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help prune
|
||||
.IP \(bu 4
|
||||
npm help install
|
||||
.IP \(bu 4
|
||||
npm help folders
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help npmrc
|
||||
.RE 0
|
||||
137
Dependencies/NodeJS/node_modules/npm/man/man1/npm-unpublish.1
generated
vendored
Normal file
137
Dependencies/NodeJS/node_modules/npm/man/man1/npm-unpublish.1
generated
vendored
Normal file
@ -0,0 +1,137 @@
|
||||
.TH "NPM-UNPUBLISH" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-unpublish\fR - Remove a package from the registry
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm unpublish \[lB]<package-spec>\[rB]
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
To learn more about how the npm registry treats unpublish, see our \fBunpublish policies\fR \fI\(lahttps://docs.npmjs.com/policies/unpublish\(ra\fR.
|
||||
.SS "Warning"
|
||||
.P
|
||||
Consider using the npm help deprecate command instead, if your intent is to encourage users to upgrade, or if you no longer want to maintain a package.
|
||||
.SS "Description"
|
||||
.P
|
||||
This removes a package version from the registry, deleting its entry and removing the tarball.
|
||||
.P
|
||||
The npm registry will return an error if you are not npm help "logged in".
|
||||
.P
|
||||
If you do not specify a package name at all, the name and version to be unpublished will be pulled from the project in the current directory.
|
||||
.P
|
||||
If you specify a package name but do not specify a version or if you remove all of a package's versions then the registry will remove the root package entry entirely.
|
||||
.P
|
||||
Even if you unpublish a package version, that specific name and version combination can never be reused. In order to publish the package again, you must use a new version number. If you unpublish the entire package, you may not publish any new versions of that package until 24 hours have passed.
|
||||
.SS "Configuration"
|
||||
.SS "\fBdry-run\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, \fBinstall\fR, \fBupdate\fR, \fBdedupe\fR, \fBuninstall\fR, as well as \fBpack\fR and \fBpublish\fR.
|
||||
.P
|
||||
Note: This is NOT honored by other network related commands, eg \fBdist-tags\fR, \fBowner\fR, etc.
|
||||
.SS "\fBforce\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Removes various protections against unfortunate side effects, common mistakes, unnecessary performance degradation, and malicious input.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Allow clobbering non-npm files in global installs.
|
||||
.IP \(bu 4
|
||||
Allow the \fBnpm version\fR command to work on an unclean git repository.
|
||||
.IP \(bu 4
|
||||
Allow deleting the cache folder with \fBnpm cache clean\fR.
|
||||
.IP \(bu 4
|
||||
Allow installing packages that have an \fBengines\fR declaration requiring a different version of npm.
|
||||
.IP \(bu 4
|
||||
Allow installing packages that have an \fBengines\fR declaration requiring a different version of \fBnode\fR, even if \fB--engine-strict\fR is enabled.
|
||||
.IP \(bu 4
|
||||
Allow \fBnpm audit fix\fR to install modules outside your stated dependency range (including SemVer-major changes).
|
||||
.IP \(bu 4
|
||||
Allow unpublishing all versions of a published package.
|
||||
.IP \(bu 4
|
||||
Allow conflicting peerDependencies to be installed in the root project.
|
||||
.IP \(bu 4
|
||||
Implicitly set \fB--yes\fR during \fBnpm init\fR.
|
||||
.IP \(bu 4
|
||||
Allow clobbering existing values in \fBnpm pkg\fR
|
||||
.IP \(bu 4
|
||||
Allow unpublishing of entire packages (not just a single version).
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If you don't have a clear idea of what you want to do, it is strongly recommended that you do not use this option!
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help "package spec"
|
||||
.IP \(bu 4
|
||||
npm help deprecate
|
||||
.IP \(bu 4
|
||||
npm help publish
|
||||
.IP \(bu 4
|
||||
npm help registry
|
||||
.IP \(bu 4
|
||||
npm help adduser
|
||||
.IP \(bu 4
|
||||
npm help owner
|
||||
.IP \(bu 4
|
||||
npm help login
|
||||
.RE 0
|
||||
70
Dependencies/NodeJS/node_modules/npm/man/man1/npm-unstar.1
generated
vendored
Normal file
70
Dependencies/NodeJS/node_modules/npm/man/man1/npm-unstar.1
generated
vendored
Normal file
@ -0,0 +1,70 @@
|
||||
.TH "NPM-UNSTAR" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-unstar\fR - Remove an item from your favorite packages
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm unstar \[lB]<package-spec>...\[rB]
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Description"
|
||||
.P
|
||||
"Unstarring" a package is the opposite of npm help star, it removes an item from your list of favorite packages.
|
||||
.SS "More"
|
||||
.P
|
||||
There's also these extra commands to help you manage your favorite packages:
|
||||
.SS "Star"
|
||||
.P
|
||||
You can "star" a package using npm help star
|
||||
.SS "Listing stars"
|
||||
.P
|
||||
You can see all your starred packages using npm help stars
|
||||
.SS "Configuration"
|
||||
.SS "\fBregistry\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "https://registry.npmjs.org/"
|
||||
.IP \(bu 4
|
||||
Type: URL
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The base URL of the npm registry.
|
||||
.SS "\fBunicode\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false on windows, true on mac/unix systems with a unicode locale, as defined by the \fBLC_ALL\fR, \fBLC_CTYPE\fR, or \fBLANG\fR environment variables.
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set to true, npm uses unicode characters in the tree output. When false, it uses ascii characters instead of unicode glyphs.
|
||||
.SS "\fBotp\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This is a one-time password from a two-factor authenticator. It's needed when publishing or changing package permissions with \fBnpm access\fR.
|
||||
.P
|
||||
If not set, and a registry response fails with a challenge for a one-time password, npm will prompt on the command line for one.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help star
|
||||
.IP \(bu 4
|
||||
npm help stars
|
||||
.IP \(bu 4
|
||||
npm help view
|
||||
.IP \(bu 4
|
||||
npm help whoami
|
||||
.IP \(bu 4
|
||||
npm help adduser
|
||||
.RE 0
|
||||
406
Dependencies/NodeJS/node_modules/npm/man/man1/npm-update.1
generated
vendored
Normal file
406
Dependencies/NodeJS/node_modules/npm/man/man1/npm-update.1
generated
vendored
Normal file
@ -0,0 +1,406 @@
|
||||
.TH "NPM-UPDATE" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-update\fR - Update packages
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm update \[lB]<pkg>...\[rB]
|
||||
|
||||
aliases: up, upgrade, udpate
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
This command will update all the packages listed to the latest version (specified by the \fB\fBtag\fR config\fR \fI\(la/using-npm/config#tag\(ra\fR), respecting the semver constraints of both your package and its dependencies (if they also require the same package).
|
||||
.P
|
||||
It will also install missing packages.
|
||||
.P
|
||||
If the \fB-g\fR flag is specified, this command will update globally installed packages.
|
||||
.P
|
||||
If no package name is specified, all packages in the specified location (global or local) will be updated.
|
||||
.P
|
||||
Note that by default \fBnpm update\fR will not update the semver values of direct dependencies in your project \fBpackage.json\fR. If you want to also update values in \fBpackage.json\fR you can run: \fBnpm update --save\fR (or add the \fBsave=true\fR option to a npm help "configuration file" to make that the default behavior).
|
||||
.SS "Example"
|
||||
.P
|
||||
For the examples below, assume that the current package is \fBapp\fR and it depends on dependencies, \fBdep1\fR (\fBdep2\fR, .. etc.). The published versions of \fBdep1\fR are:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
{
|
||||
"dist-tags": { "latest": "1.2.2" },
|
||||
"versions": \[lB]
|
||||
"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"
|
||||
\[rB]
|
||||
}
|
||||
.fi
|
||||
.RE
|
||||
.SS "Caret Dependencies"
|
||||
.P
|
||||
If \fBapp\fR's \fBpackage.json\fR contains:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
"dependencies": {
|
||||
"dep1": "^1.1.1"
|
||||
}
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Then \fBnpm update\fR will install \fBdep1@1.2.2\fR, because \fB1.2.2\fR is \fBlatest\fR and \fB1.2.2\fR satisfies \fB^1.1.1\fR.
|
||||
.SS "Tilde Dependencies"
|
||||
.P
|
||||
However, if \fBapp\fR's \fBpackage.json\fR contains:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
"dependencies": {
|
||||
"dep1": "~1.1.1"
|
||||
}
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
In this case, running \fBnpm update\fR will install \fBdep1@1.1.2\fR. Even though the \fBlatest\fR tag points to \fB1.2.2\fR, this version does not satisfy \fB~1.1.1\fR, which is equivalent to \fB>=1.1.1 <1.2.0\fR. So the highest-sorting version that satisfies \fB~1.1.1\fR is used, which is \fB1.1.2\fR.
|
||||
.SS "Caret Dependencies below 1.0.0"
|
||||
.P
|
||||
Suppose \fBapp\fR has a caret dependency on a version below \fB1.0.0\fR, for example:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
"dependencies": {
|
||||
"dep1": "^0.2.0"
|
||||
}
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
\fBnpm update\fR will install \fBdep1@0.2.0\fR.
|
||||
.P
|
||||
If the dependence were on \fB^0.4.0\fR:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
"dependencies": {
|
||||
"dep1": "^0.4.0"
|
||||
}
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Then \fBnpm update\fR will install \fBdep1@0.4.1\fR, because that is the highest-sorting version that satisfies \fB^0.4.0\fR (\fB>= 0.4.0 <0.5.0\fR)
|
||||
.SS "Subdependencies"
|
||||
.P
|
||||
Suppose your app now also has a dependency on \fBdep2\fR
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
{
|
||||
"name": "my-app",
|
||||
"dependencies": {
|
||||
"dep1": "^1.0.0",
|
||||
"dep2": "1.0.0"
|
||||
}
|
||||
}
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
and \fBdep2\fR itself depends on this limited range of \fBdep1\fR
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
{
|
||||
"name": "dep2",
|
||||
"dependencies": {
|
||||
"dep1": "~1.1.1"
|
||||
}
|
||||
}
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Then \fBnpm update\fR will install \fBdep1@1.1.2\fR because that is the highest version that \fBdep2\fR allows. npm will prioritize having a single version of \fBdep1\fR in your tree rather than two when that single version can satisfy the semver requirements of multiple dependencies in your tree. In this case if you really did need your package to use a newer version you would need to use \fBnpm install\fR.
|
||||
.SS "Updating Globally-Installed Packages"
|
||||
.P
|
||||
\fBnpm update -g\fR will apply the \fBupdate\fR action to each globally installed package that is \fBoutdated\fR -- that is, has a version that is different from \fBwanted\fR.
|
||||
.P
|
||||
Note: Globally installed packages are treated as if they are installed with a caret semver range specified. So if you require to update to \fBlatest\fR you may need to run \fBnpm install -g \[lB]<pkg>...\[rB]\fR
|
||||
.P
|
||||
NOTE: If a package has been upgraded to a version newer than \fBlatest\fR, it will be \fIdowngraded\fR.
|
||||
.SS "Configuration"
|
||||
.SS "\fBsave\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: \fBtrue\fR unless when using \fBnpm update\fR where it defaults to \fBfalse\fR
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Save installed packages to a \fBpackage.json\fR file as dependencies.
|
||||
.P
|
||||
When used with the \fBnpm rm\fR command, removes the dependency from \fBpackage.json\fR.
|
||||
.P
|
||||
Will also prevent writing to \fBpackage-lock.json\fR if set to \fBfalse\fR.
|
||||
.SS "\fBglobal\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Operates in "global" mode, so that packages are installed into the \fBprefix\fR folder instead of the current working directory. See npm help folders for more on the differences in behavior.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
packages are installed into the \fB{prefix}/lib/node_modules\fR folder, instead of the current working directory.
|
||||
.IP \(bu 4
|
||||
bin files are linked to \fB{prefix}/bin\fR
|
||||
.IP \(bu 4
|
||||
man pages are linked to \fB{prefix}/share/man\fR
|
||||
.RE 0
|
||||
|
||||
.SS "\fBinstall-strategy\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "hoisted"
|
||||
.IP \(bu 4
|
||||
Type: "hoisted", "nested", "shallow", or "linked"
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Sets the strategy for installing packages in node_modules. hoisted (default): Install non-duplicated in top-level, and duplicated as necessary within directory structure. nested: (formerly --legacy-bundling) install in place, no hoisting. shallow (formerly --global-style) only install direct deps at top-level. linked: (experimental) install in node_modules/.store, link in place, unhoisted.
|
||||
.SS "\fBlegacy-bundling\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.IP \(bu 4
|
||||
DEPRECATED: This option has been deprecated in favor of \fB--install-strategy=nested\fR
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Instead of hoisting package installs in \fBnode_modules\fR, install packages in the same manner that they are depended on. This may cause very deep directory structures and duplicate package installs as there is no de-duplicating. Sets \fB--install-strategy=nested\fR.
|
||||
.SS "\fBglobal-style\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.IP \(bu 4
|
||||
DEPRECATED: This option has been deprecated in favor of \fB--install-strategy=shallow\fR
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Only install direct dependencies in the top level \fBnode_modules\fR, but hoist on deeper dependencies. Sets \fB--install-strategy=shallow\fR.
|
||||
.SS "\fBomit\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: 'dev' if the \fBNODE_ENV\fR environment variable is set to 'production', otherwise empty.
|
||||
.IP \(bu 4
|
||||
Type: "dev", "optional", or "peer" (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Dependency types to omit from the installation tree on disk.
|
||||
.P
|
||||
Note that these dependencies \fIare\fR still resolved and added to the \fBpackage-lock.json\fR or \fBnpm-shrinkwrap.json\fR file. They are just not physically installed on disk.
|
||||
.P
|
||||
If a package type appears in both the \fB--include\fR and \fB--omit\fR lists, then it will be included.
|
||||
.P
|
||||
If the resulting omit list includes \fB'dev'\fR, then the \fBNODE_ENV\fR environment variable will be set to \fB'production'\fR for all lifecycle scripts.
|
||||
.SS "\fBinclude\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: "prod", "dev", "optional", or "peer" (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Option that allows for defining which types of dependencies to install.
|
||||
.P
|
||||
This is the inverse of \fB--omit=<type>\fR.
|
||||
.P
|
||||
Dependency types specified in \fB--include\fR will not be omitted, regardless of the order in which omit/include are specified on the command-line.
|
||||
.SS "\fBstrict-peer-deps\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If set to \fBtrue\fR, and \fB--legacy-peer-deps\fR is not set, then \fIany\fR conflicting \fBpeerDependencies\fR will be treated as an install failure, even if npm could reasonably guess the appropriate resolution based on non-peer dependency relationships.
|
||||
.P
|
||||
By default, conflicting \fBpeerDependencies\fR deep in the dependency graph will be resolved using the nearest non-peer dependency specification, even if doing so will result in some packages receiving a peer dependency outside the range set in their package's \fBpeerDependencies\fR object.
|
||||
.P
|
||||
When such an override is performed, a warning is printed, explaining the conflict and the packages involved. If \fB--strict-peer-deps\fR is set, then this warning is treated as a failure.
|
||||
.SS "\fBpackage-lock\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If set to false, then ignore \fBpackage-lock.json\fR files when installing. This will also prevent \fIwriting\fR \fBpackage-lock.json\fR if \fBsave\fR is true.
|
||||
.SS "\fBforeground-scripts\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: \fBfalse\fR unless when using \fBnpm pack\fR or \fBnpm publish\fR where it defaults to \fBtrue\fR
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Run all build scripts (ie, \fBpreinstall\fR, \fBinstall\fR, and \fBpostinstall\fR) scripts for installed packages in the foreground process, sharing standard input, output, and error with the main npm process.
|
||||
.P
|
||||
Note that this will generally make installs run slower, and be much noisier, but can be useful for debugging.
|
||||
.SS "\fBignore-scripts\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If true, npm does not run scripts specified in package.json files.
|
||||
.P
|
||||
Note that commands explicitly intended to run a particular script, such as \fBnpm start\fR, \fBnpm stop\fR, \fBnpm restart\fR, \fBnpm test\fR, and \fBnpm run-script\fR will still run their intended script if \fBignore-scripts\fR is set, but they will \fInot\fR run any pre- or post-scripts.
|
||||
.SS "\fBaudit\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When "true" submit audit reports alongside the current npm command to the default registry and all registries configured for scopes. See the documentation for npm help audit for details on what is submitted.
|
||||
.SS "\fBbin-links\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Tells npm to create symlinks (or \fB.cmd\fR shims on Windows) for package executables.
|
||||
.P
|
||||
Set to false to have it not do this. This can be used to work around the fact that some file systems don't support symlinks, even on ostensibly Unix systems.
|
||||
.SS "\fBfund\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When "true" displays the message at the end of each \fBnpm install\fR acknowledging the number of dependencies looking for funding. See npm help fund for details.
|
||||
.SS "\fBdry-run\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Indicates that you don't want npm to make any changes and that it should only report what it would have done. This can be passed into any of the commands that modify your local installation, eg, \fBinstall\fR, \fBupdate\fR, \fBdedupe\fR, \fBuninstall\fR, as well as \fBpack\fR and \fBpublish\fR.
|
||||
.P
|
||||
Note: This is NOT honored by other network related commands, eg \fBdist-tags\fR, \fBowner\fR, etc.
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinclude-workspace-root\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
.P
|
||||
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinstall-links\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set file: protocol dependencies will be packed and installed as regular dependencies instead of creating a symlink. This option has no effect on workspaces.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help install
|
||||
.IP \(bu 4
|
||||
npm help outdated
|
||||
.IP \(bu 4
|
||||
npm help shrinkwrap
|
||||
.IP \(bu 4
|
||||
npm help registry
|
||||
.IP \(bu 4
|
||||
npm help folders
|
||||
.IP \(bu 4
|
||||
npm help ls
|
||||
.RE 0
|
||||
229
Dependencies/NodeJS/node_modules/npm/man/man1/npm-version.1
generated
vendored
Normal file
229
Dependencies/NodeJS/node_modules/npm/man/man1/npm-version.1
generated
vendored
Normal file
@ -0,0 +1,229 @@
|
||||
.TH "NPM-VERSION" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-version\fR - Bump a package version
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm version \[lB]<newversion> | major | minor | patch | premajor | preminor | prepatch | prerelease | from-git\[rB]
|
||||
|
||||
alias: verison
|
||||
.fi
|
||||
.RE
|
||||
.SS "Configuration"
|
||||
.SS "\fBallow-same-version\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Prevents throwing an error when \fBnpm version\fR is used to set the new version to the same value as the current version.
|
||||
.SS "\fBcommit-hooks\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Run git commit hooks when using the \fBnpm version\fR command.
|
||||
.SS "\fBgit-tag-version\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Tag the commit when using the \fBnpm version\fR command. Setting this to false results in no commit being made at all.
|
||||
.SS "\fBjson\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Whether or not to output JSON data, rather than the normal output.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
In \fBnpm pkg set\fR it enables parsing set values with JSON.parse() before saving them to your \fBpackage.json\fR.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Not supported by all npm commands.
|
||||
.SS "\fBpreid\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: ""
|
||||
.IP \(bu 4
|
||||
Type: String
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The "prerelease identifier" to use as a prefix for the "prerelease" part of a semver. Like the \fBrc\fR in \fB1.2.0-rc.8\fR.
|
||||
.SS "\fBsign-git-tag\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If set to true, then the \fBnpm version\fR command will tag the version using \fB-s\fR to add a signature.
|
||||
.P
|
||||
Note that git requires you to have set up GPG keys in your git configs for this to work properly.
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces-update\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: true
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
If set to true, the npm cli will run an update after operations that may possibly change the workspaces installed to the \fBnode_modules\fR folder.
|
||||
.SS "\fBinclude-workspace-root\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
.P
|
||||
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "Description"
|
||||
.P
|
||||
Run this in a package directory to bump the version and write the new data back to \fBpackage.json\fR, \fBpackage-lock.json\fR, and, if present, \fBnpm-shrinkwrap.json\fR.
|
||||
.P
|
||||
The \fBnewversion\fR argument should be a valid semver string, a valid second argument to \fBsemver.inc\fR \fI\(lahttps://github.com/npm/node-semver#functions\(ra\fR (one of \fBpatch\fR, \fBminor\fR, \fBmajor\fR, \fBprepatch\fR, \fBpreminor\fR, \fBpremajor\fR, \fBprerelease\fR), or \fBfrom-git\fR. In the second case, the existing version will be incremented by 1 in the specified field. \fBfrom-git\fR will try to read the latest git tag, and use that as the new npm version.
|
||||
.P
|
||||
If run in a git repo, it will also create a version commit and tag. This behavior is controlled by \fBgit-tag-version\fR (see below), and can be disabled on the command line by running \fBnpm --no-git-tag-version version\fR. It will fail if the working directory is not clean, unless the \fB-f\fR or \fB--force\fR flag is set.
|
||||
.P
|
||||
If supplied with \fB-m\fR or \fB\fB--message\fR config\fR \fI\(la/using-npm/config#message\(ra\fR option, npm will use it as a commit message when creating a version commit. If the \fBmessage\fR config contains \fB%s\fR then that will be replaced with the resulting version number. For example:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm version patch -m "Upgrade to %s for reasons"
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
If the \fB\fBsign-git-tag\fR config\fR \fI\(la/using-npm/config#sign-git-tag\(ra\fR is set, then the tag will be signed using the \fB-s\fR 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:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ 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:
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
If \fBpreversion\fR, \fBversion\fR, or \fBpostversion\fR are in the \fBscripts\fR property of the package.json, they will be executed as part of running \fBnpm
|
||||
version\fR.
|
||||
.P
|
||||
The exact order of execution is as follows:
|
||||
.RS 0
|
||||
.IP 1. 4
|
||||
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 \fB--force\fR flag is set.
|
||||
.IP 2. 4
|
||||
Run the \fBpreversion\fR script. These scripts have access to the old \fBversion\fR 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 \fBgit add\fR.
|
||||
.IP 3. 4
|
||||
Bump \fBversion\fR in \fBpackage.json\fR as requested (\fBpatch\fR, \fBminor\fR, \fBmajor\fR, etc).
|
||||
.IP 4. 4
|
||||
Run the \fBversion\fR script. These scripts have access to the new \fBversion\fR 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 \fBgit add\fR.
|
||||
.IP 5. 4
|
||||
Commit and tag.
|
||||
.IP 6. 4
|
||||
Run the \fBpostversion\fR script. Use it to clean up the file system or automatically push the commit and/or tag.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Take the following example:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
{
|
||||
"scripts": {
|
||||
"preversion": "npm test",
|
||||
"version": "npm run build && git add -A dist",
|
||||
"postversion": "git push && git push --tags && rm -rf build/temp"
|
||||
}
|
||||
}
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
This runs all your tests and proceeds only if they pass. Then runs your \fBbuild\fR script, and adds everything in the \fBdist\fR directory to the commit. After the commit, it pushes the new commit and tag up to the server, and deletes the \fBbuild/temp\fR directory.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help init
|
||||
.IP \(bu 4
|
||||
npm help run-script
|
||||
.IP \(bu 4
|
||||
npm help scripts
|
||||
.IP \(bu 4
|
||||
\fBpackage.json\fR \fI\(la/configuring-npm/package-json\(ra\fR
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.RE 0
|
||||
213
Dependencies/NodeJS/node_modules/npm/man/man1/npm-view.1
generated
vendored
Normal file
213
Dependencies/NodeJS/node_modules/npm/man/man1/npm-view.1
generated
vendored
Normal file
@ -0,0 +1,213 @@
|
||||
.TH "NPM-VIEW" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-view\fR - View registry info
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm view \[lB]<package-spec>\[rB] \[lB]<field>\[lB].subfield\[rB]...\[rB]
|
||||
|
||||
aliases: info, show, v
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
This command shows data about a package and prints it to stdout.
|
||||
.P
|
||||
As an example, to view information about the \fBconnect\fR package from the registry, you would run:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm view connect
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
The default version is \fB"latest"\fR if unspecified.
|
||||
.P
|
||||
Field names can be specified after the package descriptor. For example, to show the dependencies of the \fBronn\fR package at version \fB0.3.5\fR, you could do the following:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm view ronn@0.3.5 dependencies
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
By default, \fBnpm view\fR shows data about the current project context (by looking for a \fBpackage.json\fR). To show field data for the current project use a file path (i.e. \fB.\fR):
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm view . dependencies
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
You can view child fields by separating them with a period. To view the git repository URL for the latest version of \fBnpm\fR, you would run the following command:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm view npm repository.url
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
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 \fBopts\fR that \fBronn\fR depends on, you could write the following:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm view opts@$(npm view ronn dependencies.opts)
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
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 email addresses for the \fBexpress\fR package, you would run:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm view express contributors.email
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
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 run:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm view express contributors\[lB]0\[rB].email
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
If the field value you are querying for is a property of an object, you should run:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm view express time'\[lB]4.8.0\[rB]'
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
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:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm view express contributors.name contributors.email
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
"Person" fields are shown as a string if they would be shown as an object. So, for example, this will show the list of \fBnpm\fR contributors in the shortened string format. (See \fB\fBpackage.json\fR\fR \fI\(la/configuring-npm/package-json\(ra\fR for more on this.)
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm view npm contributors
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
If a version range is provided, then data will be printed for every matching version of the package. This will show which version of \fBjsdom\fR was required by each matching version of \fByui3\fR:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm view yui3@'>0.5.4' dependencies.jsdom
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
To show the \fBconnect\fR package version history, you can do this:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm view connect versions
|
||||
.fi
|
||||
.RE
|
||||
.SS "Configuration"
|
||||
.SS "\fBjson\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Whether or not to output JSON data, rather than the normal output.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
In \fBnpm pkg set\fR it enables parsing set values with JSON.parse() before saving them to your \fBpackage.json\fR.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Not supported by all npm commands.
|
||||
.SS "\fBworkspace\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default:
|
||||
.IP \(bu 4
|
||||
Type: String (can be set multiple times)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option.
|
||||
.P
|
||||
Valid values for the \fBworkspace\fR config are either:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Workspace names
|
||||
.IP \(bu 4
|
||||
Path to a workspace directory
|
||||
.IP \(bu 4
|
||||
Path to a parent workspace directory (will result in selecting all workspaces within that folder)
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
When set for the \fBnpm init\fR command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBworkspaces\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: null
|
||||
.IP \(bu 4
|
||||
Type: null or Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Set to true to run the command in the context of \fBall\fR configured workspaces.
|
||||
.P
|
||||
Explicitly setting this to false will cause commands like \fBinstall\fR to ignore workspaces altogether. When not set explicitly:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Commands that operate on the \fBnode_modules\fR tree (install, update, etc.) will link workspaces into the \fBnode_modules\fR folder. - Commands that do other things (test, exec, publish, etc.) will operate on the root project, \fIunless\fR one or more workspaces are specified in the \fBworkspace\fR config.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "\fBinclude-workspace-root\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: false
|
||||
.IP \(bu 4
|
||||
Type: Boolean
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Include the workspace root when workspaces are enabled for a command.
|
||||
.P
|
||||
When false, specifying individual workspaces via the \fBworkspace\fR config, or all workspaces via the \fBworkspaces\fR flag, will cause npm to operate only on the specified workspaces, and not on the root project.
|
||||
.P
|
||||
This value is not exported to the environment for child processes.
|
||||
.SS "Output"
|
||||
.P
|
||||
If only a single string field for a single version is output, then it will not be colorized or quoted, to enable piping the output to another command. If the field is an object, it will be output as a JavaScript object literal.
|
||||
.P
|
||||
If the \fB--json\fR flag is given, the outputted fields will be JSON.
|
||||
.P
|
||||
If the version range matches multiple versions then each printed value will be prefixed with the version it applies to.
|
||||
.P
|
||||
If multiple fields are requested, then each of them is prefixed with the field name.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help "package spec"
|
||||
.IP \(bu 4
|
||||
npm help search
|
||||
.IP \(bu 4
|
||||
npm help registry
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help npmrc
|
||||
.IP \(bu 4
|
||||
npm help docs
|
||||
.RE 0
|
||||
39
Dependencies/NodeJS/node_modules/npm/man/man1/npm-whoami.1
generated
vendored
Normal file
39
Dependencies/NodeJS/node_modules/npm/man/man1/npm-whoami.1
generated
vendored
Normal file
@ -0,0 +1,39 @@
|
||||
.TH "NPM-WHOAMI" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm-whoami\fR - Display npm username
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm whoami
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Description"
|
||||
.P
|
||||
Display the npm username of the currently logged-in user.
|
||||
.P
|
||||
If logged into a registry that provides token-based authentication, then connect to the \fB/-/whoami\fR registry endpoint to find the username associated with the token, and print to standard output.
|
||||
.P
|
||||
If logged into a registry that uses Basic Auth, then simply print the \fBusername\fR portion of the authentication string.
|
||||
.SS "Configuration"
|
||||
.SS "\fBregistry\fR"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Default: "https://registry.npmjs.org/"
|
||||
.IP \(bu 4
|
||||
Type: URL
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
The base URL of the npm registry.
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help npmrc
|
||||
.IP \(bu 4
|
||||
npm help adduser
|
||||
.RE 0
|
||||
131
Dependencies/NodeJS/node_modules/npm/man/man1/npm.1
generated
vendored
Normal file
131
Dependencies/NodeJS/node_modules/npm/man/man1/npm.1
generated
vendored
Normal file
@ -0,0 +1,131 @@
|
||||
.TH "NPM" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpm\fR - javascript package manager
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npm
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Note: This command is unaware of workspaces.
|
||||
.SS "Version"
|
||||
.P
|
||||
10.9.2
|
||||
.SS "Description"
|
||||
.P
|
||||
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.
|
||||
.P
|
||||
It is extremely configurable to support a variety of use cases. Most commonly, you use it to publish, discover, install, and develop node programs.
|
||||
.P
|
||||
Run \fBnpm help\fR to get a list of available commands.
|
||||
.SS "Important"
|
||||
.P
|
||||
npm comes preconfigured to use npm'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://docs.npmjs.com/policies/terms.
|
||||
.P
|
||||
You can configure npm to use any compatible registry you like, and even run your own registry. Use of someone else's registry is governed by their terms of use.
|
||||
.SS "Introduction"
|
||||
.P
|
||||
You probably got npm because you want to install stuff.
|
||||
.P
|
||||
The very first thing you will most likely want to run in any node program is \fBnpm install\fR to install its dependencies.
|
||||
.P
|
||||
You can also run \fBnpm install blerg\fR to install the latest version of "blerg". Check out npm help install for more info. It can do a lot of stuff.
|
||||
.P
|
||||
Use the \fBnpm search\fR command to show everything that's available in the public registry. Use \fBnpm ls\fR to show everything you've installed.
|
||||
.SS "Dependencies"
|
||||
.P
|
||||
If a package lists a dependency using a git URL, npm will install that dependency using the \fB\fBgit\fR\fR \fI\(lahttps://github.com/git-guides/install-git\(ra\fR command and will generate an error if it is not installed.
|
||||
.P
|
||||
If one of the packages npm tries to install is a native node module and requires compiling of C++ Code, npm will use \fBnode-gyp\fR \fI\(lahttps://github.com/nodejs/node-gyp\(ra\fR for that task. For a Unix system, \fBnode-gyp\fR \fI\(lahttps://github.com/nodejs/node-gyp\(ra\fR needs Python, make and a buildchain like GCC. On Windows, Python and Microsoft Visual Studio C++ are needed. For more information visit \fBthe node-gyp repository\fR \fI\(lahttps://github.com/nodejs/node-gyp\(ra\fR and the \fBnode-gyp Wiki\fR \fI\(lahttps://github.com/nodejs/node-gyp/wiki\(ra\fR.
|
||||
.SS "Directories"
|
||||
.P
|
||||
See npm help folders to learn about where npm puts stuff.
|
||||
.P
|
||||
In particular, npm has two modes of operation:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
local mode: npm installs packages into the current project directory, which defaults to the current working directory. Packages install to \fB./node_modules\fR, and bins to \fB./node_modules/.bin\fR.
|
||||
.IP \(bu 4
|
||||
global mode: npm installs packages into the install prefix at \fB$npm_config_prefix/lib/node_modules\fR and bins to \fB$npm_config_prefix/bin\fR.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Local mode is the default. Use \fB-g\fR or \fB--global\fR on any command to run in global mode instead.
|
||||
.SS "Developer Usage"
|
||||
.P
|
||||
If you're using npm to develop and publish your code, check out the following help topics:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
json: Make a package.json file. See \fB\fBpackage.json\fR\fR \fI\(la/configuring-npm/package-json\(ra\fR.
|
||||
.IP \(bu 4
|
||||
link: Links your current working code into Node's path, so that you don't have to reinstall every time you make a change. Use npm help link to do this.
|
||||
.IP \(bu 4
|
||||
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 help install
|
||||
.IP \(bu 4
|
||||
adduser: Create an account or log in. When you do this, npm will store credentials in the user config file.
|
||||
.IP \(bu 4
|
||||
publish: Use the npm help publish command to upload your code to the registry.
|
||||
.RE 0
|
||||
|
||||
.SS "Configuration"
|
||||
.P
|
||||
npm is extremely configurable. It reads its configuration options from 5 places.
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Command line switches: Set a config with \fB--key val\fR. 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 you do not provide a value (\fB--key\fR) then the option is set to boolean \fBtrue\fR.
|
||||
.IP \(bu 4
|
||||
Environment Variables: Set any config by prefixing the name in an environment variable with \fBnpm_config_\fR. For example, \fBexport npm_config_key=val\fR.
|
||||
.IP \(bu 4
|
||||
User Configs: The file at \fB$HOME/.npmrc\fR is an ini-formatted list of configs. If present, it is parsed. If the \fBuserconfig\fR option is set in the cli or env, that file will be used instead.
|
||||
.IP \(bu 4
|
||||
Global Configs: The file found at \fB./etc/npmrc\fR (relative to the global prefix will be parsed if it is found. See npm help prefix for more info on the global prefix. If the \fBglobalconfig\fR option is set in the cli, env, or user config, then that file is parsed instead.
|
||||
.IP \(bu 4
|
||||
Defaults: npm's default configuration options are defined in \fBlib/utils/config/definitions.js\fR. These must not be changed.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
See npm help config for much much more information.
|
||||
.SS "Contributions"
|
||||
.P
|
||||
Patches welcome!
|
||||
.P
|
||||
If you would like to help, but don't know what to work on, read the \fBcontributing guidelines\fR \fI\(lahttps://github.com/npm/cli/blob/latest/CONTRIBUTING.md\(ra\fR and check the issues list.
|
||||
.SS "Bugs"
|
||||
.P
|
||||
When you find issues, please report them: \fI\(lahttps://github.com/npm/cli/issues\(ra\fR
|
||||
.P
|
||||
Please be sure to follow the template and bug reporting guidelines.
|
||||
.SS "Feature Requests"
|
||||
.P
|
||||
Discuss new feature ideas on our discussion forum:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
\fI\(lahttps://github.com/orgs/community/discussions/categories/npm\(ra\fR
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
Or suggest formal RFC proposals:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
\fI\(lahttps://github.com/npm/rfcs\(ra\fR
|
||||
.RE 0
|
||||
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help help
|
||||
.IP \(bu 4
|
||||
\fBpackage.json\fR \fI\(la/configuring-npm/package-json\(ra\fR
|
||||
.IP \(bu 4
|
||||
npm help npmrc
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help install
|
||||
.IP \(bu 4
|
||||
npm help prefix
|
||||
.IP \(bu 4
|
||||
npm help publish
|
||||
.RE 0
|
||||
156
Dependencies/NodeJS/node_modules/npm/man/man1/npx.1
generated
vendored
Normal file
156
Dependencies/NodeJS/node_modules/npm/man/man1/npx.1
generated
vendored
Normal file
@ -0,0 +1,156 @@
|
||||
.TH "NPX" "1" "December 2024" "NPM@10.9.2" ""
|
||||
.SH "NAME"
|
||||
\fBnpx\fR - Run a command from a local or remote npm package
|
||||
.SS "Synopsis"
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
npx -- <pkg>\[lB]@<version>\[rB] \[lB]args...\[rB]
|
||||
npx --package=<pkg>\[lB]@<version>\[rB] -- <cmd> \[lB]args...\[rB]
|
||||
npx -c '<cmd> \[lB]args...\[rB]'
|
||||
npx --package=foo -c '<cmd> \[lB]args...\[rB]'
|
||||
.fi
|
||||
.RE
|
||||
.SS "Description"
|
||||
.P
|
||||
This command allows you to run an arbitrary command from an npm package (either one installed locally, or fetched remotely), in a similar context as running it via \fBnpm run\fR.
|
||||
.P
|
||||
Whatever packages are specified by the \fB--package\fR option will be provided in the \fBPATH\fR of the executed command, along with any locally installed package executables. The \fB--package\fR option may be specified multiple times, to execute the supplied command in an environment where all specified packages are available.
|
||||
.P
|
||||
If any requested packages are not present in the local project dependencies, then they are installed to a folder in the npm cache, which is added to the \fBPATH\fR environment variable in the executed process. A prompt is printed (which can be suppressed by providing either \fB--yes\fR or \fB--no\fR).
|
||||
.P
|
||||
Package names provided without a specifier will be matched with whatever version exists in the local project. Package names with a specifier will only be considered a match if they have the exact same name and version as the local dependency.
|
||||
.P
|
||||
If no \fB-c\fR or \fB--call\fR option is provided, then the positional arguments are used to generate the command string. If no \fB--package\fR options are provided, then npm will attempt to determine the executable name from the package specifier provided as the first positional argument according to the following heuristic:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
If the package has a single entry in its \fBbin\fR field in \fBpackage.json\fR, or if all entries are aliases of the same command, then that command will be used.
|
||||
.IP \(bu 4
|
||||
If the package has multiple \fBbin\fR entries, and one of them matches the unscoped portion of the \fBname\fR field, then that command will be used.
|
||||
.IP \(bu 4
|
||||
If this does not result in exactly one option (either because there are no bin entries, or none of them match the \fBname\fR of the package), then \fBnpm exec\fR exits with an error.
|
||||
.RE 0
|
||||
|
||||
.P
|
||||
To run a binary \fIother than\fR the named binary, specify one or more \fB--package\fR options, which will prevent npm from inferring the package from the first command argument.
|
||||
.SS "\fBnpx\fR vs \fBnpm exec\fR"
|
||||
.P
|
||||
When run via the \fBnpx\fR binary, all flags and options \fImust\fR be set prior to any positional arguments. When run via \fBnpm exec\fR, a double-hyphen \fB--\fR flag can be used to suppress npm's parsing of switches and options that should be sent to the executed command.
|
||||
.P
|
||||
For example:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npx foo@latest bar --package=@npmcli/foo
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
In this case, npm will resolve the \fBfoo\fR package name, and run the following command:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ foo bar --package=@npmcli/foo
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Since the \fB--package\fR option comes \fIafter\fR the positional arguments, it is treated as an argument to the executed command.
|
||||
.P
|
||||
In contrast, due to npm's argument parsing logic, running this command is different:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm exec foo@latest bar --package=@npmcli/foo
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
In this case, npm will parse the \fB--package\fR option first, resolving the \fB@npmcli/foo\fR package. Then, it will execute the following command in that context:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ foo@latest bar
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
The double-hyphen character is recommended to explicitly tell npm to stop parsing command line options and switches. The following command would thus be equivalent to the \fBnpx\fR command above:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm exec -- foo@latest bar --package=@npmcli/foo
|
||||
.fi
|
||||
.RE
|
||||
.SS "Examples"
|
||||
.P
|
||||
Run the version of \fBtap\fR in the local dependencies, with the provided arguments:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm exec -- tap --bail test/foo.js
|
||||
$ npx tap --bail test/foo.js
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Run a command \fIother than\fR the command whose name matches the package name by specifying a \fB--package\fR option:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm exec --package=foo -- bar --bar-argument
|
||||
# ~ or ~
|
||||
$ npx --package=foo bar --bar-argument
|
||||
.fi
|
||||
.RE
|
||||
.P
|
||||
Run an arbitrary shell script, in the context of the current project:
|
||||
.P
|
||||
.RS 2
|
||||
.nf
|
||||
$ npm x -c 'eslint && say "hooray, lint passed"'
|
||||
$ npx -c 'eslint && say "hooray, lint passed"'
|
||||
.fi
|
||||
.RE
|
||||
.SS "Compatibility with Older npx Versions"
|
||||
.P
|
||||
The \fBnpx\fR binary was rewritten in npm v7.0.0, and the standalone \fBnpx\fR package deprecated at that time. \fBnpx\fR uses the \fBnpm exec\fR command instead of a separate argument parser and install process, with some affordances to maintain backwards compatibility with the arguments it accepted in previous versions.
|
||||
.P
|
||||
This resulted in some shifts in its functionality:
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
Any \fBnpm\fR config value may be provided.
|
||||
.IP \(bu 4
|
||||
To prevent security and user-experience problems from mistyping package names, \fBnpx\fR prompts before installing anything. Suppress this prompt with the \fB-y\fR or \fB--yes\fR option.
|
||||
.IP \(bu 4
|
||||
The \fB--no-install\fR option is deprecated, and will be converted to \fB--no\fR.
|
||||
.IP \(bu 4
|
||||
Shell fallback functionality is removed, as it is not advisable.
|
||||
.IP \(bu 4
|
||||
The \fB-p\fR argument is a shorthand for \fB--parseable\fR in npm, but shorthand for \fB--package\fR in npx. This is maintained, but only for the \fBnpx\fR executable.
|
||||
.IP \(bu 4
|
||||
The \fB--ignore-existing\fR option is removed. Locally installed bins are always present in the executed process \fBPATH\fR.
|
||||
.IP \(bu 4
|
||||
The \fB--npm\fR option is removed. \fBnpx\fR will always use the \fBnpm\fR it ships with.
|
||||
.IP \(bu 4
|
||||
The \fB--node-arg\fR and \fB-n\fR options have been removed. Use \fB\fBNODE_OPTIONS\fR\fR \fI\(lahttps://nodejs.org/api/cli.html#node_optionsoptions\(ra\fR instead: e.g., \fBNODE_OPTIONS="--trace-warnings --trace-exit" npx foo --random=true\fR
|
||||
.IP \(bu 4
|
||||
The \fB--always-spawn\fR option is redundant, and thus removed.
|
||||
.IP \(bu 4
|
||||
The \fB--shell\fR option is replaced with \fB--script-shell\fR, but maintained in the \fBnpx\fR executable for backwards compatibility.
|
||||
.RE 0
|
||||
|
||||
.SS "See Also"
|
||||
.RS 0
|
||||
.IP \(bu 4
|
||||
npm help run-script
|
||||
.IP \(bu 4
|
||||
npm help scripts
|
||||
.IP \(bu 4
|
||||
npm help test
|
||||
.IP \(bu 4
|
||||
npm help start
|
||||
.IP \(bu 4
|
||||
npm help restart
|
||||
.IP \(bu 4
|
||||
npm help stop
|
||||
.IP \(bu 4
|
||||
npm help config
|
||||
.IP \(bu 4
|
||||
npm help exec
|
||||
.RE 0
|
||||
Reference in New Issue
Block a user