BackPup/node
1
0 Fork 0
mirror of https://github.com/nodejs/node.git synced 2026-10-14 10:26:26 -04:00
Code Issues Packages Projects Releases Wiki Activity

deps: update npm to 6.13.0

Browse Source 
PR-URL: https://github.com/nodejs/node/pull/30271
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
This commit is contained in:
Ruy Adorno authored and Rich Trott committed 2019-11-09 20:13:43 -08:00
1 parent 5f9794ea9a
commit 4b97c3addb
464 files changed
+36358 -19804
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

deps/npm/.eslintrc
Vendored
+3
View File
@@ -0,0 +1,3 @@
{
"extends": "standard"
}
deps/npm/AUTHORS
Vendored
+4
View File
@@ -663,3 +663,7 @@ Christian Clauss <cclauss@me.com>
Nikita Lebedev <bloomber111@gmail.com>
Henrik Gemal <henrik@gemal.dk>
Philip Harrison <philip@mailharrison.com>
Jason Etcovitch <jasonetco@github.com>
Darcy Clarke <darcy@darcyclarke.me>
orion <oletizi@mac.com>
NoDocCat <nodoccat@outlook.com>
deps/npm/CHANGELOG.md
Vendored
+49
View File
@@ -1,3 +1,52 @@
## 6.13.0 (2019-11-05)
### NEW FEATURES
* [`4414b06d9`](https://github.com/npm/cli/commit/4414b06d944c56bee05ccfb85260055a767ee334)
[#273](https://github.com/npm/cli/pull/273)
add fund command
([@ruyadorno](https://github.com/ruyadorno))
### DOCUMENTATION
* [`ae4c74d04`](https://github.com/npm/cli/commit/ae4c74d04f820a0255a92bdfe77ecf97af134fae)
[#274](https://github.com/npm/cli/pull/274)
migrate existing docs to gatsby
([@claudiahdz](https://github.com/claudiahdz))
* [`4ff1bb180`](https://github.com/npm/cli/commit/4ff1bb180b1db8c72e51b3d57bd4e268b738e049)
[#277](https://github.com/npm/cli/pull/277)
updated documentation copy
([@oletizi](https://github.com/oletizi))
### BUG FIXES
* [`e4455409f`](https://github.com/npm/cli/commit/e4455409fe6fe9c198b250b488129171f0b4624a)
[#281](https://github.com/npm/cli/pull/281)
delete ps1 files on package removal
([@NoDocCat](https://github.com/NoDocCat))
* [`cd14d4701`](https://github.com/npm/cli/commit/cd14d47014e8c96ffd6a18791e8752028b19d637)
[#279](https://github.com/npm/cli/pull/279)
update supported node list to remove v6.0, v6.1, v9.0 - v9.2
([@ljharb](https://github.com/ljharb))
### DEPENDENCIES
* [`a37296b20`](https://github.com/npm/cli/commit/a37296b20ca3e19c2bbfa78fedcfe695e03fda69)
`pacote@9.5.9`
* [`d3cb3abe8`](https://github.com/npm/cli/commit/d3cb3abe8cee54bd2624acdcf8043932ef0d660a)
`read-cmd-shim@1.0.5`
### TESTING
* [`688cd97be`](https://github.com/npm/cli/commit/688cd97be94ca949719424ff69ff515a68c5caba)
[#272](https://github.com/npm/cli/pull/272)
use github actions for CI
([@JasonEtco](https://github.com/JasonEtco))
* [`9a2d8af84`](https://github.com/npm/cli/commit/9a2d8af84f7328f13d8f578cf4b150b9d5f09517)
[#240](https://github.com/npm/cli/pull/240)
Clean up some flakiness and inconsistency
([@isaacs](https://github.com/isaacs))
## 6.12.1 (2019-10-29)
### BUG FIXES
deps/npm/Makefile
Vendored
+36 -87
View File
@@ -4,51 +4,25 @@ SHELL = bash
PUBLISHTAG = $(shell node scripts/publish-tag.js)
BRANCH = $(shell git rev-parse --abbrev-ref HEAD)
markdowns = $(shell find doc -name '*.md' | grep -v 'index') README.md
markdowns = $(shell find docs -name '*.md' | grep -v 'index') README.md
html_docdeps = html/dochead.html \
html/docfoot.html \
scripts/doc-build.sh \
package.json
cli_mandocs = $(shell find doc/cli -name '*.md' \
cli_mandocs = $(shell find docs/content/cli-commands -name '*.md' \
|sed 's|.md|.1|g' \
|sed 's|doc/cli/|man/man1/|g' ) \
|sed 's|docs/content/cli-commands/|man/man1/|g' ) \
man/man1/npm-README.1 \
man/man1/npx.1
files_mandocs = $(shell find doc/files -name '*.md' \
files_mandocs = $(shell find docs/content/configuring-npm -name '*.md' \
|sed 's|.md|.5|g' \
|sed 's|doc/files/|man/man5/|g' ) \
man/man5/npm-json.5 \
man/man5/npm-global.5
|sed 's|docs/content/configuring-npm/|man/man5/|g' ) \
misc_mandocs = $(shell find doc/misc -name '*.md' \
misc_mandocs = $(shell find docs/content/using-npm -name '*.md' \
|sed 's|.md|.7|g' \
|sed 's|doc/misc/|man/man7/|g' ) \
man/man7/npm-index.7
cli_htmldocs = $(shell find doc/cli -name '*.md' \
|sed 's|.md|.html|g' \
|sed 's|doc/cli/|html/doc/cli/|g' ) \
html/doc/README.html
files_htmldocs = $(shell find doc/files -name '*.md' \
|sed 's|.md|.html|g' \
|sed 's|doc/files/|html/doc/files/|g' ) \
html/doc/files/npm-json.html \
html/doc/files/npm-global.html
misc_htmldocs = $(shell find doc/misc -name '*.md' \
|sed 's|.md|.html|g' \
|sed 's|doc/misc/|html/doc/misc/|g' ) \
html/doc/index.html
|sed 's|docs/content/using-npm/|man/man7/|g' ) \
mandocs = $(cli_mandocs) $(files_mandocs) $(misc_mandocs)
htmldocs = $(cli_htmldocs) $(files_htmldocs) $(misc_htmldocs)
all: doc
all: docs
latest:
@echo "Installing latest published npm"
@@ -65,14 +39,21 @@ dev: install
link: uninstall
node bin/npm-cli.js link -f
clean: markedclean marked-manclean doc-clean
clean: markedclean marked-manclean docs-clean
rm -rf npmrc
node bin/npm-cli.js cache clean --force
uninstall:
node bin/npm-cli.js rm npm -g -f
doc: $(mandocs) $(htmldocs)
mandocs: $(mandocs)
htmldocs:
cd docs && node ../bin/npm-cli.js install && \
node ../bin/npm-cli.js run build:static echo>&2 && \
rm -rf node_modules .cache public/*js public/*json public/404* public/page-data public/manifest*
docs: mandocs htmldocs
markedclean:
rm -rf node_modules/marked node_modules/.bin/marked .building_marked
@@ -80,26 +61,28 @@ markedclean:
marked-manclean:
rm -rf node_modules/marked-man node_modules/.bin/marked-man .building_marked-man
docclean: doc-clean
doc-clean:
docsclean: docs-clean
docs-clean:
rm -rf \
.building_marked \
.building_marked-man \
html/doc \
man
man \
docs/node_modules \
docs/public \
docs/.cache
## build-time tools for the documentation
build-doc-tools := node_modules/.bin/marked \
node_modules/.bin/marked-man
# use `npm install marked-man` for this to work.
man/man1/npm-README.1: README.md scripts/doc-build.sh package.json $(build-doc-tools)
man/man1/npm-README.1: README.md scripts/docs-build.js package.json $(build-doc-tools)
@[ -d man/man1 ] || mkdir -p man/man1
scripts/doc-build.sh $< $@
node scripts/docs-build.js $< $@
man/man1/%.1: doc/cli/%.md scripts/doc-build.sh package.json $(build-doc-tools)
man/man1/%.1: docs/content/cli-commands/%.md scripts/docs-build.js package.json $(build-doc-tools)
@[ -d man/man1 ] || mkdir -p man/man1
scripts/doc-build.sh $< $@
node scripts/docs-build.js $< $@
man/man1/npx.1: node_modules/libnpx/libnpx.1
cat $< | sed s/libnpx/npx/ > $@
@@ -107,46 +90,16 @@ man/man1/npx.1: node_modules/libnpx/libnpx.1
man/man5/npm-json.5: man/man5/package.json.5
cp $< $@
man/man5/npm-global.5: man/man5/npm-folders.5
man/man5/npm-global.5: man/man5/folders.5
cp $< $@
man/man5/%.5: doc/files/%.md scripts/doc-build.sh package.json $(build-doc-tools)
man/man5/%.5: docs/content/configuring-npm/%.md scripts/docs-build.js package.json $(build-doc-tools)
@[ -d man/man5 ] || mkdir -p man/man5
scripts/doc-build.sh $< $@
node scripts/docs-build.js $< $@
doc/misc/npm-index.md: scripts/index-build.js package.json $(build-doc-tools)
node scripts/index-build.js > $@
html/doc/index.html: doc/misc/npm-index.md $(html_docdeps) $(build-doc-tools)
@[ -d html/doc ] || mkdir -p html/doc
scripts/doc-build.sh $< $@
man/man7/%.7: doc/misc/%.md scripts/doc-build.sh package.json $(build-doc-tools)
man/man7/%.7: docs/content/using-npm/%.md scripts/docs-build.js package.json $(build-doc-tools)
@[ -d man/man7 ] || mkdir -p man/man7
scripts/doc-build.sh $< $@
html/doc/README.html: README.md $(html_docdeps) $(build-doc-tools)
@[ -d html/doc ] || mkdir -p html/doc
scripts/doc-build.sh $< $@
html/doc/cli/%.html: doc/cli/%.md $(html_docdeps) $(build-doc-tools)
@[ -d html/doc/cli ] || mkdir -p html/doc/cli
scripts/doc-build.sh $< $@
html/doc/files/npm-json.html: html/doc/files/package.json.html
cp $< $@
html/doc/files/npm-global.html: html/doc/files/npm-folders.html
cp $< $@
html/doc/files/%.html: doc/files/%.md $(html_docdeps) $(build-doc-tools)
@[ -d html/doc/files ] || mkdir -p html/doc/files
scripts/doc-build.sh $< $@
html/doc/misc/%.html: doc/misc/%.md $(html_docdeps) $(build-doc-tools)
@[ -d html/doc/misc ] || mkdir -p html/doc/misc
scripts/doc-build.sh $< $@
node scripts/docs-build.js $< $@
marked: node_modules/.bin/marked
@@ -158,11 +111,7 @@ marked-man: node_modules/.bin/marked-man
node_modules/.bin/marked-man:
node bin/npm-cli.js install marked-man --no-global --no-timing --no-save
doc: man
man: $(cli_docs)
test: doc
test: docs
node bin/npm-cli.js test
tag:
@@ -174,17 +123,17 @@ ls-ok:
gitclean:
git clean -fd
publish: gitclean ls-ok link doc-clean doc
publish: gitclean ls-ok link docs-clean docs
@git push origin :v$(shell node bin/npm-cli.js --no-timing -v) 2>&1 || true
git push origin $(BRANCH) &&\
git push origin --tags &&\
node bin/npm-cli.js publish --tag=$(PUBLISHTAG)
release: gitclean ls-ok markedclean marked-manclean doc-clean doc
release: gitclean ls-ok markedclean marked-manclean docs-clean doc
node bin/npm-cli.js prune --production --no-save
@bash scripts/release.sh
sandwich:
@[ $$(whoami) = "root" ] && (echo "ok"; echo "ham" > sandwich) || (echo "make it yourself" && exit 13)
.PHONY: all latest install dev link doc clean uninstall test man doc-clean docclean release ls-ok realclean
.PHONY: all latest install dev link doc clean uninstall test man docs-clean docclean release ls-ok realclean
deps/npm/README.md
Vendored
-1
View File
@@ -163,4 +163,3 @@ doubt tell you to put the output in a gist or email.
* npm(1)
* npm-help(1)
* npm-index(7)
deps/npm/doc/cli/npm-bin.md
Vendored
-19
View File
@@ -1,19 +0,0 @@
npm-bin(1) -- Display npm bin folder
====================================
## SYNOPSIS
npm bin [-g|--global]
## DESCRIPTION
Print the folder where npm will install executables.
## SEE ALSO
* npm-prefix(1)
* npm-root(1)
* npm-folders(5)
* npm-config(1)
* npm-config(7)
* npmrc(5)
deps/npm/doc/cli/npm-bugs.md
Vendored
-43
View File
@@ -1,43 +0,0 @@
npm-bugs(1) -- Bugs for a package in a web browser maybe
========================================================
## SYNOPSIS
npm bugs [<pkgname>]
aliases: issues
## DESCRIPTION
This command tries to guess at the likely location of a package's
bug tracker URL, and then tries to open it using the `--browser`
config param. If no package name is provided, it will search for
a `package.json` in the current folder and use the `name` property.
## CONFIGURATION
### browser
* Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
* Type: String
The browser that is called by the `npm bugs` command to open websites.
### registry
* Default: https://registry.npmjs.org/
* Type: url
The base URL of the npm package registry.
## SEE ALSO
* npm-docs(1)
* npm-view(1)
* npm-publish(1)
* npm-registry(7)
* npm-config(1)
* npm-config(7)
* npmrc(5)
* package.json(5)
deps/npm/doc/cli/npm-build.md
Vendored
-25
View File
@@ -1,25 +0,0 @@
npm-build(1) -- Build a package
===============================
## SYNOPSIS
npm build [<package-folder>]
* `<package-folder>`:
A folder containing a `package.json` file in its root.
## DESCRIPTION
This is the plumbing command called by `npm link` and `npm install`.
It should generally be called during installation, but if you need to run it
directly, run:
npm run-script build
## SEE ALSO
* npm-install(1)
* npm-link(1)
* npm-scripts(7)
* package.json(5)
deps/npm/doc/cli/npm-config.md
Vendored
-73
View File
@@ -1,73 +0,0 @@
npm-config(1) -- Manage the npm configuration files
===================================================
## SYNOPSIS
npm config set <key> <value> [-g|--global]
npm config get <key>
npm config delete <key>
npm config list [-l] [--json]
npm config edit
npm get <key>
npm set <key> <value> [-g|--global]
aliases: c
## DESCRIPTION
npm gets its config settings from the command line, environment
variables, `npmrc` files, and in some cases, the `package.json` file.
See npmrc(5) for more information about the npmrc files.
See `npm-config(7)` for a more thorough discussion of the mechanisms
involved.
The `npm config` command can be used to update and edit the contents
of the user and global npmrc files.
## Sub-commands
Config supports the following sub-commands:
### set
npm config set key value
Sets the config key to the value.
If value is omitted, then it sets it to "true".
### get
npm config get key
Echo the config value to stdout.
### list
npm config list
Show all the config settings. Use `-l` to also show defaults. Use `--json`
to show the settings in json format.
### delete
npm config delete key
Deletes the key from all configuration files.
### edit
npm config edit
Opens the config file in an editor. Use the `--global` flag to edit the
global config.
## SEE ALSO
* npm-folders(5)
* npm-config(7)
* package.json(5)
* npmrc(5)
* npm(1)
deps/npm/doc/cli/npm-docs.md
Vendored
-44
View File
@@ -1,44 +0,0 @@
npm-docs(1) -- Docs for a package in a web browser maybe
========================================================
## SYNOPSIS
npm docs [<pkgname> [<pkgname> ...]]
npm docs .
npm home [<pkgname> [<pkgname> ...]]
npm home .
## DESCRIPTION
This command tries to guess at the likely location of a package's
documentation URL, and then tries to open it using the `--browser`
config param. You can pass multiple package names at once. If no
package name is provided, it will search for a `package.json` in
the current folder and use the `name` property.
## CONFIGURATION
### browser
* Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
* Type: String
The browser that is called by the `npm docs` command to open websites.
### registry
* Default: https://registry.npmjs.org/
* Type: url
The base URL of the npm package registry.
## SEE ALSO
* npm-view(1)
* npm-publish(1)
* npm-registry(7)
* npm-config(1)
* npm-config(7)
* npmrc(5)
* package.json(5)
deps/npm/doc/cli/npm-explore.md
Vendored
-39
View File
@@ -1,39 +0,0 @@
npm-explore(1) -- Browse an installed package
=============================================
## SYNOPSIS
npm explore <pkg> [ -- <command>]
## DESCRIPTION
Spawn a subshell in the directory of the installed package specified.
If a command is specified, then it is run in the subshell, which then
immediately terminates.
This is particularly handy in the case of git submodules in the
`node_modules` folder:
npm explore some-dependency -- git pull origin master
Note that the package is *not* automatically rebuilt afterwards, so be
sure to use `npm rebuild <pkg>` if you make any changes.
## CONFIGURATION
### shell
* Default: SHELL environment variable, or "bash" on Posix, or "cmd" on
Windows
* Type: path
The shell to run for the `npm explore` command.
## SEE ALSO
* npm-folders(5)
* npm-edit(1)
* npm-rebuild(1)
* npm-build(1)
* npm-install(1)
deps/npm/doc/cli/npm-install-ci-test.md
Vendored
-16
View File
@@ -1,16 +0,0 @@
# npm install-ci-test(1) -- Install a project with a clean slate and run tests
## SYNOPSIS
npm install-ci-test
alias: npm cit
## DESCRIPTION
This command runs an `npm ci` followed immediately by an `npm test`.
## SEE ALSO
- npm-ci(1)
- npm-test(1)
deps/npm/doc/cli/npm-install-test.md
Vendored
-25
View File
@@ -1,25 +0,0 @@
# npm install-test(1) -- Install package(s) and run tests
## SYNOPSIS
npm install-test (with no args, in package dir)
npm install-test [<@scope>/]<name>
npm install-test [<@scope>/]<name>@<tag>
npm install-test [<@scope>/]<name>@<version>
npm install-test [<@scope>/]<name>@<version range>
npm install-test <tarball file>
npm install-test <tarball url>
npm install-test <folder>
alias: npm it
common options: [--save|--save-dev|--save-optional] [--save-exact] [--dry-run]
## DESCRIPTION
This command runs an `npm install` followed immediately by an `npm test`. It
takes exactly the same arguments as `npm install`.
## SEE ALSO
- npm-install(1)
- npm-test(1)
deps/npm/doc/cli/npm-ping.md
Vendored
-24
View File
@@ -1,24 +0,0 @@
npm-ping(1) -- Ping npm registry
================================
## SYNOPSIS
npm ping [--registry <registry>]
## DESCRIPTION
Ping the configured or given npm registry and verify authentication.
If it works it will output something like:
```
Ping success: {*Details about registry*}
```
otherwise you will get:
```
Ping error: {*Detail about error}
```
## SEE ALSO
* npm-config(1)
* npm-config(7)
* npmrc(5)
deps/npm/doc/cli/npm-prefix.md
Vendored
-24
View File
@@ -1,24 +0,0 @@
npm-prefix(1) -- Display prefix
===============================
## SYNOPSIS
npm prefix [-g]
## DESCRIPTION
Print the local prefix to standard out. This is the closest parent directory
to contain a `package.json` file or `node_modules` directory, unless `-g` is
also specified.
If `-g` is specified, this will be the value of the global prefix. See
`npm-config(7)` for more detail.
## SEE ALSO
* npm-root(1)
* npm-bin(1)
* npm-folders(5)
* npm-config(1)
* npm-config(7)
* npmrc(5)
deps/npm/doc/cli/npm-rebuild.md
Vendored
-19
View File
@@ -1,19 +0,0 @@
npm-rebuild(1) -- Rebuild a package
===================================
## SYNOPSIS
npm rebuild [[<@scope>/<name>]...]
alias: npm rb
## DESCRIPTION
This command runs the `npm build` command on the matched folders. This is useful
when you install a new version of node, and must recompile all your C++ addons with
the new binary.
## SEE ALSO
* npm-build(1)
* npm-install(1)
deps/npm/doc/cli/npm-root.md
Vendored
-19
View File
@@ -1,19 +0,0 @@
npm-root(1) -- Display npm root
===============================
## SYNOPSIS
npm root [-g]
## DESCRIPTION
Print the effective `node_modules` folder to standard out.
## SEE ALSO
* npm-prefix(1)
* npm-bin(1)
* npm-folders(5)
* npm-config(1)
* npm-config(7)
* npmrc(5)
deps/npm/doc/cli/npm-shrinkwrap.md
Vendored
-25
View File
@@ -1,25 +0,0 @@
npm-shrinkwrap(1) -- Lock down dependency versions for publication
=====================================================
## SYNOPSIS
npm shrinkwrap
## DESCRIPTION
This command repurposes `package-lock.json` into a publishable
`npm-shrinkwrap.json` or simply creates a new one. The file created and updated
by this command will then take precedence over any other existing or future
`package-lock.json` files. For a detailed explanation of the design and purpose
of package locks in npm, see npm-package-locks(5).
## SEE ALSO
* npm-install(1)
* npm-run-script(1)
* npm-scripts(7)
* package.json(5)
* npm-package-locks(5)
* package-lock.json(5)
* npm-shrinkwrap.json(5)
* npm-ls(1)
deps/npm/doc/cli/npm-star.md
Vendored
-22
View File
@@ -1,22 +0,0 @@
npm-star(1) -- Mark your favorite packages
==========================================
## SYNOPSIS
npm star [<pkg>...]
npm unstar [<pkg>...]
## DESCRIPTION
"Starring" a package means that you have some interest in it. It's
a vaguely positive way to show that you care.
"Unstarring" is the same thing, but in reverse.
It's a boolean thing. Starring repeatedly has no additional effect.
## SEE ALSO
* npm-view(1)
* npm-whoami(1)
* npm-adduser(1)
deps/npm/doc/cli/npm-stars.md
Vendored
-21
View File
@@ -1,21 +0,0 @@
npm-stars(1) -- View packages marked as favorites
=================================================
## SYNOPSIS
npm stars [<user>]
## DESCRIPTION
If you have starred a lot of neat things and want to find them again
quickly this command lets you do just that.
You may also want to see your friend's favorite packages, in this case
you will most certainly enjoy this command.
## SEE ALSO
* npm-star(1)
* npm-view(1)
* npm-whoami(1)
* npm-adduser(1)
deps/npm/doc/cli/npm-start.md
Vendored
-24
View File
@@ -1,24 +0,0 @@
npm-start(1) -- Start a package
===============================
## SYNOPSIS
npm start [-- <args>]
## DESCRIPTION
This runs an arbitrary command specified in the package's `"start"` property of
its `"scripts"` object. If no `"start"` property is specified on the
`"scripts"` object, it will run `node server.js`.
As of [`npm@2.0.0`](https://blog.npmjs.org/post/98131109725/npm-2-0-0), you can
use custom arguments when executing scripts. Refer to npm-run-script(1) for
more details.
## SEE ALSO
* npm-run-script(1)
* npm-scripts(7)
* npm-test(1)
* npm-restart(1)
* npm-stop(1)
deps/npm/doc/cli/npm-stop.md
Vendored
-18
View File
@@ -1,18 +0,0 @@
npm-stop(1) -- Stop a package
=============================
## SYNOPSIS
npm stop [-- <args>]
## DESCRIPTION
This runs a package's "stop" script, if one was provided.
## SEE ALSO
* npm-run-script(1)
* npm-scripts(7)
* npm-test(1)
* npm-start(1)
* npm-restart(1)
deps/npm/doc/cli/npm-test.md
Vendored
-20
View File
@@ -1,20 +0,0 @@
npm-test(1) -- Test a package
=============================
## SYNOPSIS
npm test [-- <args>]
aliases: t, tst
## DESCRIPTION
This runs a package's "test" script, if one was provided.
## SEE ALSO
* npm-run-script(1)
* npm-scripts(7)
* npm-start(1)
* npm-restart(1)
* npm-stop(1)
deps/npm/doc/cli/npm-uninstall.md
Vendored
-53
View File
@@ -1,53 +0,0 @@
npm-uninstall(1) -- Remove a package
=============================
## SYNOPSIS
npm uninstall [<@scope>/]<pkg>[@<version>]... [-S|--save|-D|--save-dev|-O|--save-optional|--no-save]
aliases: remove, rm, r, un, unlink
## DESCRIPTION
This uninstalls a package, completely removing everything npm installed
on its behalf.
Example:
npm uninstall sax
In global mode (ie, with `-g` or `--global` appended to the command),
it uninstalls the current package context as a global package.
`npm uninstall` takes 3 exclusive, optional flags which save or update
the package version in your main package.json:
* `-S, --save`: Package will be removed from your `dependencies`.
* `-D, --save-dev`: Package will be removed from your `devDependencies`.
* `-O, --save-optional`: Package will be removed from your `optionalDependencies`.
* `--no-save`: Package will not be removed from your `package.json` file.
Further, if you have an `npm-shrinkwrap.json` then it will be updated as
well.
Scope is optional and follows the usual rules for `npm-scope(7)`.
Examples:
npm uninstall sax --save
npm uninstall @myorg/privatepackage --save
npm uninstall node-tap --save-dev
npm uninstall dtrace-provider --save-optional
npm uninstall lodash --no-save
## SEE ALSO
* npm-prune(1)
* npm-install(1)
* npm-folders(5)
* npm-config(1)
* npm-config(7)
* npmrc(5)
deps/npm/doc/cli/npm-whoami.md
Vendored
-17
View File
@@ -1,17 +0,0 @@
npm-whoami(1) -- Display npm username
=====================================
## SYNOPSIS
npm whoami [--registry <registry>]
## DESCRIPTION
Print the `username` config to standard output.
## SEE ALSO
* npm-config(1)
* npm-config(7)
* npmrc(5)
* npm-adduser(1)
deps/npm/doc/misc/npm-index.md
Vendored
+4
View File
@@ -85,6 +85,10 @@ Edit an installed package
Browse an installed package
### npm-fund(1)
Open package repository page in the browser
### npm-help-search(1)
Search npm help documentation
deps/npm/doc/spec/file-specifiers.md
Vendored
-151
View File
@@ -1,151 +0,0 @@
# `file:` specifiers
`specifier` refers to the value part of the `package.json`'s `dependencies`
object. This is a semver expression for registry dependencies and
URLs and URL-like strings for other types.
### Dependency Specifiers
* A `file:` specifier is either an absolute path (eg `/path/to/thing`, `d:\path\to\thing`):
* An absolute `file:///absolute/path` with any number of leading slashes
being treated as a single slash. That is, `file:/foo/bar` and
`file:///foo/bar` reference the same package.
* … or a relative path (eg `../path/to/thing`, `path\to\subdir`). Leading
slashes on a file specifier will be removed, that is 'file://../foo/bar`
references the same package as same as `file:../foo/bar`. The latter is
considered canonical.
* Attempting to install a specifier that has a windows drive letter will
produce an error on non-Windows systems.
* A valid `file:` specifier points is:
* a valid package file. That is, a `.tar`, `.tar.gz` or `.tgz` containing
`<dir>/package.json`.
* OR, a directory that contains a `package.json`
Relative specifiers are relative to the file they were found in, or, if
provided on the command line, the CWD that the command was run from.
An absolute specifier found in a `package.json` or `npm-shrinkwrap.json` is
probably an error as it's unlikely to be portable between computers and
should warn.
A specifier provided as a command line argument that is on a different drive
is an error. That is, `npm install file:d:/foo/bar` is an error if the
current drive is `c`. The point of this rule is that if we can't produce a
relative path then it's an error.
### Specifier Disambiguation
On the command line, plain paths are allowed. These paths can be ambiguous
as they could be a path, a plain package name or a github shortcut. This
ambiguity is resolved by checking to see if either a directory exists that
contains a `package.json`. If either is the case then the specifier is a
file specifier, otherwise it's a registry or github specifier.
### Specifier Matching
A specifier is considered to match a dependency on disk when the `realpath`
of the fully resolved specifier matches the `realpath` of the package on disk.
### Saving File Specifiers
When saving to both `package.json` and `npm-shrinkwrap.json` they will be
saved using the `file:../relative/path` form, and the relative path will be
relative to the project's root folder. This is particularly important to
note for the `npm-shrinkwrap.json` as it means the specifier there will
be different then the original `package.json` (where it was relative to that
`package.json`).
When shrinkwrapping file specifiers, the contents of the destination
package's `node_modules` WILL NOT be included in the shrinkwrap. If you want to lock
down the destination package's `node_modules` you should create a shrinkwrap for it
separately.
This is necessary to support the mono repo use case where many projects file
to the same package. If each project included its own `npm-shrinkwrap.json`
then they would each have their own distinct set of transitive dependencies
and they'd step on each other any time you ran an install in one or the other.
NOTE: This should not have an effect on shrinkwrapping of other sorts of
shrinkwrapped packages.
### Installation
#### File type specifiers pointing at tarballs
File-type specifiers pointing at a `.tgz` or `.tar.gz` or `.tar` file will
install it as a package file in the same way we would a remote tarball. The
checksum of the package file should be recorded so that we can check for updates.
#### File type specifers pointing at directories
File-type specifiers that point at directories will necessarily not do
anything for `fetch` and `extract` phases.
The symlink should be created during the `finalize` phase.
The `preinstall` for file-type specifiers MUST be run AFTER the
`finalize` phase as the symlink may be a relative path reaching outside the
current project root and a symlink that resolves in `.staging` won't resolve
in the package's final resting place.
If the module is inside the package root that we're running the install for then
dependencies of the linked package will be hoisted to the top level as usual.
If the module is outside the package root then dependencies will be installed inside
the linked module's `node_modules` folder.
### Removal
Removal should remove the symlink.
Removal MUST NOT remove the transitive dependencies IF they're installed in
the linked module's `node_modules` folder.
### Listing
In listings they should not include a version as the version is not
something `npm` is concerned about. This also makes them easily
distinguishable from symlinks of packages that have other dependency
specifiers.
If you had run:
```
npm install --save file:../a
```
And then run:
```
npm ls
```
You would see:
```
example-package@1.0.0 /path/to/example-package
└── a → file:../a
```
```
example-package@1.0.0 /path/to/example-package
+-- a -> file:../a
```
Of note here: No version is included as the relevant detail is WHERE the
package came from, not what version happened to be in that path.
### Outdated
Local specifiers should only show up in `npm outdated` if they're missing
and when they do, they should be reported as:
```
Package Current Wanted Latest Location
a MISSING LOCAL LOCAL example-package
```
### Updating
If a dependency with a local specifier is already installed then `npm
update` shouldn't do anything. If one is missing then it should be
installed as if you ran `npm install`.
deps/npm/doc/spec/package-lock.md
Vendored
-294
View File
@@ -1,294 +0,0 @@
# package-lock and npm-shrinkwrap
`npm` can have one of two different lock files:
* `package-lock.json`, which is ordinarily always present and is never published.
* `npm-shrinkwrap.json`, which is created with `npm shrinkwrap` and usually published.
You can only have one of them and in the event that you have both,
`npm-shrinkwrap.json` takes precedence. The files are exactly the same
format and in fact all the `npm shrinkwrap` command does is rename your
`package-lock.json`.
Through the rest of this document we will refer to the package-lock and
`package-lock.json` but everything also applies to `npm-shrinkwrap.json`.
## File Format
### name
The name of the package this is a package-lock for. This must match what's in `package.json`.
### version
The version of the package this is a package-lock for. This must match what's in `package.json`.
### lockfileVersion *(new)*
An integer version, starting at `1` with the version number of this document
whose semantics were used when generating this `package-lock.json`.
### preserveSymlinks *(new)*
Indicates that the install was done with the environment variable
`NODE_PRESERVE_SYMLINKS` enabled. The installer should insist that the value of this
property match that environment variable.
### dependencies
These are the modules installed in the `node_modules`. Some of these are
dependencies some of these are transitive dependencies (that is,
dependencies of our dependencies).
This is a mapping of package name to dependency object. Dependency objects have the
following properties:
#### version *(changed)*
This is a specifier that uniquely identifies this package and should be
usable in fetching a new copy of it.
* bundled dependencies: Regardless of source, this is a version number that is purely for informational purposes.
* registry sources: This is a version number. (eg, `1.2.3`)
* git sources: This is a git specifier with resolved committish. (eg, `git+https://example.com/foo/bar#115311855adb0789a0466714ed48a1499ffea97e`)
* http tarball sources: This is the URL of the tarball. (eg, `https://example.com/example-1.3.0.tgz`)
* local tarball sources: This is the file URL of the tarball. (eg `file:///opt/storage/example-1.3.0.tgz`)
* local link sources: This is the file URL of the link. (eg `file:libs/our-module`)
#### integrity *(new)*
This is a [Standard Subresource
Integrity](https://w3c.github.io/webappsec/specs/subresourceintegrity/) for
this resource.
* For bundled dependencies this is not included, regardless of source.
* For registry sources, this is the `integrity` that the registry provided, or if one wasn't provided the SHA1 in `shasum`.
* For git sources this is the specific commit hash we cloned from.
* For remote tarball sources this is an integrity based on a SHA512 of
the file.
* For local tarball sources: This is an integrity field based on the SHA512 of the file.
#### resolved
* For bundled dependencies this is not included, regardless of source.
* For registry sources this is path of the tarball relative to the registry
URL. If the tarball URL isn't on the same server as the registry URL then
this is a complete URL.
eg, Given a `package-lock.json` file containing:
```
"resolved": "https://registry.npmjs.org/example/-/example-1.0.0.tgz"
```
and a registry source configuring a custom value:
```
npm install --registry https://registry.example.com
```
the package will be fetched from the custom-defined registry:
```
https://registry.example.com/example/-/example-1.0.0.tgz
```
#### link *(new)*
If this module was symlinked in development but had semver in the
`package.json` then this is the relative path of that link.
Discussion of the semantics of this will go in the symlinks RFC.
Implementation note: To be implemented post npm@5.
#### bundled *(new)*
If true, this is the bundled dependency and will be installed by the parent
module. When installing, this module will be extracted from the parent
module during the extract phase, not installed as a separate dependency.
#### dev
If true then this dependency is either a development dependency ONLY of the
top level module or a transitive dependency of one. This is false for
dependencies that are both a development dependency of the top level and a
transitive dependency of a non-development dependency of the top level.
#### optional
If true then this dependency is either an optional dependency ONLY of the
top level module or a transitive dependency of one. This is false for
dependencies that are both an optional dependency of the top level and a
transitive dependency of a non-optional dependency of the top level.
All optional dependencies should be included even if they're uninstallable
on the current platform.
#### from
This is a record of what specifier was used to originally install this
package. This should be used only for git dependencies.
#### requires
This is a mapping of module name to version. This is a list of everything
this module requires, regardless of where it will be installed. The version
should match via normal matching rules a dependency either in our
`dependencies` or in a level higher than us.
#### dependencies
Exactly like `dependencies` at the top level, this is a list of modules to
install in the `node_modules` of this module.
## Generating
### `npm init`
If neither a `package-lock.json` nor an `npm-shrinkwrap.json` exist then
`npm init` will create a `package-lock.json`. This is functionally
equivalent to running `npm shrinkwrap` after the current init completes and
renaming the result to `package-lock.json`.
### `npm install --save`
If either an `npm-shrinkwrap.json` or a `package-lock.json` exists then it
will be updated.
If neither exist then a `package-lock.json` should be generated.
If a `package.json` does not exist, it should be generated. The generated
`package.json` should be empty, as in:
```
{
"dependencies": {
}
}
```
If the user wants to get a default package name/version added they can run `npm init`.
### `npm shrinkwrap`
If a `package-lock.json` exists, rename it to `npm-shrinkwrap.json`.
Refresh the data from the installer's ideal tree.
The top level `name` and `version` come from the `package.json`. It is an
error if either are missing or invalid.
#### dependencies.dev
This is `true` if this dependency is ONLY installed to fulfill either a top
level development dependency, or one of its transitive dependencies.
Given:
```
B (Dev) → C
```
Then both B and C would be `dev: true`.
Given:
```
A → B → C
B (Dev) -> C
```
Then all dependencies would be `dev: false`.
#### dependencies.optional
This is `true` if this dependency is ONLY ever either an optional dependency
or a transitive dependency of optional dependencies.
Given:
```
A (Opt) → B → C
```
Then all three of A, B and C would be flagged as optional.
Given:
```
A (Opt) → B → C
D → C
```
Then A and B would be flagged as optional, but C would not be.
Given:
```
A (Opt) → B → C
D → A
```
Then none would be flagged as optional.
## Installing
If the `packageIntegrity` in the `package-lock.json` differs from the one
computed from the `package.json` then places where the `package.json` is
incompatible with the `package-lock.json` a new module should be installed.
That is, while the `package-lock.json` ordinarily defines the state of your
project, if your `package.json` is edited independently it will take
precedence.
The `package-lock.json` describes the exact tree that `npm` should create.
Any deviation between the `package.json` and the shrinkwrap/lock should
result in a warning be issued. This includes:
* Modules in `package.json` but missing from the `package-lock.json`
* Modules in the `package-lock.json` but missing from the `package.json`.
* Modules in `package.json` whose specifiers don't match the version in `package-lock.json`.
Warn if the `lockfileVersion` in the `package-lock.json` is for a different
major version than we implement.
Module resolution from package-lock data works as such:
* If install was run with `--resolve-links` and a dependency has a `link`
property then a symlink is made using that. If the version of the
destination can not be matched to the package-lock and/or the package.json
then a warning will be issued.
* Otherwise, if a `integrity` is available then we try to install it from the cache using it.
If `integrity` is unavailable or we are unable to locate a module from the `integrity` then:
* If `lockfileVersion` is set:
* Install using the value of `version` and validate the result against the
`integrity`.
* Otherwise, try these in turn and validate the result against the `integrity`:
* `resolved`, then `from`, then `version.
* `from` can be either `package@specifier` or just `specifier`.
Regardless of how the module is installed the metadata in the installed
module should be identical to what it would have been if the module were
installed w/o a package-lock.
## Implied Changes To Other Commands
### `npm rm --save`
Currently if you ask to remove a package that's both a direct and a
transitive dependency, we'll remove the package from `node_modules` even if
this results in a broken tree. This was chosen at the time because we felt
that users would expect `npm rm pkgname` to be equivalent of
`rm -rf node_modules/pkgname`.
As you are no longer going to be allowed to put your `node_modules` in a
state that's not a valid package-lock, this means this behavior is no longer
valid. Instead we should follow normal rules, removing it from the
dependencies for the top level but only removing the module on disk if
nothing requires it any more.
## Additional fields / Adding new fields
Installers should ignore any field they aren't aware of. It's not an error
to have additional properties in the package-lock or lock file.
Installers that want to add new fields should either have one added via RFC
in the npm issue tracker and an accompanying documentation PR, or should prefix
it with the name of their project.
deps/npm/docs/LICENSE
Vendored
+21
View File
@@ -0,0 +1,21 @@
The MIT License (MIT)
Copyright (c) 2015 gatsbyjs
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
deps/npm/doc/cli/npm-access.md → deps/npm/docs/content/cli-commands/npm-access.md
Vendored Regular → Executable
+28 -19
View File
@@ -1,22 +1,31 @@
npm-access(1) -- Set access level on published packages
=======================================================
---
section: cli-commands
title: npm-access
description: Set access level on published packages
---
## SYNOPSIS
# npm-access
npm access public [<package>]
npm access restricted [<package>]
## Set access level on published packages
npm access grant <read-only|read-write> <scope:team> [<package>]
npm access revoke <scope:team> [<package>]
### Synopsis
npm access 2fa-required [<package>]
npm access 2fa-not-required [<package>]
```bash
npm access public [<package>]
npm access restricted [<package>]
npm access ls-packages [<user>|<scope>|<scope:team>]
npm access ls-collaborators [<package> [<user>]]
npm access edit [<package>]
npm access grant <read-only|read-write> <scope:team> [<package>]
npm access revoke <scope:team> [<package>]
## DESCRIPTION
npm access 2fa-required [<package>]
npm access 2fa-not-required [<package>]
npm access ls-packages [<user>|<scope>|<scope:team>]
npm access ls-collaborators [<package> [<user>]]
npm access edit [<package>]
```
### Description
Used to set access controls on private packages.
@@ -48,7 +57,7 @@ subcommand.
* edit:
Set the access privileges for a package at once using `$EDITOR`.
## DETAILS
### Details
`npm access` always operates directly on the current registry, configurable
from the command line using `--registry=<registry url>`.
@@ -75,10 +84,10 @@ with an HTTP 402 status code (logically enough), unless you use
Management of teams and team memberships is done with the `npm team` command.
## SEE ALSO
### See Also
* [`libnpmaccess`](https://npm.im/libnpmaccess)
* npm-team(1)
* npm-publish(1)
* npm-config(7)
* npm-registry(7)
* [npm team](/cli-commands/npm-team)
* [npm publish](/cli-commands/npm-publish)
* [npm config](/cli-commands/npm-config)
* [npm registry](/using-npm/registry)
deps/npm/doc/cli/npm-adduser.md → deps/npm/docs/content/cli-commands/npm-adduser.md
Vendored Regular → Executable
+34 -22
View File
@@ -1,17 +1,26 @@
npm-adduser(1) -- Add a registry user account
=============================================
---
section: cli-commands
title: npm-adduser
description: Set access level on published packages
---
## SYNOPSIS
# npm-adduser
npm adduser [--registry=url] [--scope=@orgname] [--always-auth] [--auth-type=legacy]
## Add a registry user account
aliases: login, add-user
### Synopsis
## DESCRIPTION
```bash
npm adduser [--registry=url] [--scope=@orgname] [--always-auth] [--auth-type=legacy]
aliases: login, add-user
```
### Description
Create or verify a user named `<username>` in the specified registry, and
save the credentials to the `.npmrc` file. If no registry is specified,
the default registry will be used (see `npm-config(7)`).
the default registry will be used (see [`npm-config`](npm-config)).
The username, password, and email are read in from prompts.
@@ -26,30 +35,32 @@ your existing record.
`npm login` is an alias to `adduser` and behaves exactly the same way.
## CONFIGURATION
### Configuration
### registry
#### registry
Default: https://registry.npmjs.org/
The base URL of the npm package registry. If `scope` is also specified,
this registry will only be used for packages with that scope. `scope` defaults
to the scope of the project directory you're currently in, if any. See `npm-scope(7)`.
to the scope of the project directory you're currently in, if any. See [`npm-scope`](/docs/using-npm/scope).
### scope
#### scope
Default: none
If specified, the user and login credentials given will be associated
with the specified scope. See `npm-scope(7)`. You can use both at the same time,
with the specified scope. See [`npm-scope`](/docs/using-npm/scope). You can use both at the same time,
e.g.
```bash
npm adduser --registry=http://myregistry.example.com --scope=@myco
```
This will set a registry for the given scope and login or create a user for
that registry at the same time.
### always-auth
#### always-auth
Default: false
@@ -57,16 +68,18 @@ If specified, save configuration indicating that all requests to the given
registry should include authorization information. Useful for private
registries. Can be used with `--registry` and / or `--scope`, e.g.
```bash
npm adduser --registry=http://private-registry.example.com --always-auth
```
This will ensure that all requests to that registry (including for tarballs)
include an authorization header. This setting may be necessary for use with
private registries where metadata and package tarballs are stored on hosts with
different hostnames. See `always-auth` in `npm-config(7)` for more details on
different hostnames. See `always-auth` in [`npm-config`](/docs/using-npm/config) for more details on
always-auth. Registry-specific configuration of `always-auth` takes precedence
over any global configuration.
### auth-type
#### auth-type
* Default: `'legacy'`
* Type: `'legacy'`, `'sso'`, `'saml'`, `'oauth'`
@@ -75,11 +88,10 @@ What authentication strategy to use with `adduser`/`login`. Some npm registries
(for example, npmE) might support alternative auth strategies besides classic
username/password entry in legacy npm.
## SEE ALSO
### See Also
* npm-registry(7)
* npm-config(1)
* npm-config(7)
* npmrc(5)
* npm-owner(1)
* npm-whoami(1)
* [npm registry](/using-npm/registry)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [npm owner](/cli-commands/npm-owner)
* [npm whoami](/cli-commands/npm-whoami)
deps/npm/doc/cli/npm-audit.md → deps/npm/docs/content/cli-commands/npm-audit.md
Vendored Regular → Executable
+34 -25
View File
@@ -1,73 +1,82 @@
npm-audit(1) -- Run a security audit
====================================
---
section: cli-commands
title: npm-audit
description: Run a security audit
---
## SYNOPSIS
# npm-audit
npm audit [--json|--parseable|--audit-level=(low|moderate|high|critical)]
npm audit fix [--force|--package-lock-only|--dry-run]
## Run a security audit
common options: [--production] [--only=(dev|prod)]
### Synopsis
## EXAMPLES
```bash
npm audit [--json|--parseable|--audit-level=(low|moderate|high|critical)]
npm audit fix [--force|--package-lock-only|--dry-run]
common options: [--production] [--only=(dev|prod)]
```
### Examples
Scan your project for vulnerabilities and automatically install any compatible
updates to vulnerable dependencies:
```
```bash
$ npm audit fix
```
Run `audit fix` without modifying `node_modules`, but still updating the
pkglock:
```
```bash
$ npm audit fix --package-lock-only
```
Skip updating `devDependencies`:
```
```bash
$ npm audit fix --only=prod
```
Have `audit fix` install semver-major updates to toplevel dependencies, not just
semver-compatible ones:
```
```bash
$ npm audit fix --force
```
Do a dry run to get an idea of what `audit fix` will do, and _also_ output
install information in JSON format:
```
```bash
$ npm audit fix --dry-run --json
```
Scan your project for vulnerabilities and just show the details, without fixing
anything:
```
```bash
$ npm audit
```
Get the detailed audit report in JSON format:
```
```bash
$ npm audit --json
```
Get the detailed audit report in plain text result, separated by tab characters, allowing for
future reuse in scripting or command line post processing, like for example, selecting
some of the columns printed:
```
```bash
$ npm audit --parseable
```
To parse columns, you can use for example `awk`, and just print some of them:
```
```bash
$ npm audit --parseable | awk -F $'\t' '{print $1,$4}'
```
Fail an audit only if the results include a vulnerability with a level of moderate or higher:
```
```bash
$ npm audit --audit-level=moderate
```
## DESCRIPTION
### Description
The audit command submits a description of the dependencies configured in
your project to your default registry and asks for a report of known
@@ -88,7 +97,7 @@ to specify the minimum vulnerability level that will cause the command to fail.
option does not filter the report output, it simply changes the command's failure
threshold.
## CONTENT SUBMITTED
### Content Submitted
* npm_version
* node_version
@@ -96,7 +105,7 @@ threshold.
* node_env
* A scrubbed version of your package-lock.json or npm-shrinkwrap.json
### SCRUBBING
#### Scrubbing
In order to ensure that potentially sensitive information is not included in
the audit data bundle, some dependencies may have their names (and sometimes
@@ -113,15 +122,15 @@ The non-reversible identifiers are a sha256 of a session-specific UUID and the
value being replaced, ensuring a consistent value within the payload that is
different between runs.
## EXIT CODE
### Exit Code
The `npm audit` command will exit with a 0 exit code if no vulnerabilities were found.
If vulnerabilities were found the exit code will depend on the `audit-level`
configuration setting.
## SEE ALSO
### See Also
* npm-install(1)
* package-locks(5)
* config(7)
* [npm install](/cli-commands/npm-install)
* [package-locks](/configuring-npm/package-locks)
* [config](/using-npm/config)
deps/npm/docs/content/cli-commands/npm-bin.md
Vendored Executable
+26
View File
@@ -0,0 +1,26 @@
---
section: cli-commands
title: npm-bin
description: Display npm bin folder
---
# npm-bin
## Display npm bin folder
### Synopsis
```bash
npm bin [-g|--global]
```
### Description
Print the folder where npm will install executables.
### See Also
* [npm prefix](/cli-commands/npm-prefix)
* [npm root](/cli-commands/npm-root)
* [npm folders](/configuring-npm/folders)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
deps/npm/docs/content/cli-commands/npm-bugs.md
Vendored Executable
+50
View File
@@ -0,0 +1,50 @@
---
section: cli-commands
title: npm-bugs
description: Bugs for a package in a web browser maybe
---
# npm-bugs
## Bugs for a package in a web browser maybe
### Synopsis
```bash
npm bugs [<pkgname>]
aliases: issues
```
### Description
This command tries to guess at the likely location of a package's
bug tracker URL, and then tries to open it using the `--browser`
config param. If no package name is provided, it will search for
a `package.json` in the current folder and use the `name` property.
### Configuration
#### browser
* Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
* Type: String
The browser that is called by the `npm bugs` command to open websites.
#### registry
* Default: https://registry.npmjs.org/
* Type: url
The base URL of the npm package registry.
### See Also
* [npm docs](/cli-commands/npm-docs)
* [npm view](/cli-commands/npm-view)
* [npm publish](/cli-commands/npm-publish)
* [npm registry](/using-npm/registry)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [package.json](/configuring-npm/package-json)
deps/npm/docs/content/cli-commands/npm-build.md
Vendored Executable
+34
View File
@@ -0,0 +1,34 @@
---
section: cli-commands
title: npm-build
description: Build a package
---
# npm-build
## Build a package
### Synopsis
```shell
npm build [<package-folder>]
```
* `<package-folder>`:
A folder containing a `package.json` file in its root.
### Description
This is the plumbing command called by `npm link` and `npm install`.
It should generally be called during installation, but if you need to run it
directly, run:
```bash
npm run-script build
```
### See Also
* [npm install](/cli-commands/npm-install)
* [npm link](/cli-commands/npm-link)
* [npm scripts](/using-npm/scripts)
* [package.json](/configuring-npm/package-json)
deps/npm/doc/cli/npm-bundle.md → deps/npm/docs/content/cli-commands/npm-bundle.md
Vendored Regular → Executable
+12 -5
View File
@@ -1,7 +1,14 @@
npm-bundle(1) -- REMOVED
========================
---
section: cli-commands
title: npm-bundle
description: REMOVED
---
## DESCRIPTION
# npm-bundle
## REMOVED
### Description
The `npm bundle` command has been removed in 1.0, for the simple reason
that it is no longer necessary, as the default behavior is now to
@@ -9,6 +16,6 @@ install packages into the local space.
Just use `npm install` now to do what `npm bundle` used to do.
## SEE ALSO
### See Also
* npm-install(1)
* [npm install](/cli-commands/npm-install)
deps/npm/doc/cli/npm-cache.md → deps/npm/docs/content/cli-commands/npm-cache.md
Vendored Regular → Executable
+31 -23
View File
@@ -1,19 +1,28 @@
npm-cache(1) -- Manipulates packages cache
==========================================
---
section: cli-commands
title: npm-cache
description: Manipulates packages cache
---
## SYNOPSIS
# npm-cache
npm cache add <tarball file>
npm cache add <folder>
npm cache add <tarball url>
npm cache add <name>@<version>
## Manipulates packages cache
npm cache clean [<path>]
aliases: npm cache clear, npm cache rm
### Synopsis
npm cache verify
```bash
npm cache add <tarball file>
npm cache add <folder>
npm cache add <tarball url>
npm cache add <name>@<version>
## DESCRIPTION
npm cache clean [<path>]
aliases: npm cache clear, npm cache rm
npm cache verify
```
### Description
Used to add, list, or clean the npm cache folder.
@@ -29,7 +38,7 @@ Used to add, list, or clean the npm cache folder.
Verify the contents of the cache folder, garbage collecting any unneeded data,
and verifying the integrity of the cache index and all cached data.
## DETAILS
### Details
npm stores cache data in an opaque directory within the configured `cache`,
named `_cacache`. This directory is a `cacache`-based content-addressable cache
@@ -51,7 +60,7 @@ directly.
npm will not remove data by itself: the cache will grow as new packages are
installed.
## A NOTE ABOUT THE CACHE'S DESIGN
### A note about the cache's design
The npm cache is strictly a cache: it should not be relied upon as a persistent
and reliable data store for package data. npm makes no guarantee that a
@@ -62,22 +71,21 @@ if it does return data, that data will be exactly the data that was inserted.
To run an offline verification of existing cache contents, use `npm cache
verify`.
## CONFIGURATION
### Configuration
### cache
#### cache
Default: `~/.npm` on Posix, or `%AppData%/npm-cache` on Windows.
The root cache folder.
## SEE ALSO
### See Also
* npm-folders(5)
* npm-config(1)
* npm-config(7)
* npmrc(5)
* npm-install(1)
* npm-publish(1)
* npm-pack(1)
* [npm folders](/configuring-npm/folders)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [npm install](/cli-commands/npm-install)
* [npm publish](/cli-commands/npm-publish)
* [npm pack](/cli-commands/npm-pack)
* https://npm.im/cacache
* https://npm.im/pacote
deps/npm/doc/cli/npm-ci.md → deps/npm/docs/content/cli-commands/npm-ci.md
Vendored Regular → Executable
+21 -13
View File
@@ -1,15 +1,23 @@
npm-ci(1) -- Install a project with a clean slate
===================================
---
section: cli-commands
title: npm-ci
description: Install a project with a clean slate
---
## SYNOPSIS
# npm-ci
npm ci
## Install a project with a clean slate
## EXAMPLE
### Synopsis
```bash
npm ci
```
### Example
Make sure you have a package-lock and an up-to-date install:
```
```bash
$ cd ./my/npm/project
$ npm install
added 154 packages in 10s
@@ -18,14 +26,14 @@ $ ls | grep package-lock
Run `npm ci` in that project
```
```bash
$ npm ci
added 154 packages in 5s
```
Configure Travis to build using `npm ci` instead of `npm install`:
```
```bash
# .travis.yml
install:
- npm ci
@@ -35,9 +43,9 @@ cache:
- "$HOME/.npm"
```
## DESCRIPTION
### Description
This command is similar to `npm-install(1)`, except it's meant to be used in
This command is similar to [`npm-install`](npm-install), except it's meant to be used in
automated environments such as test platforms, continuous integration, and
deployment -- or any situation where you want to make sure you're doing a clean
install of your dependencies. It can be significantly faster than a regular npm
@@ -53,7 +61,7 @@ In short, the main differences between using `npm install` and `npm ci` are:
* If a `node_modules` is already present, it will be automatically removed before `npm ci` begins its install.
* It will never write to `package.json` or any of the package-locks: installs are essentially frozen.
## SEE ALSO
### See Also
* npm-install(1)
* npm-package-locks(5)
* [npm install](/cli-commands/npm-install)
* [package-locks](/configuring-npm/package-locks)
deps/npm/doc/cli/npm-completion.md → deps/npm/docs/content/cli-commands/npm-completion.md
Vendored Regular → Executable
+20 -10
View File
@@ -1,11 +1,19 @@
npm-completion(1) -- Tab Completion for npm
===========================================
---
section: cli-commands
title: npm-completion
description: Tab Completion for npm
---
## SYNOPSIS
# npm-completion
source <(npm completion)
## Tab Completion for npm
## DESCRIPTION
### Synopsis
```bash
source <(npm completion)
```
### Description
Enables tab-completion in all npm commands.
@@ -14,8 +22,10 @@ loads the completions into your current shell. Adding it to
your ~/.bashrc or ~/.zshrc will make the completions available
everywhere:
npm completion >> ~/.bashrc
npm completion >> ~/.zshrc
```bash
npm completion >> ~/.bashrc
npm completion >> ~/.zshrc
```
You may of course also pipe the output of `npm completion` to a file
such as `/usr/local/etc/bash_completion.d/npm` or
@@ -26,7 +36,7 @@ When `COMP_CWORD`, `COMP_LINE`, and `COMP_POINT` are defined in the
environment, `npm completion` acts in "plumbing mode", and outputs
completions based on the arguments.
## SEE ALSO
### See Also
* npm-developers(7)
* npm(1)
* [npm developers](/using-npm/developers)
* [npm](/cli-commands/npm)
deps/npm/docs/content/cli-commands/npm-config.md
Vendored Executable
+85
View File
@@ -0,0 +1,85 @@
---
section: cli-commands
title: npm-config
description: Manage the npm configuration files
---
# npm-config
## Manage the npm configuration files
### Synopsis
```bash
npm config set <key> <value> [-g|--global]
npm config get <key>
npm config delete <key>
npm config list [-l] [--json]
npm config edit
npm get <key>
npm set <key> <value> [-g|--global]
aliases: c
```
### Description
npm gets its config settings from the command line, environment
variables, `npmrc` files, and in some cases, the `package.json` file.
See [npmrc](/docs/configuring-npm/npmrc) for more information about the npmrc files.
See [config](/docs/using-npm/config) for a more thorough discussion of the mechanisms
involved.
The `npm config` command can be used to update and edit the contents
of the user and global npmrc files.
### Sub-commands
Config supports the following sub-commands:
#### set
```bash
npm config set key value
```
Sets the config key to the value.
If value is omitted, then it sets it to "true".
#### get
```bash
npm config get key
```
Echo the config value to stdout.
#### list
```bash
npm config list
```
Show all the config settings. Use `-l` to also show defaults. Use `--json`
to show the settings in json format.
#### delete
```bash
npm config delete key
```
Deletes the key from all configuration files.
#### edit
```bash
npm config edit
```
Opens the config file in an editor. Use the `--global` flag to edit the
global config.
### See Also
* [npm folders](/configuring-npm/folders)
* [npm config](/cli-commands/npm-config)
* [package.json](/configuring-npm/package-json)
* [npmrc](/configuring-npm/npmrc)
* [npm](/cli-commands/npm)
deps/npm/doc/cli/npm-dedupe.md → deps/npm/docs/content/cli-commands/npm-dedupe.md
Vendored Regular → Executable
+34 -22
View File
@@ -1,14 +1,22 @@
npm-dedupe(1) -- Reduce duplication
===================================
---
section: cli-commands
title: npm-dedupe
description: Reduce duplication
---
## SYNOPSIS
# npm-dedupe
npm dedupe
npm ddp
## Reduce duplication
aliases: find-dupes, ddp
### Synopsis
```bash
npm dedupe
npm ddp
## DESCRIPTION
aliases: find-dupes, ddp
```
### Description
Searches the local package tree and attempts to simplify the overall
structure by moving dependencies further up the tree, where they can
@@ -16,18 +24,22 @@ be more effectively shared by multiple dependent packages.
For example, consider this dependency graph:
a
+-- b <-- depends on c@1.0.x
| `-- c@1.0.3
`-- d <-- depends on c@~1.0.9
`-- c@1.0.10
In this case, `npm-dedupe(1)` will transform the tree to:
a
+-- b
+-- d
```bash
a
+-- b <-- depends on c@1.0.x
| `-- c@1.0.3
`-- d <-- depends on c@~1.0.9
`-- c@1.0.10
```
In this case, `npm-dedupe` will transform the tree to:
```bash
a
+-- b
+-- d
`-- c@1.0.10
```
Because of the hierarchical nature of node's module lookup, b and d
will both get their dependency met by the single c package at the root
@@ -48,8 +60,8 @@ Modules
Note that this operation transforms the dependency tree, but will never
result in new modules being installed.
## SEE ALSO
### See Also
* npm-ls(1)
* npm-update(1)
* npm-install(1)
* [npm ls](/cli-commands/npm-ls)
* [npm update](/cli-commands/npm-update)
* [npm install](/cli-commands/npm-install)
deps/npm/doc/cli/npm-deprecate.md → deps/npm/docs/content/cli-commands/npm-deprecate.md
Vendored Regular → Executable
+18 -10
View File
@@ -1,19 +1,27 @@
npm-deprecate(1) -- Deprecate a version of a package
====================================================
---
section: cli-commands
title: npm-deprecate
description: Deprecate a version of a package
---
# npm-deprecate
## SYNOPSIS
## Deprecate a version of a package
npm deprecate <pkg>[@<version>] <message>
### Synopsis
```bash
npm deprecate <pkg>[@<version>] <message>
```
## DESCRIPTION
### Description
This command will update the npm registry entry for a package, providing
a deprecation warning to all who attempt to install it.
It works on [version ranges](https://semver.npmjs.com/) as well as specific
versions, so you can do something like this:
npm deprecate my-thing@"< 0.2.3" "critical bug fixed in v0.2.3"
```bash
npm deprecate my-thing@"< 0.2.3" "critical bug fixed in v0.2.3"
```
Note that you must be the package owner to deprecate something. See the
`owner` and `adduser` help topics.
@@ -22,7 +30,7 @@ To un-deprecate a package, specify an empty string (`""`) for the `message`
argument. Note that you must use double quotes with no space between them to
format an empty string.
## SEE ALSO
### See Also
* npm-publish(1)
* npm-registry(7)
* [npm publish](/cli-commands/npm-publish)
* [npm registry](/using-npm/registry)
deps/npm/doc/cli/npm-dist-tag.md → deps/npm/docs/content/cli-commands/npm-dist-tag.md
Vendored Regular → Executable
+33 -23
View File
@@ -1,15 +1,24 @@
npm-dist-tag(1) -- Modify package distribution tags
===================================================
---
section: cli-commands
title: npm-dist-tag
description: Modify package distribution tags
---
## SYNOPSIS
# npm-dist-tag
npm dist-tag add <pkg>@<version> [<tag>]
npm dist-tag rm <pkg> <tag>
npm dist-tag ls [<pkg>]
## Modify package distribution tags
aliases: dist-tags
## DESCRIPTION
### Synopsis
```bash
npm dist-tag add <pkg>@<version> [<tag>]
npm dist-tag rm <pkg> <tag>
npm dist-tag ls [<pkg>]
aliases: dist-tags
```
### Description
Add, remove, and enumerate distribution tags on a package:
@@ -24,18 +33,20 @@ Add, remove, and enumerate distribution tags on a package:
* ls:
Show all of the dist-tags for a package, defaulting to the package in
the current prefix.
This is the default action if none is specified.
the current prefix. This is the default action if none is specified.
A tag can be used when installing packages as a reference to a version instead
of using a specific version number:
npm install <name>@<tag>
```bash
npm install <name>@<tag>
```
When installing dependencies, a preferred tagged version may be specified:
npm install --tag <tag>
```bash
npm install --tag <tag>
```
This also applies to `npm dedupe`.
@@ -45,7 +56,7 @@ Publishing a package sets the `latest` tag to the published version unless the
By default, `npm install <pkg>` (without any `@<version>` or `@<tag>`
specifier) installs the `latest` tag.
## PURPOSE
### Purpose
Tags can be used to provide an alias instead of version numbers.
@@ -64,7 +75,7 @@ The `next` tag is used by some projects to identify the upcoming version.
By default, other than `latest`, no tag has any special significance to npm
itself.
## CAVEATS
### Caveats
This command used to be known as `npm tag`, which only created new tags, and so
had a different syntax.
@@ -79,12 +90,11 @@ example, `v1.4` cannot be used as a tag, because it is interpreted by semver as
The simplest way to avoid semver problems with tags is to use tags that do not
begin with a number or the letter `v`.
## SEE ALSO
### See Also
* npm-publish(1)
* npm-install(1)
* npm-dedupe(1)
* npm-registry(7)
* npm-config(1)
* npm-config(7)
* npmrc(5)
* [npm publish](/cli-commands/npm-publish)
* [npm install](/cli-commands/npm-install)
* [npm dedupe](/cli-commands/npm-dedupe)
* [npm registry](/using-npm/registry)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
deps/npm/docs/content/cli-commands/npm-docs.md
Vendored Executable
+53
View File
@@ -0,0 +1,53 @@
---
section: cli-commands
title: npm-docs
description: Docs for a package in a web browser maybe
---
# npm-docs
## Docs for a package in a web browser maybe
### Synopsis
```bash
npm docs [<pkgname> [<pkgname> ...]]
npm docs .
npm home [<pkgname> [<pkgname> ...]]
npm home .
```
### Description
This command tries to guess at the likely location of a package's
documentation URL, and then tries to open it using the `--browser`
config param. You can pass multiple package names at once. If no
package name is provided, it will search for a `package.json` in
the current folder and use the `name` property.
### Configuration
#### browser
* Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
* Type: String
The browser that is called by the `npm docs` command to open websites.
#### registry
* Default: https://registry.npmjs.org/
* Type: url
The base URL of the npm package registry.
### See Also
* [npm view](/cli-commands/npm-view)
* [npm publish](/cli-commands/npm-publish)
* [npm registry](/using-npm/registry)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [package.json](/configuring-npm/package-json)
deps/npm/doc/cli/npm-doctor.md → deps/npm/docs/content/cli-commands/npm-doctor.md
Vendored Regular → Executable
+25 -16
View File
@@ -1,11 +1,20 @@
npm-doctor(1) -- Check your environments
========================================================
---
section: cli-commands
title: npm-doctor
description: Check your environments
---
## SYNOPSIS
# npm-doctor
npm doctor
## Check your environments
## DESCRIPTION
### Synopsis
```bash
npm doctor
```
### Description
`npm doctor` runs a set of checks to ensure that your npm installation has
what it needs to manage your JavaScript packages. npm is mostly a standalone tool, but it does
@@ -29,7 +38,7 @@ better than an old version.
`npm doctor` verifies the following items in your environment, and if there are
any recommended changes, it will display them.
### `npm ping`
#### `npm ping`
By default, npm installs from the primary npm registry, `registry.npmjs.org`.
`npm doctor` hits a special ping endpoint within the registry. This can also be
@@ -42,7 +51,7 @@ what that is by running `npm config get registry`), and if you're using a
private registry that doesn't support the `/whoami` endpoint supported by the
primary registry, this check may fail.
### `npm -v`
#### `npm -v`
While Node.js may come bundled with a particular version of npm, it's the
policy of the CLI team that we recommend all users run `npm@latest` if they
@@ -52,7 +61,7 @@ releases typically only receive critical security and regression fixes. The
team believes that the latest tested version of npm is almost always likely to
be the most functional and defect-free version of npm.
### `node -v`
#### `node -v`
For most users, in most circumstances, the best version of Node will be the
latest long-term support (LTS) release. Those of you who want access to new
@@ -61,7 +70,7 @@ running a newer version, and some of you may be required to run an older
version of Node because of enterprise change control policies. That's OK! But
in general, the npm team recommends that most users run Node.js LTS.
### `npm config get registry`
#### `npm config get registry`
Some of you may be installing from private package registries for your project
or company. That's great! Others of you may be following tutorials or
@@ -70,7 +79,7 @@ having. Sometimes, this may entail changing the registry you're pointing at.
This part of `npm doctor` just lets you, and maybe whoever's helping you with
support, know that you're not using the default registry.
### `which git`
#### `which git`
While it's documented in the README, it may not be obvious that npm needs Git
installed to do many of the things that it does. Also, in some cases
@@ -78,14 +87,14 @@ installed to do many of the things that it does. Also, in some cases
accessible via your `PATH` so that npm can find it. This check ensures that Git
is available.
### Permissions checks
#### Permissions checks
* Your cache must be readable and writable by the user running npm.
* Global package binaries must be writable by the user running npm.
* Your local `node_modules` path, if you're running `npm doctor` with a project
directory, must be readable and writable by the user running npm.
### Validate the checksums of cached packages
#### Validate the checksums of cached packages
When an npm package is published, the publishing process generates a checksum
that npm uses at install time to verify that the package didn't get corrupted
@@ -95,8 +104,8 @@ get cache`, and see what's in that cache with `npm cache ls` – probably more
than you were expecting!). In the event that there are corrupt packages in your
cache, you should probably run `npm cache clean` and reset the cache.
## SEE ALSO
### See Also
* npm-bugs(1)
* npm-help(1)
* npm-ping(1)
* [npm bugs](/cli-commands/npm-bugs)
* [npm help](/cli-commands/npm-help)
* [npm ping](/cli-commands/npm-ping)
deps/npm/doc/cli/npm-edit.md → deps/npm/docs/content/cli-commands/npm-edit.md
Vendored Regular → Executable
+23 -15
View File
@@ -1,16 +1,25 @@
npm-edit(1) -- Edit an installed package
========================================
---
section: cli-commands
title: npm-edit
description: Edit an installed package
---
## SYNOPSIS
# npm-edit
npm edit <pkg>[/<subpkg>...]
## Edit an installed package
## DESCRIPTION
### Synopsis
```bash
npm edit <pkg>[/<subpkg>...]
```
### Description
Selects a (sub)dependency in the current
working directory and opens the package folder in the default editor
(or whatever you've configured as the npm `editor` config -- see
`npm-config(7)`.)
[`npm-config`](npm-config).)
After it has been edited, the package is rebuilt so as to pick up any
changes in compiled packages.
@@ -19,9 +28,9 @@ For instance, you can do `npm install connect` to install connect
into your package, and then `npm edit connect` to make a few
changes to your locally installed copy.
## CONFIGURATION
### Configuration
### editor
#### editor
* Default: `EDITOR` environment variable if set, or `"vi"` on Posix,
or `"notepad"` on Windows.
@@ -29,11 +38,10 @@ changes to your locally installed copy.
The command to run for `npm edit` or `npm config edit`.
## SEE ALSO
### See Also
* npm-folders(5)
* npm-explore(1)
* npm-install(1)
* npm-config(1)
* npm-config(7)
* npmrc(5)
* [npm folders](/configuring-npm/folders)
* [npm explore](/cli-commands/npm-explore)
* [npm install](/cli-commands/npm-install)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
deps/npm/docs/content/cli-commands/npm-explore.md
Vendored Executable
+50
View File
@@ -0,0 +1,50 @@
---
section: cli-commands
title: npm-explore
description: Browse an installed package
---
# npm-explore
## description: Browse an installed package
### Synopsis
```bash
npm explore <pkg> [ -- <command>]
```
### Description
Spawn a subshell in the directory of the installed package specified.
If a command is specified, then it is run in the subshell, which then
immediately terminates.
This is particularly handy in the case of git submodules in the
`node_modules` folder:
```bash
npm explore some-dependency -- git pull origin master
```
Note that the package is *not* automatically rebuilt afterwards, so be
sure to use `npm rebuild <pkg>` if you make any changes.
### Configuration
#### shell
* Default: SHELL environment variable, or "bash" on Posix, or "cmd" on
Windows
* Type: path
The shell to run for the `npm explore` command.
### See Also
* [npm folders](/configuring-npm/folders)
* [npm edit](/cli-commands/npm-edit)
* [npm rebuild](/cli-commands/npm-rebuild)
* [npm build](/cli-commands/npm-build)
* [npm install](/cli-commands/npm-install)
deps/npm/docs/content/cli-commands/npm-fund.md
Vendored
+59
View File
@@ -0,0 +1,59 @@
---
section: cli-commands
title: npm-fund
description: Retrieve funding information
---
# npm-fund
## Retrieve funding information
### Synopsis
```bash
npm fund [<pkg>]
```
### Description
This command retrieves information on how to fund the dependencies of
a given project. If no package name is provided, it will list all
dependencies that are looking for funding in a tree-structure in which
are listed the type of funding and the url to visit. If a package name
is provided then it tries to open its funding url using the `--browser`
config param.
The list will avoid duplicated entries and will stack all packages
that share the same type/url as a single entry. Given this nature the
list is not going to have the same shape of the output from `npm ls`.
### Configuration
#### browser
* Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
* Type: String
The browser that is called by the `npm fund` command to open websites.
#### json
* Default: false
* Type: Boolean
Show information in JSON format.
#### unicode
* Type: Boolean
* Default: true
Whether to represent the tree structure using unicode characters.
Set it to `false` in order to use all-ansi output.
## See Also
* [npm-docs](/cli-commands/npm-docs)
* [npm-config](/cli-commands/npm-config)
* [npm-install](/cli-commands/npm-install)
* [npm-ls](/cli-commands/npm-ls)
deps/npm/doc/cli/npm-help-search.md → deps/npm/docs/content/cli-commands/npm-help-search.md
Vendored Regular → Executable
+19 -10
View File
@@ -1,11 +1,20 @@
npm-help-search(1) -- Search npm help documentation
===================================================
---
section: cli-commands
title: npm-help-search
description: Search npm help documentation
---
## SYNOPSIS
# npm-help-search
npm help-search <text>
## Search npm help documentation
## DESCRIPTION
### Synopsis
```bash
npm help-search <text>
```
### Description
This command will search the npm markdown documentation files for the
terms provided, and then list the results, sorted by relevance.
@@ -16,9 +25,9 @@ If the argument to `npm help` is not a known help topic, then it will
call `help-search`. It is rarely if ever necessary to call this
command directly.
## CONFIGURATION
### Configuration
### long
#### long
* Type: Boolean
* Default: false
@@ -28,7 +37,7 @@ where the terms were found in the documentation.
If false, then help-search will just list out the help topics found.
## SEE ALSO
### See Also
* npm(1)
* npm-help(1)
* [npm](/cli-commands/npm)
* [npm help](/cli-commands/npm-help)
deps/npm/doc/cli/npm-help.md → deps/npm/docs/content/cli-commands/npm-help.md
Vendored Regular → Executable
+23 -17
View File
@@ -1,11 +1,20 @@
npm-help(1) -- Get help on npm
==============================
---
section: cli-commands
title: npm-help
description: Get help on npm
---
## SYNOPSIS
# npm-help
npm help <term> [<terms..>]
## Get help on npm
## DESCRIPTION
### Synopsis
```bash
npm help <term> [<terms..>]
```
### Description
If supplied a topic, then show the appropriate documentation page.
@@ -14,9 +23,9 @@ the `help-search` command to find a match. Note that, if `help-search`
finds a single subject, then it will run `help` on that topic, so unique
matches are equivalent to specifying a topic name.
## CONFIGURATION
### Configuration
### viewer
#### viewer
* Default: "man" on Posix, "browser" on Windows
* Type: path
@@ -25,14 +34,11 @@ The program to use to view help content.
Set to `"browser"` to view html help content in the default web browser.
## SEE ALSO
### See Also
* npm(1)
* README
* npm-folders(5)
* npm-config(1)
* npm-config(7)
* npmrc(5)
* package.json(5)
* npm-help-search(1)
* npm-index(7)
* [npm](/cli-commands/npm)
* [npm folders](/configuring-npm/folders)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [package.json](/configuring-npm/package-json)
* [npm help-search](/cli-commands/npm-help-search)
deps/npm/doc/cli/npm-hook.md → deps/npm/docs/content/cli-commands/npm-hook.md
Vendored Regular → Executable
+26 -17
View File
@@ -1,51 +1,60 @@
npm-hook(1) -- Manage registry hooks
===================================
---
section: cli-commands
title: npm-hook
description: Manage registry hooks
---
## SYNOPSIS
# npm-hook
npm hook ls [pkg]
npm hook add <entity> <url> <secret>
npm hook update <id> <url> [secret]
npm hook rm <id>
## Manage registry hooks
## EXAMPLE
### Synopsis
```bash
npm hook ls [pkg]
npm hook add <entity> <url> <secret>
npm hook update <id> <url> [secret]
npm hook rm <id>
```
### Example
Add a hook to watch a package for changes:
```
```bash
$ npm hook add lodash https://example.com/ my-shared-secret
```
Add a hook to watch packages belonging to the user `substack`:
```
```bash
$ npm hook add ~substack https://example.com/ my-shared-secret
```
Add a hook to watch packages in the scope `@npm`
```
```bash
$ npm hook add @npm https://example.com/ my-shared-secret
```
List all your active hooks:
```
```bash
$ npm hook ls
```
List your active hooks for the `lodash` package:
```
```bash
$ npm hook ls lodash
```
Update an existing hook's url:
```
```bash
$ npm hook update id-deadbeef https://my-new-website.here/
```
Remove a hook:
```
```bash
$ npm hook rm id-deadbeef
```
## DESCRIPTION
### Description
Allows you to manage [npm
hooks](https://blog.npmjs.org/post/145260155635/introducing-hooks-get-notifications-of-npm),
@@ -67,6 +76,6 @@ that particular hook.
The shared secret will be sent along to the URL endpoint so you can verify the
request came from your own configured hook.
## SEE ALSO
### See Also
* ["Introducing Hooks" blog post](https://blog.npmjs.org/post/145260155635/introducing-hooks-get-notifications-of-npm)
deps/npm/doc/cli/npm-init.md → deps/npm/docs/content/cli-commands/npm-init.md
Vendored Regular → Executable
+25 -17
View File
@@ -1,43 +1,51 @@
npm-init(1) -- create a package.json file
=======================================================
---
section: cli-commands
title: npm-init
description: create a package.json file
---
## SYNOPSIS
# npm-init
npm init [--force|-f|--yes|-y|--scope]
npm init <@scope> (same as `npx <@scope>/create`)
npm init [<@scope>/]<name> (same as `npx [<@scope>/]create-<name>`)
## create a package.json file
## EXAMPLES
### Synopsis
```bash
npm init [--force|-f|--yes|-y|--scope]
npm init <@scope> (same as `npx <@scope>/create`)
npm init [<@scope>/]<name> (same as `npx [<@scope>/]create-<name>`)
```
### Examples
Create a new React-based project using [`create-react-app`](https://npm.im/create-react-app):
```
```bash
$ npm init react-app ./my-react-app
```
Create a new `esm`-compatible package using [`create-esm`](https://npm.im/create-esm):
```
```bash
$ mkdir my-esm-lib && cd my-esm-lib
$ npm init esm --yes
```
Generate a plain old package.json using legacy init:
```
```bash
$ mkdir my-npm-pkg && cd my-npm-pkg
$ git init
$ npm init
```
Generate it without having it ask any questions:
```
```bash
$ npm init -y
```
## DESCRIPTION
### Description
`npm init <initializer>` can be used to set up a new or existing npm package.
`initializer` in this case is an npm package named `create-<initializer>`, which
will be installed by [`npx(1)`](https://npm.im/npx), and then have its main bin
will be installed by [`npx`](https://npm.im/npx), and then have its main bin
executed -- presumably creating or updating `package.json` and running any other
initialization-related operations.
@@ -58,9 +66,9 @@ it will keep any fields and values that were already set. You can also use
`-y`/`--yes` to skip the questionnaire altogether. If you pass `--scope`, it
will create a scoped package.
## SEE ALSO
### See Also
* <https://github.com/isaacs/init-package-json>
* package.json(5)
* npm-version(1)
* npm-scope(7)
* [package.json](/configuring-npm/package-json)
* [npm version](/cli-commands/npm-version)
* [npm scope](/using-npm/scope)
deps/npm/docs/content/cli-commands/npm-install-ci-test.md
Vendored Executable
+26
View File
@@ -0,0 +1,26 @@
---
section: cli-commands
title: npm-install-ci-test
description: Install a project with a clean slate and run tests
---
# npm install-ci-test
## Install a project with a clean slate and run tests
### Synopsis
```bash
npm install-ci-test
alias: npm cit
```
### Description
This command runs an `npm ci` followed immediately by an `npm test`.
### See Also
* [npm ci](/cli-commands/npm-ci)
* [npm test](/cli-commands/npm-test)
deps/npm/docs/content/cli-commands/npm-install-test.md
Vendored Executable
+35
View File
@@ -0,0 +1,35 @@
---
section: cli-commands
title: npm-install-test
description: Install package(s) and run tests
---
# npm install-test
## Install package(s) and run tests
### Synopsis
```bash
npm install-test (with no args, in package dir)
npm install-test [<@scope>/]<name>
npm install-test [<@scope>/]<name>@<tag>
npm install-test [<@scope>/]<name>@<version>
npm install-test [<@scope>/]<name>@<version range>
npm install-test <tarball file>
npm install-test <tarball url>
npm install-test <folder>
alias: npm it
common options: [--save|--save-dev|--save-optional] [--save-exact] [--dry-run]
```
### Description
This command runs an `npm install` followed immediately by an `npm test`. It
takes exactly the same arguments as `npm install`.
### See Also
* [npm install](/cli-commands/npm-install)
* [npm test](/cli-commands/npm-test)
deps/npm/doc/cli/npm-install.md → deps/npm/docs/content/cli-commands/npm-install.md
Vendored Regular → Executable
+138 -96
View File
@@ -1,36 +1,45 @@
npm-install(1) -- Install a package
===================================
---
section: cli-commands
title: npm-install
description: Install a package
---
## SYNOPSIS
# npm-install
npm install (with no args, in package dir)
npm install [<@scope>/]<name>
npm install [<@scope>/]<name>@<tag>
npm install [<@scope>/]<name>@<version>
npm install [<@scope>/]<name>@<version range>
npm install <git-host>:<git-user>/<repo-name>
npm install <git repo url>
npm install <tarball file>
npm install <tarball url>
npm install <folder>
## Install a package
aliases: npm i, npm add
common options: [-P|--save-prod|-D|--save-dev|-O|--save-optional] [-E|--save-exact] [-B|--save-bundle] [--no-save] [--dry-run]
### Synopsis
## DESCRIPTION
```bash
npm install (with no args, in package dir)
npm install [<@scope>/]<name>
npm install [<@scope>/]<name>@<tag>
npm install [<@scope>/]<name>@<version>
npm install [<@scope>/]<name>@<version range>
npm install <git-host>:<git-user>/<repo-name>
npm install <git repo url>
npm install <tarball file>
npm install <tarball url>
npm install <folder>
aliases: npm i, npm add
common options: [-P|--save-prod|-D|--save-dev|-O|--save-optional] [-E|--save-exact] [-B|--save-bundle] [--no-save] [--dry-run]
```
### Description
This command installs a package, and any packages that it depends on. If the
package has a package-lock or shrinkwrap file, the installation of dependencies
will be driven by that, with an `npm-shrinkwrap.json` taking precedence if both
files exist. See package-lock.json(5) and npm-shrinkwrap(1).
files exist. See [package-lock.json](/docs/configuring-npm/package-lock.json) and [`npm-shrinkwrap`](npm-shrinkwrap).
A `package` is:
* a) a folder containing a program described by a `package.json(5)` file
* a) a folder containing a program described by a [`package.json`](/docs/configuring-npm/package-json) file
* b) a gzipped tarball containing (a)
* c) a url that resolves to (b)
* d) a `<name>@<version>` that is published on the registry (see `npm-registry(7)`) with (c)
* e) a `<name>@<tag>` (see `npm-dist-tag(1)`) that points to (d)
* d) a `<name>@<version>` that is published on the registry (see [`npm-registry`](npm-registry)) with (c)
* e) a `<name>@<tag>` (see [`npm-dist-tag`](npm-dist-tag)) that points to (d)
* f) a `<name>` that has a "latest" tag satisfying (e)
* g) a `<git remote url>` that resolves to (a)
@@ -49,7 +58,7 @@ after packing it up into a tarball (b).
directory) as a global package.
By default, `npm install` will install all modules listed as dependencies
in `package.json(5)`.
in [`package.json`](/docs/configuring-npm/package-json).
With the `--production` flag (or when the `NODE_ENV` environment variable
is set to `production`), npm will not install modules listed in
@@ -93,7 +102,7 @@ after packing it up into a tarball (b).
* `npm install [<@scope>/]<name>`:
Do a `<name>@<tag>` install, where `<tag>` is the "tag" config. (See
`npm-config(7)`. The config's default value is `latest`.)
[`npm-config`](/docs/using-npm/config). The config's default value is `latest`.)
In most cases, this will install the version of the modules tagged as
`latest` on the npm registry.
@@ -129,7 +138,7 @@ after packing it up into a tarball (b).
`<scope>` is optional. The package will be downloaded from the registry
associated with the specified scope. If no registry is associated with
the given scope the default registry is assumed. See `npm-scope(7)`.
the given scope the default registry is assumed. See [`npm-scope`](/docs/using-npm/scope).
Note: if you do not include the @-symbol on your scope name, npm will
interpret this as a GitHub repository instead, see below. Scopes names
@@ -137,14 +146,15 @@ after packing it up into a tarball (b).
Examples:
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
```bash
npm install sax
npm install githubname/reponame
npm install @myorg/privatepackage
npm install node-tap --save-dev
npm install dtrace-provider --save-optional
npm install readable-stream --save-exact
npm install ansi-regex --save-bundle
```
**Note**: If there is a file or folder named `<name>` in the current
working directory, then it will try to install that, and only try to
@@ -158,8 +168,10 @@ after packing it up into a tarball (b).
Example:
npm install sax@latest
npm install @myorg/mypackage@latest
```bash
npm install sax@latest
npm install @myorg/mypackage@latest
```
* `npm install [<@scope>/]<name>@<version>`:
@@ -168,28 +180,33 @@ after packing it up into a tarball (b).
Example:
npm install sax@0.1.1
npm install @myorg/privatepackage@1.5.0
```bash
npm install sax@0.1.1
npm install @myorg/privatepackage@1.5.0
```
* `npm install [<@scope>/]<name>@<version range>`:
Install a version of the package matching the specified version range. This
will follow the same rules for resolving dependencies described in `package.json(5)`.
will follow the same rules for resolving dependencies described in [`package.json`](/docs/configuring-npm/package-json).
Note that most version ranges must be put in quotes so that your shell will
treat it as a single argument.
Example:
npm install sax@">=0.1.0 <0.2.0"
npm install @myorg/privatepackage@">=0.1.0 <0.2.0"
```bash
npm install sax@">=0.1.0 <0.2.0"
npm install @myorg/privatepackage@">=0.1.0 <0.2.0"
```
* `npm install <git remote url>`:
Installs the package from the hosted git provider, cloning it with `git`.
For a full git remote url, only that URL will be attempted.
<protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish> | #semver:<semver>]
```bash
<protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish> | #semver:<semver>]
```
`<protocol>` is one of `git`, `git+ssh`, `git+http`, `git+https`, or
`git+file`.
@@ -223,11 +240,13 @@ after packing it up into a tarball (b).
Examples:
npm install git+ssh://git@github.com:npm/cli.git#v1.0.27
npm install git+ssh://git@github.com:npm/cli#semver:^5.0
npm install git+https://isaacs@github.com/npm/cli.git
npm install git://github.com/npm/cli.git#v1.0.27
GIT_SSH_COMMAND='ssh -i ~/.ssh/custom_ident' npm install git+ssh://git@github.com:npm/cli.git
```bash
npm install git+ssh://git@github.com:npm/cli.git#v1.0.27
npm install git+ssh://git@github.com:npm/cli#semver:^5.0
npm install git+https://isaacs@github.com/npm/cli.git
npm install git://github.com/npm/cli.git#v1.0.27
GIT_SSH_COMMAND='ssh -i ~/.ssh/custom_ident' npm install git+ssh://git@github.com:npm/cli.git
```
* `npm install <githubname>/<githubrepo>[#<commit-ish>]`:
* `npm install github:<githubname>/<githubrepo>[#<commit-ish>]`:
@@ -248,8 +267,10 @@ after packing it up into a tarball (b).
Examples:
npm install mygithubuser/myproject
npm install github:mygithubuser/myproject
```bash
npm install mygithubuser/myproject
npm install github:mygithubuser/myproject
```
* `npm install gist:[<githubname>/]<gistID>[#<commit-ish>|#semver:<semver>]`:
@@ -263,7 +284,9 @@ after packing it up into a tarball (b).
Example:
npm install gist:101a11beef
```bash
npm install gist:101a11beef
```
* `npm install bitbucket:<bitbucketname>/<bitbucketrepo>[#<commit-ish>]`:
@@ -283,7 +306,9 @@ after packing it up into a tarball (b).
Example:
npm install bitbucket:mybitbucketuser/myproject
```bash
npm install bitbucket:mybitbucketuser/myproject
```
* `npm install gitlab:<gitlabname>/<gitlabrepo>[#<commit-ish>]`:
@@ -303,13 +328,17 @@ after packing it up into a tarball (b).
Example:
npm install gitlab:mygitlabuser/myproject
npm install gitlab:myusr/myproj#semver:^5.0
```bash
npm install gitlab:mygitlabuser/myproject
npm install gitlab:myusr/myproj#semver:^5.0
```
You may combine multiple arguments, and even multiple types of arguments.
For example:
npm install sax@">=0.1.0 <0.2.0" bench supervisor
```bash
npm install sax@">=0.1.0 <0.2.0" bench supervisor
```
The `--tag` argument will apply to all of the specified install targets. If a
tag with the given name exists, the tagged version is preferred over newer
@@ -324,10 +353,16 @@ instead of checking `node_modules` and downloading dependencies.
The `-f` or `--force` argument will force npm to fetch remote resources even if a
local copy exists on disk.
npm install sax --force
```bash
npm install sax --force
```
The `--no-fund` argument will hide the message displayed at the end of each
install that aknowledges the number of dependencies looking for funding.
See `npm-fund(1)`
The `-g` or `--global` argument will cause npm to install the package globally
rather than locally. See `npm-folders(5)`.
rather than locally. See [npm-folders](/docs/configuring-npm/folders).
The `--global-style` argument will cause npm to install the package into
your local `node_modules` folder with the same layout it uses with the
@@ -336,7 +371,7 @@ global `node_modules` folder. Only your direct dependencies will show in
`node_modules` folders. This obviously will eliminate some deduping.
The `--ignore-scripts` argument will cause npm to not execute any
scripts defined in the package.json. See `npm-scripts(7)`.
scripts defined in the package.json. See [`npm-scripts`](/docs/using-npm/scripts).
The `--legacy-bundling` argument will cause npm to install the package such
that versions of npm prior to 1.4, such as the one included with node 0.8,
@@ -365,33 +400,36 @@ The `--only={prod[uction]|dev[elopment]}` argument will cause either only
`devDependencies` or only non-`devDependencies` to be installed regardless of the `NODE_ENV`.
The `--no-audit` argument can be used to disable sending of audit reports to
the configured registries. See `npm-audit(1)` for details on what is sent.
the configured registries. See [`npm-audit`](npm-audit) for details on what is sent.
See `npm-config(7)`. Many of the configuration params have some
See [`npm-config`](/docs/using-npm/config). Many of the configuration params have some
effect on installation, since that's most of what npm does.
## ALGORITHM
#### Algorithm
To install a package, npm uses the following algorithm:
load the existing node_modules tree from disk
clone the tree
fetch the package.json and assorted metadata and add it to the clone
walk the clone and add any missing dependencies
dependencies will be added as close to the top as is possible
without breaking any other modules
compare the original tree with the cloned tree and make a list of
actions to take to convert one to the other
execute all of the actions, deepest first
kinds of actions are install, update, remove and move
```bash
load the existing node_modules tree from disk
clone the tree
fetch the package.json and assorted metadata and add it to the clone
walk the clone and add any missing dependencies
dependencies will be added as close to the top as is possible
without breaking any other modules
compare the original tree with the cloned tree and make a list of
actions to take to convert one to the other
execute all of the actions, deepest first
kinds of actions are install, update, remove and move
```
For this `package{dep}` structure: `A{B,C}, B{C}, C{D}`,
this algorithm produces:
A
+-- B
+-- C
+-- D
```bash
A
+-- B
+-- C
+-- D
```
That is, the dependency from B to C is satisfied by the fact that A
already caused C to be installed at a higher level. D is still installed
@@ -399,18 +437,20 @@ at the top level because nothing conflicts with it.
For `A{B,C}, B{C,D@1}, C{D@2}`, this algorithm produces:
A
+-- B
+-- C
`-- D@2
+-- D@1
```bash
A
+-- B
+-- C
`-- D@2
+-- D@1
```
Because B's D@1 will be installed in the top level, C now has to install D@2
privately for itself. This algorithm is deterministic, but different trees may
be produced if two dependencies are requested for installation in a different
order.
See npm-folders(5) for a more detailed description of the specific
See [npm-folders](/docs/configuring-npm/folders) for a more detailed description of the specific
folder structures that npm creates.
### Limitations of npm's Install Algorithm
@@ -423,7 +463,9 @@ There are some very rare and pathological edge-cases where a cycle can
cause npm to try to install a never-ending tree of packages. Here is
the simplest case:
A -> B -> A' -> B' -> A -> B -> A' -> B' -> A -> ...
```bash
A -> B -> A' -> B' -> A -> B -> A' -> B' -> A -> ...
```
where `A` is some version of a package, and `A'` is a different version
of the same package. Because `B` depends on a different version of `A`
@@ -438,20 +480,20 @@ folder ancestors. A more correct, but more complex, solution would be
to symlink the existing version into the new location. If this ever
affects a real use-case, it will be investigated.
## SEE ALSO
### See Also
* npm-folders(5)
* npm-update(1)
* npm-audit(1)
* npm-link(1)
* npm-rebuild(1)
* npm-scripts(7)
* npm-build(1)
* npm-config(1)
* npm-config(7)
* npmrc(5)
* npm-registry(7)
* npm-dist-tag(1)
* npm-uninstall(1)
* npm-shrinkwrap(1)
* package.json(5)
* [npm folders](/configuring-npm/folders)
* [npm update](/cli-commands/npm-update)
* [npm audit](/cli-commands/npm-audit)
* [npm fund](/cli-commands/npm-fund)
* [npm link](/cli-commands/npm-link)
* [npm rebuild](/cli-commands/npm-rebuild)
* [npm scripts](/using-npm/scripts)
* [npm build](/cli-commands/npm-build)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [npm registry](/using-npm/registry)
* [npm dist-tag](/cli-commands/npm-dist-tag)
* [npm uninstall](/cli-commands/npm-uninstall)
* [npm shrinkwrap](/cli-commands/npm-shrinkwrap)
* [package.json](/configuring-npm/package-json)
deps/npm/doc/cli/npm-link.md → deps/npm/docs/content/cli-commands/npm-link.md
Vendored Regular → Executable
+39 -23
View File
@@ -1,20 +1,29 @@
npm-link(1) -- Symlink a package folder
=======================================
---
section: cli-commands
title: npm-link
description: Symlink a package folder
---
## SYNOPSIS
# npm-link
npm link (in package dir)
npm link [<@scope>/]<pkg>[@<version>]
## Symlink a package folder
alias: npm ln
### Synopsis
## DESCRIPTION
```bash
npm link (in package dir)
npm link [<@scope>/]<pkg>[@<version>]
alias: npm ln
```
### Description
Package linking is a two-step process.
First, `npm link` in a package folder will create a symlink in the global folder
`{prefix}/lib/node_modules/<package>` that links to the package where the `npm
link` command was executed. (see `npm-config(7)` for the value of `prefix`). It
link` command was executed. (see [`npm-config`](npm-config) for the value of `prefix`). It
will also link any bins in the package to `{prefix}/bin/{name}`.
Next, in some other location, `npm link package-name` will create a
@@ -24,7 +33,7 @@ of the current folder.
Note that `package-name` is taken from `package.json`,
not from directory name.
The package name can be optionally prefixed with a scope. See `npm-scope(7)`.
The package name can be optionally prefixed with a scope. See [`npm-scope`](npm-scope).
The scope must be preceded by an @-symbol and followed by a slash.
When creating tarballs for `npm publish`, the linked packages are
@@ -35,10 +44,12 @@ test it iteratively without having to continually rebuild.
For example:
```bash
cd ~/projects/node-redis # go into the package directory
npm link # creates global link
cd ~/projects/node-bloggy # go into some other package directory.
npm link redis # link-install the package
```
Now, any changes to ~/projects/node-redis will be reflected in
~/projects/node-bloggy/node_modules/node-redis/. Note that the link should
@@ -47,13 +58,17 @@ be to the package name, not the directory name for that package.
You may also shortcut the two steps in one. For example, to do the
above use-case in a shorter way:
cd ~/projects/node-bloggy # go into the dir of your main project
npm link ../node-redis # link the dir of your dependency
```bash
cd ~/projects/node-bloggy # go into the dir of your main project
npm link ../node-redis # link the dir of your dependency
```
The second line is the equivalent of doing:
(cd ../node-redis; npm link)
npm link redis
```bash
(cd ../node-redis; npm link)
npm link redis
```
That is, it first creates a global link, and then links the global
installation target into your project's `node_modules` folder.
@@ -61,17 +76,18 @@ installation target into your project's `node_modules` folder.
Note that in this case, you are referring to the directory name, `node-redis`,
rather than the package name `redis`.
If your linked package is scoped (see `npm-scope(7)`) your link command must
If your linked package is scoped (see [`npm-scope`](npm-scope)) your link command must
include that scope, e.g.
npm link @myorg/privatepackage
```bash
npm link @myorg/privatepackage
```
## SEE ALSO
### See Also
* npm-developers(7)
* package.json(5)
* npm-install(1)
* npm-folders(5)
* npm-config(1)
* npm-config(7)
* npmrc(5)
* [npm developers](/using-npm/developers)
* [package.json](/configuring-npm/package-json)
* [npm- nstall](/cli-commands/npm-install)
* [npm folders](/configuring-npm/folders)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
deps/npm/doc/cli/npm-logout.md → deps/npm/docs/content/cli-commands/npm-logout.md
Vendored Regular → Executable
+26 -17
View File
@@ -1,11 +1,20 @@
npm-logout(1) -- Log out of the registry
========================================
---
section: cli-commands
title: npm-logout
description: Log out of the registry
---
## SYNOPSIS
# npm-logout
npm logout [--registry=<url>] [--scope=<@scope>]
## Log out of the registry
## DESCRIPTION
### Synopsis
```bash
npm logout [--registry=<url>] [--scope=<@scope>]
```
### Description
When logged into a registry that supports token-based authentication, tell the
server to end this token's session. This will invalidate the token everywhere
@@ -18,28 +27,28 @@ the current environment.
If `--scope` is provided, this will find the credentials for the registry
connected to that scope, if set.
## CONFIGURATION
### Configuration
### registry
#### registry
Default: https://registry.npmjs.org/
The base URL of the npm package registry. If `scope` is also specified,
it takes precedence.
### scope
#### scope
Default: The scope of your current project, if any, otherwise none.
If specified, you will be logged out of the specified scope. See `npm-scope(7)`.
If specified, you will be logged out of the specified scope. See [`npm-scope`](npm-scope).
npm logout --scope=@myco
```bash
npm logout --scope=@myco
```
## SEE ALSO
### See Also
* npm-adduser(1)
* npm-registry(7)
* npm-config(1)
* npm-config(7)
* npmrc(5)
* npm-whoami(1)
* [npm adduser](/cli-commands/npm-adduser)
* [npm registry](/using-npm/registry)
* [npm config](/cli-commands/npm-config)
* [npm whoami](/cli-commands/npm-whoami)
deps/npm/doc/cli/npm-ls.md → deps/npm/docs/content/cli-commands/npm-ls.md
Vendored Regular → Executable
+44 -26
View File
@@ -1,13 +1,22 @@
npm-ls(1) -- List installed packages
======================================
---
section: cli-commands
title: npm-ls
description: List installed packages
---
## SYNOPSIS
# npm-ls
npm ls [[<@scope>/]<pkg> ...]
## List installed packages
aliases: list, la, ll
### Synopsis
## DESCRIPTION
```bash
npm ls [[<@scope>/]<pkg> ...]
aliases: list, la, ll
```
### Description
This command will print to stdout all the versions of packages that are
installed, as well as their dependencies, in a tree-structure.
@@ -17,9 +26,11 @@ limit the results to only the paths to the packages named. Note that
nested packages will *also* show the paths to the specified packages.
For example, running `npm ls promzard` in npm's source tree will show:
```bash
npm@@VERSION@ /path/to/npm
└─┬ init-package-json@0.0.4
└── promzard@0.1.5
```
It will print out extraneous, missing, and invalid packages.
@@ -32,30 +43,30 @@ dependencies, not the physical layout of your node_modules folder.
When run as `ll` or `la`, it shows extended information by default.
## CONFIGURATION
### Configuration
### json
#### json
* Default: false
* Type: Boolean
Show information in JSON format.
### long
#### long
* Default: false
* Type: Boolean
Show extended information.
### parseable
#### parseable
* Default: false
* Type: Boolean
Show parseable output instead of tree view.
### global
#### global
* Default: false
* Type: Boolean
@@ -63,27 +74,27 @@ Show parseable output instead of tree view.
List packages in the global install prefix instead of in the current
project.
### depth
#### depth
* Type: Int
Max display depth of the dependency tree.
### prod / production
#### prod / production
* Type: Boolean
* Default: false
Display only the dependency tree for packages in `dependencies`.
### dev / development
#### dev / development
* Type: Boolean
* Default: false
Display only the dependency tree for packages in `devDependencies`.
### only
#### only
* Type: String
@@ -91,21 +102,28 @@ When "dev" or "development", is an alias to `dev`.
When "prod" or "production", is an alias to `production`.
### link
#### link
* Type: Boolean
* Default: false
Display only dependencies which are linked
## SEE ALSO
#### unicode
* npm-config(1)
* npm-config(7)
* npmrc(5)
* npm-folders(5)
* npm-install(1)
* npm-link(1)
* npm-prune(1)
* npm-outdated(1)
* npm-update(1)
* Type: Boolean
* Default: true
Whether to represent the tree structure using unicode characters.
Set it to false in order to use all-ansi output.
### See Also
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [npm folders](/configuring-npm/folders)
* [npm install](/cli-commands/npm-install)
* [npm link](/cli-commands/npm-link)
* [npm prune](/cli-commands/npm-prune)
* [npm outdated](/cli-commands/npm-outdated)
* [npm update](/cli-commands/npm-update)
deps/npm/doc/cli/npm-org.md → deps/npm/docs/content/cli-commands/npm-org.md
Vendored Regular → Executable
+30 -15
View File
@@ -1,50 +1,65 @@
npm-org(1) -- Manage orgs
===================================
---
section: cli-commands
title: npm-org
description: Manage orgs
---
## SYNOPSIS
# npm-org
npm org set <orgname> <username> [developer | admin | owner]
npm org rm <orgname> <username>
npm org ls <orgname> [<username>]
## Manage orgs
## EXAMPLE
### Synopsis
```bash
npm org set <orgname> <username> [developer | admin | owner]
npm org rm <orgname> <username>
npm org ls <orgname> [<username>]
```
### Example
Add a new developer to an org:
```
```bash
$ npm org set my-org @mx-smith
```
Add a new admin to an org (or change a developer to an admin):
```
```bash
$ npm org set my-org @mx-santos admin
```
Remove a user from an org:
```
```bash
$ npm org rm my-org mx-santos
```
List all users in an org:
```
```bash
$ npm org ls my-org
```
List all users in JSON format:
```
```bash
$ npm org ls my-org --json
```
See what role a user has in an org:
```
```bash
$ npm org ls my-org @mx-santos
```
## DESCRIPTION
### Description
You can use the `npm org` commands to manage and view users of an organization.
It supports adding and removing users, changing their roles, listing them, and
finding specific ones and their roles.
## SEE ALSO
### See Also
* [Documentation on npm Orgs](https://docs.npmjs.com/orgs/)
deps/npm/doc/cli/npm-outdated.md → deps/npm/docs/content/cli-commands/npm-outdated.md
Vendored Regular → Executable
+27 -18
View File
@@ -1,11 +1,20 @@
npm-outdated(1) -- Check for outdated packages
==============================================
---
section: cli-commands
title: npm-outdated
description: Check for outdated packages
---
## SYNOPSIS
# npm-outdated
npm outdated [[<@scope>/]<pkg> ...]
## Check for outdated packages
## DESCRIPTION
### Synopsis
```bash
npm outdated [[<@scope>/]<pkg> ...]
```
### Description
This command will check the registry to see if any (or, specific) installed
packages are currently outdated.
@@ -20,7 +29,7 @@ In the output:
Running `npm publish` with no special configuration will publish the package
with a dist-tag of `latest`. This may or may not be the maximum version of
the package, or the most-recently published version of the package, depending
on how the package's developer manages the latest dist-tag(1).
on how the package's developer manages the latest [dist-tag](npm-dist-tag).
* `location` is where in the dependency tree the package is located. Note that
`npm outdated` defaults to a depth of 0, so unless you override that, you'll
always be seeing only top-level dependencies that are outdated.
@@ -33,7 +42,7 @@ In the output:
### An example
```
```bash
$ npm outdated
Package Current Wanted Latest Location
glob 5.0.15 5.0.15 6.0.1 test-outdated-output
@@ -69,30 +78,30 @@ A few things to note:
* `once` is just plain out of date. Reinstalling `node_modules` from scratch or
running `npm update` will bring it up to spec.
## CONFIGURATION
### Configuration
### json
#### json
* Default: false
* Type: Boolean
Show information in JSON format.
### long
#### long
* Default: false
* Type: Boolean
Show extended information.
### parseable
#### parseable
* Default: false
* Type: Boolean
Show parseable output instead of tree view.
### global
#### global
* Default: false
* Type: Boolean
@@ -100,16 +109,16 @@ Show parseable output instead of tree view.
Check packages in the global install prefix instead of in the current
project.
### depth
#### depth
* Default: 0
* Type: Int
Max depth for checking dependency tree.
## SEE ALSO
### See Also
* npm-update(1)
* npm-dist-tag(1)
* npm-registry(7)
* npm-folders(5)
* [npm update](/cli-commands/npm-update)
* [npm dist-tag](/cli-commands/npm-dist-tag)
* [npm registry](/using-npm/registry)
* [npm folders](/configuring-npm/folders)
deps/npm/doc/cli/npm-owner.md → deps/npm/docs/content/cli-commands/npm-owner.md
Vendored Regular → Executable
+21 -13
View File
@@ -1,15 +1,23 @@
npm-owner(1) -- Manage package owners
=====================================
---
section: cli-commands
title: npm-owner
description: Manage package owners
---
## SYNOPSIS
# npm-owner
## Manage package owners
npm owner add <user> [<@scope>/]<pkg>
npm owner rm <user> [<@scope>/]<pkg>
npm owner ls [<@scope>/]<pkg>
### Synopsis
aliases: author
```bash
npm owner add <user> [<@scope>/]<pkg>
npm owner rm <user> [<@scope>/]<pkg>
npm owner ls [<@scope>/]<pkg>
## DESCRIPTION
aliases: author
```
### Description
Manage ownership of published packages.
@@ -31,9 +39,9 @@ If you have two-factor authentication enabled with `auth-and-writes` then
you'll need to include an otp on the command line when changing ownership
with `--otp`.
## SEE ALSO
### See Also
* npm-publish(1)
* npm-registry(7)
* npm-adduser(1)
* npm-disputes(7)
* [npm publish](/cli-commands/npm-publish)
* [npm registry](/using-npm/registry)
* [npm adduser](/cli-commands/npm-adduser)
* [npm disputes](/using-npm/disputes)
deps/npm/doc/cli/npm-pack.md → deps/npm/docs/content/cli-commands/npm-pack.md
Vendored Regular → Executable
+19 -11
View File
@@ -1,11 +1,20 @@
npm-pack(1) -- Create a tarball from a package
==============================================
---
section: cli-commands
title: npm-pack
description: Create a tarball from a package
---
## SYNOPSIS
# npm-pack
npm pack [[<@scope>/]<pkg>...] [--dry-run]
## Create a tarball from a package
## DESCRIPTION
### Synopsis
```bash
npm pack [[<@scope>/]<pkg>...] [--dry-run]
```
### Description
For anything that's installable (that is, a package folder, tarball,
tarball url, name@tag, name@version, name, or scoped name), this
@@ -21,10 +30,9 @@ If no arguments are supplied, then npm packs the current package folder.
The `--dry-run` argument will do everything that pack usually does without
actually packing anything. Reports on what would have gone into the tarball.
## SEE ALSO
### See Also
* npm-cache(1)
* npm-publish(1)
* npm-config(1)
* npm-config(7)
* npmrc(5)
* [npm cache](/cli-commands/npm-cache)
* [npm publish](/cli-commands/npm-publish)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
deps/npm/docs/content/cli-commands/npm-ping.md
Vendored Executable
+33
View File
@@ -0,0 +1,33 @@
---
section: cli-commands
title: npm-ping
description: Ping npm registry
---
# npm-ping
## Ping npm registry
### Synopsis
```bash
npm ping [--registry <registry>]
```
### Description
Ping the configured or given npm registry and verify authentication.
If it works it will output something like:
```bash
Ping success: {*Details about registry*}
```
otherwise you will get:
```bash
Ping error: {*Detail about error}
```
### See Also
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
deps/npm/docs/content/cli-commands/npm-prefix.md
Vendored Executable
+32
View File
@@ -0,0 +1,32 @@
---
section: cli-commands
title: npm-prefix
description: Display prefix
---
# npm-prefix
## Display prefix
### Synopsis
```bash
npm prefix [-g]
```
### Description
Print the local prefix to standard out. This is the closest parent directory
to contain a `package.json` file or `node_modules` directory, unless `-g` is
also specified.
If `-g` is specified, this will be the value of the global prefix. See
[`npm-config`](npm-config) for more detail.
### See Also
* [npm root](/cli-commands/npm-root)
* [npm bin](/cli-commands/npm-bin)
* [npm folders](/configuring-npm/folders)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
deps/npm/doc/cli/npm-profile.md → deps/npm/docs/content/cli-commands/npm-profile.md
Vendored Regular → Executable
+21 -13
View File
@@ -1,15 +1,23 @@
npm-profile(1) -- Change settings on your registry profile
==========================================================
---
section: cli-commands
title: npm-profile
description: Change settings on your registry profile
---
## SYNOPSIS
# npm-profile
## Change settings on your registry profile
npm profile get [--json|--parseable] [<property>]
npm profile set [--json|--parseable] <property> <value>
npm profile set password
npm profile enable-2fa [auth-and-writes|auth-only]
npm profile disable-2fa
### Synopsis
## DESCRIPTION
```bash
npm profile get [--json|--parseable] [<property>]
npm profile set [--json|--parseable] <property> <value>
npm profile set password
npm profile enable-2fa [auth-and-writes|auth-only]
npm profile disable-2fa
```
### Description
Change your profile information on the registry. This not be available if
you're using a non-npmjs registry.
@@ -18,7 +26,7 @@ you're using a non-npmjs registry.
Display all of the properties of your profile, or one or more specific
properties. It looks like:
```
```bash
+-----------------+---------------------------+
| name | example |
+-----------------+---------------------------+
@@ -63,12 +71,12 @@ you're using a non-npmjs registry.
* `npm profile disable-2fa`:
Disables two-factor authentication.
## DETAILS
### Details
All of the `npm profile` subcommands accept `--json` and `--parseable` and
will tailor their output based on those. Some of these commands may not be
available on non npmjs.com registries.
## SEE ALSO
### See Also
* npm-config(7)
* [npm config](/cli-commands/npm-config)
deps/npm/doc/cli/npm-prune.md → deps/npm/docs/content/cli-commands/npm-prune.md
Vendored Regular → Executable
+17 -9
View File
@@ -1,11 +1,19 @@
npm-prune(1) -- Remove extraneous packages
==========================================
---
section: cli-commands
title: npm-prune
description: Remove extraneous packages
---
## SYNOPSIS
# npm-prune
## Remove extraneous packages
npm prune [[<@scope>/]<pkg>...] [--production] [--dry-run] [--json]
### Synopsis
## DESCRIPTION
```bash
npm prune [[<@scope>/]<pkg>...] [--production] [--dry-run] [--json]
```
### Description
This command removes "extraneous" packages. If a package name is
provided, then only packages matching one of the supplied names are
@@ -31,8 +39,8 @@ this command with the `--production` flag.
If you've disabled package-locks then extraneous modules will not be removed
and it's up to you to run `npm prune` from time-to-time to remove them.
## SEE ALSO
### See Also
* npm-uninstall(1)
* npm-folders(5)
* npm-ls(1)
* [npm uninstall](/cli-commands/npm-uninstall)
* [npm folders](/configuring-npm/folders)
* [npm ls](/cli-commands/npm-ls)
deps/npm/doc/cli/npm-publish.md → deps/npm/docs/content/cli-commands/npm-publish.md
Vendored Regular → Executable
+29 -22
View File
@@ -1,26 +1,33 @@
npm-publish(1) -- Publish a package
===================================
---
section: cli-commands
title: npm-publish
description: Publish a package
---
# npm-publish
## SYNOPSIS
## Publish a package
npm publish [<tarball>|<folder>] [--tag <tag>] [--access <public|restricted>] [--otp otpcode] [--dry-run]
### Synopsis
```bash
npm publish [<tarball>|<folder>] [--tag <tag>] [--access <public|restricted>] [--otp otpcode] [--dry-run]
Publishes '.' if no argument supplied
Sets tag 'latest' if no --tag specified
Publishes '.' if no argument supplied
Sets tag 'latest' if no --tag specified
```
## DESCRIPTION
### Description
Publishes a package to the registry so that it can be installed by name. All
files in the package directory are included if no local `.gitignore` or
`.npmignore` file exists. If both files exist and a file is ignored by
`.gitignore` but not by `.npmignore` then it will be included. See
`npm-developers(7)` for full details on what's included in the published
[`npm-developers`](/docs/using-npm/developers) for full details on what's included in the published
package, as well as details on how the package is built.
By default npm will publish to the public registry. This can be overridden by
specifying a different default registry or using a `npm-scope(7)` in the name
(see `package.json(5)`).
specifying a different default registry or using a [`npm-scope`](npm-scope) in the name
(see [`package.json`](/docs/configuring-npm/package-json)).
* `<folder>`:
A folder containing a package.json file
@@ -32,7 +39,7 @@ specifying a different default registry or using a `npm-scope(7)` in the name
* `[--tag <tag>]`
Registers the published package with the given tag, such that `npm install
<name>@<tag>` will install this version. By default, `npm publish` updates
and `npm install` installs the `latest` tag. See `npm-dist-tag(1)` for
and `npm install` installs the `latest` tag. See [`npm-dist-tag`](npm-dist-tag) for
details about tags.
* `[--access <public|restricted>]`
@@ -55,22 +62,22 @@ the specified registry.
Once a package is published with a given name and version, that
specific name and version combination can never be used again, even if
it is removed with npm-unpublish(1).
it is removed with [`npm-unpublish`](npm-unpublish).
As of `npm@5`, both a sha1sum and an integrity field with a sha512sum of the
tarball will be submitted to the registry during publication. Subsequent
installs will use the strongest supported algorithm to verify downloads.
Similar to `--dry-run` see `npm-pack(1)`, which figures out the files to be
Similar to `--dry-run` see [`npm-pack`](npm-pack), which figures out the files to be
included and packs them into a tarball to be uploaded to the registry.
## SEE ALSO
### See Also
* npm-registry(7)
* npm-scope(7)
* npm-adduser(1)
* npm-owner(1)
* npm-deprecate(1)
* npm-dist-tag(1)
* npm-pack(1)
* npm-profile(1)
* [npm registry](/using-npm/registry)
* [npm scope](/using-npm/scope)
* [npm adduser](/cli-commands/npm-adduser)
* [npm owner](/cli-commands/npm-owner)
* [npm deprecate](/cli-commands/npm-deprecate)
* [npm dist-tag](/cli-commands/npm-dist-tag)
* [npm pack](/cli-commands/npm-pack)
* [npm profile](/cli-commands/npm-profile)
deps/npm/docs/content/cli-commands/npm-rebuild.md
Vendored Executable
+28
View File
@@ -0,0 +1,28 @@
---
section: cli-commands
title: npm-rebuild
description: Rebuild a package
---
# npm-rebuildd
## Rebuild a package
### Synopsis
```bash
npm rebuild [[<@scope>/<name>]...]
alias: npm rb
```
### Description
This command runs the `npm build` command on the matched folders. This is useful
when you install a new version of node, and must recompile all your C++ addons with
the new binary.
### See Also
* [npm build](/cli-commands/npm-build)
* [npm install](/cli-commands/npm-install)
deps/npm/doc/cli/npm-repo.md → deps/npm/docs/content/cli-commands/npm-repo.md
Vendored Regular → Executable
+19 -10
View File
@@ -1,27 +1,36 @@
npm-repo(1) -- Open package repository page in the browser
========================================================
---
section: cli-commands
title: npm-repo
description: Open package repository page in the browser
---
## SYNOPSIS
# npm-repo
npm repo [<pkg>]
## Open package repository page in the browser
## DESCRIPTION
### Synopsis
```bash
npm repo [<pkg>]
```
### Description
This command tries to guess at the likely location of a package's
repository URL, and then tries to open it using the `--browser`
config param. If no package name is provided, it will search for
a `package.json` in the current folder and use the `name` property.
## CONFIGURATION
### Configuration
### browser
#### browser
* Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
* Type: String
The browser that is called by the `npm repo` command to open websites.
## SEE ALSO
### See Also
* npm-docs(1)
* npm-config(1)
* [npm docs](/cli-commands/npm-docs)
* [npm config](/cli-commands/npm-config)
deps/npm/doc/cli/npm-restart.md → deps/npm/docs/content/cli-commands/npm-restart.md
Vendored Regular → Executable
+22 -13
View File
@@ -1,11 +1,20 @@
npm-restart(1) -- Restart a package
===================================
---
section: cli-commands
title: npm-restart
description: Restart a package
---
## SYNOPSIS
# npm-restart
npm restart [-- <args>]
## Restart a package
## DESCRIPTION
### Synopsis
```bash
npm restart [-- <args>]
```
### Description
This restarts a package.
@@ -22,7 +31,7 @@ pre- and post- scripts, in the order given below:
8. poststart
9. postrestart
## NOTE
### Note
Note that the "restart" script is run **in addition to** the "stop"
and "start" scripts, not instead of them.
@@ -30,11 +39,11 @@ and "start" scripts, not instead of them.
This is the behavior as of `npm` major version 2. A change in this
behavior will be accompanied by an increase in major version number
## SEE ALSO
### See Also
* npm-run-script(1)
* npm-scripts(7)
* npm-test(1)
* npm-start(1)
* npm-stop(1)
* npm-restart(3)
* [npm run-script](/cli-commands/npm-run-script)
* [npm scripts](/cli-commands//docs/using-npm/scripts)
* [npm test](/cli-commands/npm-test)
* [npm start](/cli-commands/npm-start)
* [npm stop](/cli-commands/npm-stop)
* [npm restart](/cli-commands/npm-restart)
deps/npm/docs/content/cli-commands/npm-root.md
Vendored Executable
+26
View File
@@ -0,0 +1,26 @@
---
section: cli-commands
title: npm-root
description: Display npm root
---
# npm-root
## Display npm root
### Synopsis
```bash
npm root [-g]
```
### Description
Print the effective `node_modules` folder to standard out.
### See Also
* [npm prefix](/cli-commands/npm-prefix)
* [npm bin](/cli-commands/npm-bin)
* [npm folders](/configuring-npm/folders)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
deps/npm/doc/cli/npm-run-script.md → deps/npm/docs/content/cli-commands/npm-run-script.md
Vendored Regular → Executable
+31 -16
View File
@@ -1,13 +1,22 @@
npm-run-script(1) -- Run arbitrary package scripts
==================================================
---
section: cli-commands
title: npm-run-script
description: Run arbitrary package scripts
---
## SYNOPSIS
# npm-run-script
npm run-script <command> [--silent] [-- <args>...]
## Run arbitrary package scripts
alias: npm run
### Synopsis
## DESCRIPTION
```bash
npm run-script <command> [--silent] [-- <args>...]
alias: npm run
```
### Description
This runs an arbitrary command from a package's `"scripts"` object. If no
`"command"` is provided, it will list the available scripts. `run[-script]` is
@@ -20,7 +29,9 @@ use custom arguments when executing scripts. The special option `--` is used by
[getopt](https://goo.gl/KxMmtG) to delimit the end of the options. npm will pass
all the arguments after the `--` directly to your script:
npm run test -- --grep="pattern"
```bash
npm run test -- --grep="pattern"
```
The arguments will only be passed to the script specified after ```npm run```
and not to any pre or post script.
@@ -36,11 +47,15 @@ locally-installed dependencies can be used without the `node_modules/.bin`
prefix. For example, if there is a `devDependency` on `tap` in your package,
you should write:
"scripts": {"test": "tap test/\*.js"}
```bash
"scripts": {"test": "tap test/\*.js"}
```
instead of
"scripts": {"test": "node_modules/.bin/tap test/\*.js"}
```bash
"scripts": {"test": "node_modules/.bin/tap test/\*.js"}
```
to run your tests.
@@ -72,11 +87,11 @@ You can use the `--if-present` flag to avoid exiting with a non-zero exit code
when the script is undefined. This lets you run potentially undefined scripts
without breaking the execution chain.
## SEE ALSO
### See Also
* npm-scripts(7)
* npm-test(1)
* npm-start(1)
* npm-restart(1)
* npm-stop(1)
* npm-config(7)
* [npm scripts](/using-npm/scripts)
* [npm test](/cli-commands/npm-test)
* [npm start](/cli-commands/npm-start)
* [npm restart](/cli-commands/npm-restart)
* [npm stop](/cli-commands/npm-stop)
* [npm config](/cli-commands/npm-config)
deps/npm/doc/cli/npm-search.md → deps/npm/docs/content/cli-commands/npm-search.md
Vendored Regular → Executable
+29 -21
View File
@@ -1,13 +1,22 @@
npm-search(1) -- Search for packages
====================================
---
section: cli-commands
title: npm-search
description: Search for packages
---
## SYNOPSIS
# npm-search
npm search [-l|--long] [--json] [--parseable] [--no-description] [search terms ...]
## Search for packages
aliases: s, se, find
### Synopsis
## DESCRIPTION
```bash
npm search [-l|--long] [--json] [--parseable] [--no-description] [search terms ...]
aliases: s, se, find
```
### Description
Search the registry for packages matching the search terms. `npm search`
performs a linear, incremental, lexically-ordered search through package
@@ -31,9 +40,9 @@ quoted in most shells.)
### A Note on caching
## CONFIGURATION
### Configuration
### description
#### description
* Default: true
* Type: Boolean
@@ -41,21 +50,21 @@ quoted in most shells.)
Used as `--no-description`, disables search matching in package descriptions and
suppresses display of that field in results.
### json
#### json
* Default: false
* Type: Boolean
Output search results as a JSON array.
### parseable
#### parseable
* Default: false
* Type: Boolean
Output search results as lines with tab-separated columns.
### long
#### long
* Default: false
* Type: Boolean
@@ -65,28 +74,28 @@ lines. When disabled (default) search results are truncated to fit
neatly on a single line. Modules with extremely long names will
fall on multiple lines.
### searchopts
#### searchopts
* Default: ""
* Type: String
Space-separated options that are always passed to search.
### searchexclude
#### searchexclude
* Default: ""
* Type: String
Space-separated options that limit the results from search.
### searchstaleness
#### searchstaleness
* Default: 900 (15 minutes)
* Type: Number
The age of the cache, in seconds, before another registry request is made.
### registry
#### registry
* Default: https://registry.npmjs.org/
* Type: url
@@ -97,10 +106,9 @@ repository, `npm search` will default to that registry when searching. Pass a
different registry url such as the default above in order to override this
setting.
## SEE ALSO
### See Also
* npm-registry(7)
* npm-config(1)
* npm-config(7)
* npmrc(5)
* npm-view(1)
* [npm registry](/using-npm/registry)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [npm view](/cli-commands/npm-view)
deps/npm/docs/content/cli-commands/npm-shrinkwrap.md
Vendored Executable
+34
View File
@@ -0,0 +1,34 @@
---
section: cli-commands
title: npm-shrinkwrap
description: Lock down dependency versions for publication
---
# npm-shrinkwrap
## Lock down dependency versions for publication
### Synopsis
```bash
npm shrinkwrap
```
### Description
This command repurposes `package-lock.json` into a publishable
`npm-shrinkwrap.json` or simply creates a new one. The file created and updated
by this command will then take precedence over any other existing or future
`package-lock.json` files. For a detailed explanation of the design and purpose
of package locks in npm, see [npm-package-locks](npm-package-locks).
### See Also
* [npm install](/cli-commands/npm-install)
* [npm run-script](/cli-commands/npm-run-script)
* [npm scripts](/using-npm/scripts)
* [package.js](/configuring-npm/package-json)
* [package-locks](/configuring-npm/package-locks)
* [package-lock.json](/configuring-npm/package-lock-json)
* [shrinkwrap.json](/configuring-npm/shrinkwrap-json)
* [npm ls](/cli-commands/npm-ls)
deps/npm/docs/content/cli-commands/npm-star.md
Vendored Executable
+31
View File
@@ -0,0 +1,31 @@
---
section: cli-commands
title: npm-star
description: Mark your favorite packages
---
# npm-star
## Mark your favorite packages
### Synopsis
```bash
npm star [<pkg>...]
npm unstar [<pkg>...]
```
### Description
"Starring" a package means that you have some interest in it. It's
a vaguely positive way to show that you care.
"Unstarring" is the same thing, but in reverse.
It's a boolean thing. Starring repeatedly has no additional effect.
### See Also
* [npm view](/cli-commands/npm-view)
* [npm whoami](/cli-commands/npm-whoami)
* [npm adduser](/cli-commands/npm-adduser)
deps/npm/docs/content/cli-commands/npm-stars.md
Vendored Executable
+29
View File
@@ -0,0 +1,29 @@
---
section: cli-commands
title: npm-stars
description: View packages marked as favorites
---
# npm-stars
## View packages marked as favorites
### Synopsis
```bash
npm stars [<user>]
```
### Description
If you have starred a lot of neat things and want to find them again
quickly this command lets you do just that.
You may also want to see your friend's favorite packages, in this case
you will most certainly enjoy this command.
### See Also
* [npm star](/cli-commands/npm-star)
* [npm view](/cli-commands/npm-view)
* [npm whoami](/cli-commands/npm-whoami)
* [npm adduser](/cli-commands/npm-adduser)
deps/npm/docs/content/cli-commands/npm-start.md
Vendored Executable
+33
View File
@@ -0,0 +1,33 @@
---
section: cli-commands
title: npm-start
description: Start a package
---
# npm-start
## Start a package
### Synopsis
```bash
npm start [-- <args>]
```
### Description
This runs an arbitrary command specified in the package's `"start"` property of
its `"scripts"` object. If no `"start"` property is specified on the
`"scripts"` object, it will run `node server.js`.
As of [`npm@2.0.0`](https://blog.npmjs.org/post/98131109725/npm-2-0-0), you can
use custom arguments when executing scripts. Refer to [`npm-run-script`](npm-run-script) for
more details.
### See Also
* [npm run-script](/cli-commands/npm-run-script)
* [npm scripts](/using-npm/scripts)
* [npm test](/cli-commands/npm-test)
* [npm restart](/cli-commands/npm-restart)
* [npm stop](/cli-commands/npm-stop)
deps/npm/docs/content/cli-commands/npm-stop.md
Vendored Executable
+27
View File
@@ -0,0 +1,27 @@
---
section: cli-commands
title: npm-stop
description: Stop a package
---
# npm-stop
## Stop a package
### Synopsis
```bash
npm stop [-- <args>]
```
### Description
This runs a package's "stop" script, if one was provided.
### See Also
* [npm run-script](/cli-commands/npm-run-script)
* [npm scripts](/using-npm/scripts)
* [npm test](/cli-commands/npm-test)
* [npm start](/cli-commands/npm-start)
* [npm restart](/cli-commands/npm-restart)
deps/npm/doc/cli/npm-team.md → deps/npm/docs/content/cli-commands/npm-team.md
Vendored Regular → Executable
+23 -14
View File
@@ -1,19 +1,28 @@
npm-team(1) -- Manage organization teams and team memberships
=============================================================
---
section: cli-commands
title: npm-team
description: Manage organization teams and team memberships
---
## SYNOPSIS
# npm-team
npm team create <scope:team>
npm team destroy <scope:team>
## Manage organization teams and team memberships
npm team add <scope:team> <user>
npm team rm <scope:team> <user>
### Synopsis
npm team ls <scope>|<scope:team>
```bash
npm team create <scope:team>
npm team destroy <scope:team>
npm team edit <scope:team>
npm team add <scope:team> <user>
npm team rm <scope:team> <user>
## DESCRIPTION
npm team ls <scope>|<scope:team>
npm team edit <scope:team>
```
### Description
Used to manage teams in organizations, and change team memberships. Does not
handle permissions for packages.
@@ -37,7 +46,7 @@ when operating on them, separated by a colon (`:`). That is, if you have a
* edit:
Edit a current team.
## DETAILS
### Details
`npm team` always operates directly on the current registry, configurable from
the command line using `--registry=<registry url>`.
@@ -52,7 +61,7 @@ is done through the website, not the npm CLI.
To use teams to manage permissions on packages belonging to your organization,
use the `npm access` command to grant or revoke the appropriate permissions.
## SEE ALSO
### See Also
* npm-access(1)
* npm-registry(7)
* [npm access](/cli-commands/npm-access)
* [npm registry](/using-npm/registry)
deps/npm/docs/content/cli-commands/npm-test.md
Vendored Executable
+29
View File
@@ -0,0 +1,29 @@
---
section: cli-commands
title: npm-test
description: Test a package
---
# npm-test
## Test a package
### Synopsis
```bash
npm test [-- <args>]
aliases: t, tst
```
### Description
This runs a package's "test" script, if one was provided.
### See Also
* [npm run-script](/cli-commands/npm-run-script)
* [npm scripts](/using-npm/scripts)
* [npm start](/cli-commands/npm-start)
* [npm restart](/cli-commands/npm-restart)
* [npm stop](/cli-commands/npm-stop)
deps/npm/doc/cli/npm-token.md → deps/npm/docs/content/cli-commands/npm-token.md
Vendored Regular → Executable
+18 -9
View File
@@ -1,20 +1,29 @@
npm-token(1) -- Manage your authentication tokens
=================================================
---
section: cli-commands
title: npm-token
description: Manage your authentication tokens
---
## SYNOPSIS
# npm-token
npm token list [--json|--parseable]
npm token create [--read-only] [--cidr=1.1.1.1/24,2.2.2.2/16]
npm token revoke <id|token>
## Manage your authentication tokens
## DESCRIPTION
### Synopsis
```bash
npm token list [--json|--parseable]
npm token create [--read-only] [--cidr=1.1.1.1/24,2.2.2.2/16]
npm token revoke <id|token>
```
### Description
This lets you list, create and revoke authentication tokens.
* `npm token list`:
Shows a table of all active authentication tokens. You can request this as
JSON with `--json` or tab-separated values with `--parseable`.
```
```bash
+--------+---------+------------+----------+----------------+
| id | token | created | read-only | CIDR whitelist |
+--------+---------+------------+----------+----------------+
@@ -40,7 +49,7 @@ This lets you list, create and revoke authentication tokens.
limit use of this token to. This will prompt you for your password, and, if you have
two-factor authentication enabled, an otp.
```
```bash
+----------------+--------------------------------------+
| token | a73c9572-f1b9-8983-983d-ba3ac3cc913d |
+----------------+--------------------------------------+
deps/npm/docs/content/cli-commands/npm-uninstall.md
Vendored Executable
+64
View File
@@ -0,0 +1,64 @@
---
section: cli-commands
title: npm-uninstall
description: Remove a package
---
# npm-uninstall
## Remove a package
### Synopsis
```bash
npm uninstall [<@scope>/]<pkg>[@<version>]... [-S|--save|-D|--save-dev|-O|--save-optional|--no-save]
aliases: remove, rm, r, un, unlink
```
### Description
This uninstalls a package, completely removing everything npm installed
on its behalf.
Example:
```bash
npm uninstall sax
```
In global mode (ie, with `-g` or `--global` appended to the command),
it uninstalls the current package context as a global package.
`npm uninstall` takes 3 exclusive, optional flags which save or update
the package version in your main package.json:
* `-S, --save`: Package will be removed from your `dependencies`.
* `-D, --save-dev`: Package will be removed from your `devDependencies`.
* `-O, --save-optional`: Package will be removed from your `optionalDependencies`.
* `--no-save`: Package will not be removed from your `package.json` file.
Further, if you have an `npm-shrinkwrap.json` then it will be updated as
well.
Scope is optional and follows the usual rules for [`npm-scope`](snpm-scope).
Examples:
```bash
npm uninstall sax --save
npm uninstall @myorg/privatepackage --save
npm uninstall node-tap --save-dev
npm uninstall dtrace-provider --save-optional
npm uninstall lodash --no-save
```
### See Also
* [npm prune](/cli-commands/npm-prune)
* [npm install](/cli-commands/npm-install)
* [npm folders](/configuring-npm/folders)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
deps/npm/doc/cli/npm-unpublish.md → deps/npm/docs/content/cli-commands/npm-unpublish.md
Vendored Regular → Executable
+22 -13
View File
@@ -1,11 +1,20 @@
npm-unpublish(1) -- Remove a package from the registry
======================================================
---
section: cli-commands
title: npm-unpublish
description: Remove a package from the registry
---
## SYNOPSIS
# npm-unpublish
npm unpublish [<@scope>/]<pkg>[@<version>]
## Remove a package from the registry
## WARNING
### Synopsis
```bash
npm unpublish [<@scope>/]<pkg>[@<version>]
```
### Warning
**It is generally considered bad behavior to remove versions of a library
that others are depending on!**
@@ -15,7 +24,7 @@ instead, if your intent is to encourage users to upgrade.
There is plenty of room on the registry.
## DESCRIPTION
### Description
This removes a package version from the registry, deleting its
entry and removing the tarball.
@@ -34,12 +43,12 @@ only allowed with versions published in the last 72 hours. If you
are trying to unpublish a version published longer ago than that,
contact support@npmjs.com.
The scope is optional and follows the usual rules for `npm-scope(7)`.
The scope is optional and follows the usual rules for [`npm-scope`](/docs/using-npm/scope).
## SEE ALSO
### See Also
* npm-deprecate(1)
* npm-publish(1)
* npm-registry(7)
* npm-adduser(1)
* npm-owner(1)
* [npm deprecate](/cli-commands/npm-deprecate)
* [npm publish](/cli-commands/npm-publish)
* [npm registry](/using-npm/registry)
* [npm adduser](/cli-commands/npm-adduser)
* [npm owner](/cli-commands/npm-owner)
deps/npm/doc/cli/npm-update.md → deps/npm/docs/content/cli-commands/npm-update.md
Vendored Regular → Executable
+32 -23
View File
@@ -1,13 +1,22 @@
npm-update(1) -- Update a package
=================================
---
section: cli-commands
title: npm-update
description: Update a package
---
## SYNOPSIS
# npm-update
npm update [-g] [<pkg>...]
## Update a package
aliases: up, upgrade
### Synopsis
## DESCRIPTION
```bash
npm update [-g] [<pkg>...]
aliases: up, upgrade
```
### Description
This command will update all the packages listed to the latest version
(specified by the `tag` config), respecting semver.
@@ -30,7 +39,7 @@ As of `npm@5.0.0`, the `npm update` will change `package.json` to save the
new version as the minimum required dependency. To get the old behavior,
use `npm update --no-save`.
## EXAMPLES
### Example
IMPORTANT VERSION NOTE: these examples assume `npm@2.6.1` or later. For
older versions of `npm`, you must specify `--depth 0` to get the behavior
@@ -39,7 +48,7 @@ described below.
For the examples below, assume that the current package is `app` and it depends
on dependencies, `dep1` (`dep2`, .. etc.). The published versions of `dep1` are:
```
```json
{
"dist-tags": { "latest": "1.2.2" },
"versions": [
@@ -56,11 +65,11 @@ on dependencies, `dep1` (`dep2`, .. etc.). The published versions of `dep1` are
}
```
### Caret Dependencies
#### Caret Dependencies
If `app`'s `package.json` contains:
```
```json
"dependencies": {
"dep1": "^1.1.1"
}
@@ -69,11 +78,11 @@ If `app`'s `package.json` contains:
Then `npm update` will install `dep1@1.2.2`, because `1.2.2` is `latest` and
`1.2.2` satisfies `^1.1.1`.
### Tilde Dependencies
#### Tilde Dependencies
However, if `app`'s `package.json` contains:
```
```json
"dependencies": {
"dep1": "~1.1.1"
}
@@ -84,11 +93,11 @@ tag points to `1.2.2`, this version does not satisfy `~1.1.1`, which is equivale
to `>=1.1.1 <1.2.0`. So the highest-sorting version that satisfies `~1.1.1` is used,
which is `1.1.2`.
### Caret Dependencies below 1.0.0
#### Caret Dependencies below 1.0.0
Suppose `app` has a caret dependency on a version below `1.0.0`, for example:
```
```json
"dependencies": {
"dep1": "^0.2.0"
}
@@ -99,7 +108,7 @@ versions which satisfy `^0.2.0`.
If the dependence were on `^0.4.0`:
```
```json
"dependencies": {
"dep1": "^0.4.0"
}
@@ -109,7 +118,7 @@ Then `npm update` will install `dep1@0.4.1`, because that is the highest-sorting
version that satisfies `^0.4.0` (`>= 0.4.0 <0.5.0`)
### Updating Globally-Installed Packages
#### Updating Globally-Installed Packages
`npm update -g` will apply the `update` action to each globally installed
package that is `outdated` -- that is, has a version that is different from
@@ -119,11 +128,11 @@ NOTE: If a package has been upgraded to a version newer than `latest`, it will
be _downgraded_.
## SEE ALSO
### See Also
* npm-install(1)
* npm-outdated(1)
* npm-shrinkwrap(1)
* npm-registry(7)
* npm-folders(5)
* npm-ls(1)
* [npm install](/cli-commands/npm-install)
* [npm outdated](/cli-commands/npm-outdated)
* [npm shrinkwrap](/cli-commands/npm-shrinkwrap)
* [npm registry](/using-npm/registry)
* [npm folders](/configuring-npm/folders)
* [npm ls](/cli-commands/npm-ls)
deps/npm/doc/cli/npm-version.md → deps/npm/docs/content/cli-commands/npm-version.md
Vendored Regular → Executable
+42 -27
View File
@@ -1,15 +1,24 @@
npm-version(1) -- Bump a package version
========================================
---
section: cli-commands
title: npm-version
description: Bump a package version
---
## SYNOPSIS
# npm-version
npm version [<newversion> | major | minor | patch | premajor | preminor | prepatch | prerelease [--preid=<prerelease-id>] | from-git]
## Bump a package version
'npm [-v | --version]' to print npm version
'npm view <pkg> version' to view a package's published version
'npm ls' to inspect current package/dependency versions
### Synopsis
## DESCRIPTION
```bash
npm version [<newversion> | major | minor | patch | premajor | preminor | prepatch | prerelease [--preid=<prerelease-id>] | from-git]
'npm [-v | --version]' to print npm version
'npm view <pkg> version' to view a package's published version
'npm ls' to inspect current package/dependency versions
```
### Description
Run this in a package directory to bump the version and write the new
data back to `package.json`, `package-lock.json`, and, if present, `npm-shrinkwrap.json`.
@@ -31,20 +40,24 @@ use it as a commit message when creating a version commit. If the
`message` config contains `%s` then that will be replaced with the
resulting version number. For example:
npm version patch -m "Upgrade to %s for reasons"
```bash
npm version patch -m "Upgrade to %s for reasons"
```
If the `sign-git-tag` config is set, then the tag will be signed using
the `-s` flag to git. Note that you must have a default GPG key set up
in your git config for this to work properly. For example:
$ npm config set sign-git-tag true
$ npm version patch
```bash
$ npm config set sign-git-tag true
$ npm version patch
You need a passphrase to unlock the secret key for
user: "isaacs (http://blog.izs.me/) <i@izs.me>"
2048-bit RSA key, ID 6C481CF6, created 2010-08-31
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:
Enter passphrase:
```
If `preversion`, `version`, or `postversion` are in the `scripts` property of
the package.json, they will be executed as part of running `npm version`.
@@ -66,19 +79,21 @@ The exact order of execution is as follows:
Take the following example:
```json
"scripts": {
"preversion": "npm test",
"version": "npm run build && git add -A dist",
"postversion": "git push && git push --tags && rm -rf build/temp"
}
```
This runs all your tests, and proceeds only if they pass. Then runs your `build` script, and
adds everything in the `dist` directory to the commit. After the commit, it pushes the new commit
and tag up to the server, and deletes the `build/temp` directory.
## CONFIGURATION
### Configuration
### allow-same-version
#### allow-same-version
* Default: false
* Type: Boolean
@@ -86,21 +101,21 @@ and tag up to the server, and deletes the `build/temp` directory.
Prevents throwing an error when `npm version` is used to set the new version
to the same value as the current version.
### git-tag-version
#### git-tag-version
* Default: true
* Type: Boolean
Commit and tag the version change.
### commit-hooks
#### commit-hooks
* Default: true
* Type: Boolean
Run git commit hooks when committing the version change.
### sign-git-tag
#### sign-git-tag
* Default: false
* Type: Boolean
@@ -109,11 +124,11 @@ Pass the `-s` flag to git to sign the tag.
Note that you must have a default GPG key set up in your git config for this to work properly.
## SEE ALSO
### See Also
* npm-init(1)
* npm-run-script(1)
* npm-scripts(7)
* package.json(5)
* semver(7)
* config(7)
* [npm init](/cli-commands/npm-init)
* [npm run-script](/cli-commands/npm-run-script)
* [npm scripts](/using-npm/scripts)
* [package.json](/docs/configuring-npm/package-json)
* [semver](/using-npm/semver)
* [config](/using-npm/config)
deps/npm/doc/cli/npm-view.md → deps/npm/docs/content/cli-commands/npm-view.md
Vendored Regular → Executable
+53 -25
View File
@@ -1,13 +1,22 @@
npm-view(1) -- View registry info
=================================
---
section: cli-commands
title: npm-view
description: View registry info
---
## SYNOPSIS
# npm-view
npm view [<@scope>/]<name>[@<version>] [<field>[.<subfield>]...]
## View registry info
aliases: info, show, v
### Synopsis
## DESCRIPTION
```bash
npm view [<@scope>/]<name>[@<version>] [<field>[.<subfield>]...]
aliases: info, show, v
```
### Description
This command shows data about a package and prints it to the stream
referenced by the `outfd` config, which defaults to stdout.
@@ -15,7 +24,9 @@ referenced by the `outfd` config, which defaults to stdout.
To show the package registry entry for the `connect` package, you can do
this:
npm view connect
```bash
npm view connect
```
The default version is "latest" if unspecified.
@@ -23,56 +34,74 @@ Field names can be specified after the package descriptor.
For example, to show the dependencies of the `ronn` package at version
0.3.5, you could do the following:
npm view ronn@0.3.5 dependencies
```bash
npm view ronn@0.3.5 dependencies
```
You can view child fields by separating them with a period.
To view the git repository URL for the latest version of npm, you could
do this:
npm view npm repository.url
```bash
npm view npm repository.url
```
This makes it easy to view information about a dependency with a bit of
shell scripting. For example, to view all the data about the version of
opts that ronn depends on, you can do this:
npm view opts@$(npm view ronn dependencies.opts)
```bash
npm view opts@$(npm view ronn dependencies.opts)
```
For fields that are arrays, requesting a non-numeric field will return
all of the values from the objects in the list. For example, to get all
the contributor names for the "express" project, you can do this:
npm view express contributors.email
```bash
npm view express contributors.email
```
You may also use numeric indices in square braces to specifically select
an item in an array field. To just get the email address of the first
contributor in the list, you can do this:
npm view express contributors[0].email
```bash
npm view express contributors[0].email
```
Multiple fields may be specified, and will be printed one after another.
For example, to get all the contributor names and email addresses, you
can do this:
npm view express contributors.name contributors.email
```bash
npm view express contributors.name contributors.email
```
"Person" fields are shown as a string if they would be shown as an
object. So, for example, this will show the list of npm contributors in
the shortened string format. (See `package.json(5)` for more on this.)
the shortened string format. (See [`package.json`](/docs/configuring-npm/package.json) for more on this.)
npm view npm contributors
```bash
npm view npm contributors
```
If a version range is provided, then data will be printed for every
matching version of the package. This will show which version of jsdom
was required by each matching version of yui3:
npm view yui3@'>0.5.4' dependencies.jsdom
```bash
npm view yui3@'>0.5.4' dependencies.jsdom
```
To show the `connect` package version history, you can do
this:
npm view connect versions
```bash
npm view connect versions
```
## OUTPUT
### Output
If only a single string field for a single version is output, then it
will not be colorized or quoted, so as to enable piping the output to
@@ -86,11 +115,10 @@ will be prefixed with the version it applies to.
If multiple fields are requested, than each of them are prefixed with
the field name.
## SEE ALSO
### See Also
* npm-search(1)
* npm-registry(7)
* npm-config(1)
* npm-config(7)
* npmrc(5)
* npm-docs(1)
* [npm search](/cli-commands/npm-search)
* [npm registry](/using-npm/registry)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [npm docs](/cli-commands/npm-docs)
deps/npm/docs/content/cli-commands/npm-whoami.md
Vendored Executable
+24
View File
@@ -0,0 +1,24 @@
---
section: cli-commands
title: npm-whoami
description: Display npm username
---
# npm-whoami
## Display npm username
### Synopsis
```bash
npm whoami [--registry <registry>]
```
### Description
Print the `username` config to standard output.
### See Also
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [npm adduser](/cli-commands/npm-adduser)
deps/npm/doc/cli/npm.md → deps/npm/docs/content/cli-commands/npm.md
Vendored Regular → Executable
+33 -29
View File
@@ -1,15 +1,23 @@
npm(1) -- javascript package manager
====================================
---
section: cli-commands
title: npm
description: javascript package manager
---
## SYNOPSIS
# npm
## javascript package manager
npm <command> [args]
### Synopsis
## VERSION
```bash
npm <command> [args]
```
### Version
@VERSION@
## DESCRIPTION
### Description
npm is the package manager for the Node JavaScript platform. It puts
modules in place so that node can find them, and manages dependency
@@ -21,7 +29,7 @@ programs.
Run `npm help` to get a list of available commands.
## IMPORTANT
### Important
npm is configured to use npm, Inc.'s public registry at
https://registry.npmjs.org by default. Use of the npm public registry is
@@ -31,17 +39,17 @@ You can configure npm to use any compatible registry you like, and even run
your own registry. Use of someone else's registry may be governed by their
terms of use.
## INTRODUCTION
### Introduction
You probably got npm because you want to install stuff.
Use `npm install blerg` to install the latest version of "blerg". Check out
`npm-install(1)` for more info. It can do a lot of stuff.
[`npm-install`](npm-install) for more info. It can do a lot of stuff.
Use the `npm search` command to show everything that's available.
Use `npm ls` to show everything you've installed.
## DEPENDENCIES
### Dependencies
If a package references to another package with a git URL, npm depends
on a preinstalled git.
@@ -57,9 +65,9 @@ For more information visit
[the node-gyp repository](https://github.com/TooTallNate/node-gyp) and
the [node-gyp Wiki](https://github.com/TooTallNate/node-gyp/wiki).
## DIRECTORIES
### Directories
See `npm-folders(5)` to learn about where npm puts stuff.
See [`npm-folders`](/docs/configuring-npm/folders) to learn about where npm puts stuff.
In particular, npm has two modes of operation:
@@ -74,13 +82,13 @@ In particular, npm has two modes of operation:
Local mode is the default. Use `-g` or `--global` on any command to
operate in global mode instead.
## DEVELOPER USAGE
### Developer Usage
If you're using npm to develop and publish your code, check out the
following help topics:
* json:
Make a package.json file. See `package.json(5)`.
Make a package.json file. See [`package.json`](/docs/configuring-npm/package.json).
* link:
For linking your current working code into Node's path, so that you
don't have to reinstall every time you make a change. Use
@@ -95,7 +103,7 @@ following help topics:
* publish:
Use the `npm publish` command to upload your code to the registry.
## CONFIGURATION
#### Configuration
npm is extremely configurable. It reads its configuration options from
5 places.
@@ -121,9 +129,9 @@ npm is extremely configurable. It reads its configuration options from
npm's default configuration options are defined in
lib/utils/config-defs.js. These must not be changed.
See `npm-config(7)` for much much more information.
See [`npm-config`](/docs/using-npm/config) for much much more information.
## CONTRIBUTIONS
### Contributions
Patches welcome!
@@ -134,7 +142,7 @@ the contributing guidelines and check the issues list.
* [Bug tracker](https://npm.community/c/bugs)
* [Support tracker](https://npm.community/c/support)
## BUGS
### Bugs
When you find issues, please report them:
@@ -146,20 +154,16 @@ for help in the [support forum](https://npm.community/c/support) if you're
unsure if it's actually a bug or are having trouble coming up with a detailed
reproduction to report.
## AUTHOR
### Author
[Isaac Z. Schlueter](http://blog.izs.me/) ::
[isaacs](https://github.com/isaacs/) ::
[@izs](https://twitter.com/izs) ::
<i@izs.me>
## SEE ALSO
* npm-help(1)
* README
* package.json(5)
* npm-install(1)
* npm-config(1)
* npm-config(7)
* npmrc(5)
* npm-index(7)
### See Also
* [npm help](/cli-commands/npm-help)
* [package.json](/configuring-npm/package-json)
* [npm install](/cli-commands/npm-install)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
deps/npm/doc/files/npm-folders.md → deps/npm/docs/content/configuring-npm/folders.md
Vendored Regular → Executable
+60 -49
View File
@@ -1,13 +1,20 @@
npm-folders(5) -- Folder Structures Used by npm
===============================================
---
section: configuring-npm
title: folders
description: Folder Structures Used by npm
---
## DESCRIPTION
# folders
## Folder Structures Used by npm
### Description
npm puts various things on your computer. That's its job.
This document will tell you what it puts where.
### tl;dr
#### tl;dr
* Local install (default): puts stuff in `./node_modules` of the current
package root.
@@ -17,7 +24,7 @@ This document will tell you what it puts where.
* Install it **globally** if you're going to run it on the command line.
* If you need both, then install it in both places, or use `npm link`.
### prefix Configuration
#### prefix Configuration
The `prefix` config defaults to the location where node is installed.
On most systems, this is `/usr/local`. On Windows, it's `%AppData%\npm`.
@@ -28,7 +35,7 @@ When the `global` flag is set, npm installs things into this prefix.
When it is not set, it uses the root of the current package, or the
current working directory if not in a package already.
### Node Modules
#### Node Modules
Packages are dropped into the `node_modules` folder under the `prefix`.
When installing locally, this means that you can
@@ -42,12 +49,12 @@ Global installs on Windows go to `{prefix}/node_modules` (that is, no
Scoped packages are installed the same way, except they are grouped together
in a sub-folder of the relevant `node_modules` folder with the name of that
scope prefix by the @ symbol, e.g. `npm install @myorg/package` would place
the package in `{prefix}/node_modules/@myorg/package`. See `scope(7)` for
the package in `{prefix}/node_modules/@myorg/package`. See [`scope`](/docs/using-npm/scope) for
more details.
If you wish to `require()` a package, then install it locally.
### Executables
#### Executables
When in global mode, executables are linked into `{prefix}/bin` on Unix,
or directly into `{prefix}` on Windows.
@@ -57,7 +64,7 @@ When in local mode, executables are linked into
through npm. (For example, so that a test runner will be in the path
when you run `npm test`.)
### Man Pages
#### Man Pages
When in global mode, man pages are linked into `{prefix}/share/man`.
@@ -65,14 +72,14 @@ When in local mode, man pages are not installed.
Man pages are not installed on Windows systems.
### Cache
#### Cache
See `npm-cache(1)`. Cache files are stored in `~/.npm` on Posix, or
See [`npm-cache`](/docs/cli-commands/npm-cache). Cache files are stored in `~/.npm` on Posix, or
`%AppData%/npm-cache` on Windows.
This is controlled by the `cache` configuration param.
### Temp Files
#### Temp Files
Temporary files are stored by default in the folder specified by the
`tmp` config, which defaults to the TMPDIR, TMP, or TEMP environment
@@ -81,7 +88,7 @@ variables, or `/tmp` on Unix and `c:\windows\temp` on Windows.
Temp files are given a unique folder under this root for each run of the
program, and are deleted upon successful exit.
## More Information
### More Information
When installing locally, npm first tries to find an appropriate
`prefix` folder. This is so that `npm install foo@1.2.3` will install
@@ -105,7 +112,7 @@ foo's dependencies are similarly unpacked into
Any bin files are symlinked to `./node_modules/.bin/`, so that they may
be found by npm scripts when necessary.
### Global Installation
#### Global Installation
If the `global` configuration is set to true, then npm will
install packages "globally".
@@ -113,7 +120,7 @@ install packages "globally".
For global installation, packages are installed roughly the same way,
but using the folders described above.
### Cycles, Conflicts, and Folder Parsimony
#### Cycles, Conflicts, and Folder Parsimony
Cycles are handled using the property of node's module system that it
walks up the directories looking for `node_modules` folders. So, at every
@@ -142,32 +149,36 @@ highest level possible, below the localized "target" folder.
Consider this dependency graph:
foo
+-- blerg@1.2.5
+-- bar@1.2.3
| +-- blerg@1.x (latest=1.3.7)
| +-- baz@2.x
| | `-- quux@3.x
| | `-- bar@1.2.3 (cycle)
| `-- asdf@*
`-- baz@1.2.3
`-- quux@3.x
`-- bar
```bash
foo
+-- blerg@1.2.5
+-- bar@1.2.3
| +-- blerg@1.x (latest=1.3.7)
| +-- baz@2.x
| | `-- quux@3.x
| | `-- bar@1.2.3 (cycle)
| `-- asdf@*
`-- baz@1.2.3
`-- quux@3.x
`-- bar
```
In this case, we might expect a folder structure like this:
foo
+-- node_modules
+-- blerg (1.2.5) <---[A]
+-- bar (1.2.3) <---[B]
| `-- node_modules
| +-- baz (2.0.2) <---[C]
| | `-- node_modules
| | `-- quux (3.2.0)
| `-- asdf (2.3.4)
`-- baz (1.2.3) <---[D]
`-- node_modules
`-- quux (3.2.0) <---[E]
```bash
foo
+-- node_modules
+-- blerg (1.2.5) <---[A]
+-- bar (1.2.3) <---[B]
| `-- node_modules
| +-- baz (2.0.2) <---[C]
| | `-- node_modules
| | `-- quux (3.2.0)
| `-- asdf (2.3.4)
`-- baz (1.2.3) <---[D]
`-- node_modules
`-- quux (3.2.0) <---[E]
```
Since foo depends directly on `bar@1.2.3` and `baz@1.2.3`, those are
installed in foo's `node_modules` folder.
@@ -191,7 +202,7 @@ dependency on bar is satisfied by the parent folder copy installed at [B].
For a graphical breakdown of what is installed where, use `npm ls`.
### Publishing
#### Publishing
Upon publishing, npm will look in the `node_modules` folder. If any of
the items there are not in the `bundledDependencies` array, then they will
@@ -199,15 +210,15 @@ not be included in the package tarball.
This allows a package maintainer to install all of their dependencies
(and dev dependencies) locally, but only re-publish those items that
cannot be found elsewhere. See `package.json(5)` for more information.
cannot be found elsewhere. See [`package.json`](/docs/configuring-npm/package.json) for more information.
## SEE ALSO
### See also
* package.json(5)
* npm-install(1)
* npm-pack(1)
* npm-cache(1)
* npm-config(1)
* npmrc(5)
* npm-config(7)
* npm-publish(1)
* [package.json](/configuring-npm/package-json)
* [npm install](/cli-commands/npm-install)
* [npm pack](/cli-commands/npm-pack)
* [npm cache](/cli-commands/npm-cache)
* [npm config](/cli-commands/npm-config)
* [npmrc](/configuring-npm/npmrc)
* [config](/using-npm/config)
* [npm publish](/cli-commands/npm-publish)
deps/npm/docs/content/configuring-npm/install.md
Vendored
+66
View File
@@ -0,0 +1,66 @@
---
section: configuring-npm
title: install
description: Download and install node and npm
---
# Download and Install npm
To publish and install packages to and from the public npm registry, you must install Node.js and the npm command line interface using either a Node version manager or a Node installer. **We strongly recommend using a Node version manager to install Node.js and npm.** We do not recommend using a Node installer, since the Node installation process installs npm in a directory with local permissions and can cause permissions errors when you run npm packages globally.
### Overview
- [Checking your version of npm and Node.js](#checking-your-version-of-npm-and-node-js)
- [Using a Node version manager to install Node.js and npm](#using-a-node-version-manager-to-install-node-js-and-npm)
- [Using a Node installer to install Node.js and npm](#using-a-node-installer-to-install-node-js-and-npm)
### Checking your version of npm and Node.js
To see if you already have Node.js and npm installed and check the installed version, run the following commands:
```
node -v
npm -v
```
### Using a Node version manager to install Node.js and npm
Node version managers allow you to install and switch between multiple versions of Node.js and npm on your system so you can test your applications on multiple versions of npm to ensure they work for users on different versions.
#### OSX or Linux Node version managers
* [nvm](https://github.com/creationix/nvm)
* [n](https://github.com/tj/n)
#### Windows Node version managers
* [nodist](https://github.com/marcelklehr/nodist)
* [nvm-windows](https://github.com/coreybutler/nvm-windows)
### Using a Node installer to install Node.js and npm
If you are unable to use a Node version manager, you can use a Node installer to install both Node.js and npm on your system.
* [Node.js installer](https://nodejs.org/en/download/)
* [NodeSource installer](https://github.com/nodesource/distributions). If you use Linux, we recommend that you use a NodeSource installer.
#### OS X or Windows Node installers
If you're using OS X or Windows, use one of the installers from the [Node.js download page](https://nodejs.org/en/download/). Be sure to install the version labeled **LTS**. Other versions have not yet been tested with npm.
#### Linux or other operating systems Node installers
If you're using Linux or another operating system, use one of the following installers:
- [NodeSource installer](https://github.com/nodesource/distributions) (recommended)
- One of the installers on the [Node.js download page](https://nodejs.org/en/download/)
Or see [this page](https://nodejs.org/en/download/package-manager/) to install npm for Linux in the way many Linux developers prefer.
#### Less-common operating systems
For more information on installing Node.js on a variety of operating systems, see [this page][pkg-mgr].
[pkg-mgr]: https://nodejs.org/en/download/package-manager/
deps/npm/doc/files/npmrc.md → deps/npm/docs/content/configuring-npm/npmrc.md
Vendored Regular → Executable
+34 -21
View File
@@ -1,7 +1,14 @@
npmrc(5) -- The npm config files
================================
---
section: configuring-npm
title: npmrc
description: The npm config files
---
## DESCRIPTION
# npmrc
## The npm config files
### Description
npm gets its config settings from the command line, environment
variables, and `npmrc` files.
@@ -9,9 +16,9 @@ variables, and `npmrc` files.
The `npm config` command can be used to update and edit the contents
of the user and global npmrc files.
For a list of available configuration options, see npm-config(7).
For a list of available configuration options, see [npm-config](/docs/using-npm/config).
## FILES
### Files
The four relevant files are:
@@ -24,7 +31,9 @@ All npm config files are an ini-formatted list of `key = value`
parameters. Environment variables can be replaced using
`${VARIABLE_NAME}`. For example:
prefix = ${HOME}/.npm-packages
```bash
prefix = ${HOME}/.npm-packages
```
Each of these files is loaded, and config options are resolved in
priority order. For example, a setting in the userconfig file would
@@ -33,8 +42,10 @@ override the setting in the globalconfig file.
Array values are specified by adding "[]" after the key name. For
example:
key[] = "first value"
key[] = "second value"
```bash
key[] = "first value"
key[] = "second value"
```
#### Comments
@@ -42,11 +53,13 @@ Lines in `.npmrc` files are interpreted as comments when they begin with a `;` o
For example:
# last modified: 01 Jan 2016
; Set a new registry for a scoped package
@myscope:registry=https://mycustomregistry.example.org
```bash
# last modified: 01 Jan 2016
; Set a new registry for a scoped package
@myscope:registry=https://mycustomregistry.example.org
```
### Per-project config file
#### Per-project config file
When working locally in a project, a `.npmrc` file in the root of the
project (ie, a sibling of `node_modules` and `package.json`) will set
@@ -60,18 +73,18 @@ globally, or in a different location.
Additionally, this file is not read in global mode, such as when running
`npm install -g`.
### Per-user config file
#### Per-user config file
`$HOME/.npmrc` (or the `userconfig` param, if set in the environment
or on the command line)
### Global config file
#### Global config file
`$PREFIX/etc/npmrc` (or the `globalconfig` param, if set above):
This file is an ini-file formatted list of `key = value` parameters.
Environment variables can be replaced as above.
### Built-in config file
#### Built-in config file
`path/to/npm/itself/npmrc`
@@ -81,10 +94,10 @@ script that comes with npm. This is primarily for distribution
maintainers to override default configs in a standard and consistent
manner.
## SEE ALSO
### See also
* npm-folders(5)
* npm-config(1)
* npm-config(7)
* package.json(5)
* npm(1)
* [npm folders](/configuring-npm/folders)
* [npm config](/cli-commands/npm-config)
* [config](/using-npm/config)
* [package.json](/configuring-npm/package-json)
* [npm](/cli-commands/npm)
deps/npm/doc/files/package.json.md → deps/npm/docs/content/configuring-npm/package-json.md
Vendored Regular → Executable
+317 -223
View File
@@ -1,15 +1,22 @@
package.json(5) -- Specifics of npm's package.json handling
===========================================================
---
section: configuring-npm
title: package.json
description: Specifics of npm's package.json handling
---
## DESCRIPTION
# package.json
## Specifics of npm's package.json handling
### Description
This document is all you need to know about what's required in your package.json
file. It must be actual JSON, not just a JavaScript object literal.
A lot of the behavior described in this document is affected by the config
settings described in `npm-config(7)`.
settings described in [`npm-config`](/docs/using-npm/config).
## name
### name
If you plan to publish your package, the *most* important things in your
package.json are the name and version fields as they will be required. The name
@@ -40,9 +47,9 @@ Some tips:
already, before you get too attached to it. <https://www.npmjs.com/>
A name can be optionally prefixed by a scope, e.g. `@myorg/mypackage`. See
`npm-scope(7)` for more detail.
[`npm-scope`](/docs/using-npm/scope) for more detail.
## version
### version
If you plan to publish your package, the *most* important things in your
package.json are the name and version fields as they will be required. The name
@@ -54,27 +61,29 @@ Version must be parseable by
[node-semver](https://github.com/isaacs/node-semver), which is bundled
with npm as a dependency. (`npm install semver` to use it yourself.)
More on version numbers and ranges at semver(7).
More on version numbers and ranges at [semver](/docs/using-npm/semver).
## description
### description
Put a description in it. It's a string. This helps people discover your
package, as it's listed in `npm search`.
## keywords
### keywords
Put keywords in it. It's an array of strings. This helps people
discover your package as it's listed in `npm search`.
## homepage
### homepage
The url to the project homepage.
Example:
"homepage": "https://github.com/owner/project#readme"
```json
"homepage": "https://github.com/owner/project#readme"
```
## bugs
### bugs
The url to your project's issue tracker and / or the email address to which
issues should be reported. These are helpful for people who encounter issues
@@ -82,16 +91,18 @@ with your package.
It should look like this:
{ "url" : "https://github.com/owner/project/issues"
, "email" : "project@hostname.com"
}
```json
{ "url" : "https://github.com/owner/project/issues"
, "email" : "project@hostname.com"
}
```
You can specify either one or both values. If you want to provide only a url,
you can specify the value for "bugs" as a simple string instead of an object.
If a url is provided, it will be used by the `npm bugs` command.
## license
### license
You should specify a license for your package so that people know how they are
permitted to use it, and any restrictions you're placing on it.
@@ -99,7 +110,9 @@ permitted to use it, and any restrictions you're placing on it.
If you're using a common license such as BSD-2-Clause or MIT, add a
current SPDX license identifier for the license you're using, like this:
{ "license" : "BSD-3-Clause" }
```json
{ "license" : "BSD-3-Clause" }
```
You can check [the full list of SPDX license IDs](https://spdx.org/licenses/).
Ideally you should pick one that is
@@ -108,69 +121,100 @@ Ideally you should pick one that is
If your package is licensed under multiple common licenses, use an [SPDX license
expression syntax version 2.0 string](https://www.npmjs.com/package/spdx), like this:
{ "license" : "(ISC OR GPL-3.0)" }
```json
{ "license" : "(ISC OR GPL-3.0)" }
```
If you are using a license that hasn't been assigned an SPDX identifier, or if
you are using a custom license, use a string value like this one:
{ "license" : "SEE LICENSE IN <filename>" }
```json
{ "license" : "SEE LICENSE IN <filename>" }
```
Then include a file named `<filename>` at the top level of the package.
Some old packages used license objects or a "licenses" property containing an
array of license objects:
// Not valid metadata
{ "license" :
{ "type" : "ISC"
, "url" : "https://opensource.org/licenses/ISC"
}
}
```json
// Not valid metadata
{ "license" :
{ "type" : "ISC"
, "url" : "https://opensource.org/licenses/ISC"
}
}
// Not valid metadata
{ "licenses" :
[
{ "type": "MIT"
, "url": "https://www.opensource.org/licenses/mit-license.php"
}
, { "type": "Apache-2.0"
, "url": "https://opensource.org/licenses/apache2.0.php"
}
]
// Not valid metadata
{ "licenses" :
[
{ "type": "MIT"
, "url": "https://www.opensource.org/licenses/mit-license.php"
}
, { "type": "Apache-2.0"
, "url": "https://opensource.org/licenses/apache2.0.php"
}
]
}
```
Those styles are now deprecated. Instead, use SPDX expressions, like this:
{ "license": "ISC" }
```json
{ "license": "ISC" }
{ "license": "(MIT OR Apache-2.0)" }
{ "license": "(MIT OR Apache-2.0)" }
```
Finally, if you do not wish to grant others the right to use a private or
unpublished package under any terms:
{ "license": "UNLICENSED" }
```json
{ "license": "UNLICENSED" }
```
Consider also setting `"private": true` to prevent accidental publication.
## people fields: author, contributors
### people fields: author, contributors
The "author" is one person. "contributors" is an array of people. A "person"
is an object with a "name" field and optionally "url" and "email", like this:
{ "name" : "Barney Rubble"
, "email" : "b@rubble.com"
, "url" : "http://barnyrubble.tumblr.com/"
}
```json
{ "name" : "Barney Rubble"
, "email" : "b@rubble.com"
, "url" : "http://barnyrubble.tumblr.com/"
}
```
Or you can shorten that all into a single string, and npm will parse it for you:
"Barney Rubble <b@rubble.com> (http://barnyrubble.tumblr.com/)"
```json
"Barney Rubble <b@rubble.com> (http://barnyrubble.tumblr.com/)"
```
Both email and url are optional either way.
npm also sets a top-level "maintainers" field with your npm user info.
## files
### funding
You can specify an object containing an URL that provides up-to-date
information about ways to help fund development of your package:
"funding": {
"type" : "individual",
"url" : "http://example.com/donate"
}
"funding": {
"type" : "patreon",
"url" : "https://www.patreon.com/my-account"
}
Users can use the `npm fund` subcommand to list the `funding` URLs of all
dependencies of their project, direct and indirect. A shortcut to visit each
funding url is also available when providing the project name such as:
`npm fund <projectname>`.
### files
The optional `files` field is an array of file patterns that describes
the entries to be included when your package is installed as a
@@ -221,7 +265,7 @@ Conversely, some files are always ignored:
* `*.orig`
* `package-lock.json` (use shrinkwrap instead)
## main
### main
The main field is a module ID that is the primary entry point to your program.
That is, if your package is named `foo`, and a user installs it, and then does
@@ -232,13 +276,13 @@ This should be a module ID relative to the root of your package folder.
For most modules, it makes the most sense to have a main script and often not
much else.
## browser
### browser
If your module is meant to be used client-side the browser field should be
used instead of the main field. This is helpful to hint users that it might
rely on primitives that aren't available in Node.js modules. (e.g. `window`)
## bin
### bin
A lot of packages have one or more executable files that they'd like to
install into the PATH. npm makes this pretty easy (in fact, it uses this
@@ -252,7 +296,9 @@ installs.
For example, myapp could have this:
{ "bin" : { "myapp" : "./cli.js" } }
```json
{ "bin" : { "myapp" : "./cli.js" } }
```
So, when you install myapp, it'll create a symlink from the `cli.js` script to
`/usr/local/bin/myapp`.
@@ -260,21 +306,25 @@ So, when you install myapp, it'll create a symlink from the `cli.js` script to
If you have a single executable, and its name should be the name
of the package, then you can just supply it as a string. For example:
{ "name": "my-program"
, "version": "1.2.5"
, "bin": "./path/to/program" }
```json
{ "name": "my-program"
, "version": "1.2.5"
, "bin": "./path/to/program" }
```
would be the same as this:
{ "name": "my-program"
, "version": "1.2.5"
, "bin" : { "my-program" : "./path/to/program" } }
```json
{ "name": "my-program"
, "version": "1.2.5"
, "bin" : { "my-program" : "./path/to/program" } }
```
Please make sure that your file(s) referenced in `bin` starts with
`#!/usr/bin/env node`, otherwise the scripts are started without the node
executable!
## man
### man
Specify either a single file or an array of filenames to put in place for the
`man` program to find.
@@ -282,40 +332,45 @@ Specify either a single file or an array of filenames to put in place for the
If only a single file is provided, then it's installed such that it is the
result from `man <pkgname>`, regardless of its actual filename. For example:
{ "name" : "foo"
, "version" : "1.2.3"
, "description" : "A packaged foo fooer for fooing foos"
, "main" : "foo.js"
, "man" : "./man/doc.1"
}
```json
{ "name" : "foo"
, "version" : "1.2.3"
, "description" : "A packaged foo fooer for fooing foos"
, "main" : "foo.js"
, "man" : "./man/doc.1"
}
```
would link the `./man/doc.1` file in such that it is the target for `man foo`
If the filename doesn't start with the package name, then it's prefixed.
So, this:
{ "name" : "foo"
, "version" : "1.2.3"
, "description" : "A packaged foo fooer for fooing foos"
, "main" : "foo.js"
, "man" : [ "./man/foo.1", "./man/bar.1" ]
}
```json
{ "name" : "foo"
, "version" : "1.2.3"
, "description" : "A packaged foo fooer for fooing foos"
, "main" : "foo.js"
, "man" : [ "./man/foo.1", "./man/bar.1" ]
}
```
will create files to do `man foo` and `man foo-bar`.
Man files must end with a number, and optionally a `.gz` suffix if they are
compressed. The number dictates which man section the file is installed into.
{ "name" : "foo"
, "version" : "1.2.3"
, "description" : "A packaged foo fooer for fooing foos"
, "main" : "foo.js"
, "man" : [ "./man/foo.1", "./man/foo.2" ]
}
```json
{ "name" : "foo"
, "version" : "1.2.3"
, "description" : "A packaged foo fooer for fooing foos"
, "main" : "foo.js"
, "man" : [ "./man/foo.1", "./man/foo.2" ]
}
```
will create entries for `man foo` and `man 2 foo`
## directories
### directories
The CommonJS [Packages](http://wiki.commonjs.org/wiki/Packages/1.0) spec details a
few ways that you can indicate the structure of your package using a `directories`
@@ -324,12 +379,12 @@ you'll see that it has directories for doc, lib, and man.
In the future, this information may be used in other creative ways.
### directories.lib
#### directories.lib
Tell people where the bulk of your library is. Nothing special is done
with the lib folder in any way, but it's useful meta info.
### directories.bin
#### directories.bin
If you specify a `bin` directory in `directories.bin`, all the files in
that folder will be added.
@@ -339,26 +394,26 @@ Because of the way the `bin` directive works, specifying both a
specify individual files, use `bin`, and for all the files in an
existing `bin` directory, use `directories.bin`.
### directories.man
#### directories.man
A folder that is full of man pages. Sugar to generate a "man" array by
walking the folder.
### directories.doc
#### directories.doc
Put markdown files in here. Eventually, these will be displayed nicely,
maybe, someday.
### directories.example
#### directories.example
Put example scripts in here. Someday, it might be exposed in some clever way.
### directories.test
#### directories.test
Put your tests in here. It is currently not exposed, but it might be in the
future.
## repository
### repository
Specify the place where your code lives. This is helpful for people who
want to contribute. If the git repo is on GitHub, then the `npm docs`
@@ -366,15 +421,17 @@ command will be able to find you.
Do it like this:
"repository": {
"type" : "git",
"url" : "https://github.com/npm/cli.git"
}
```json
"repository": {
"type" : "git",
"url" : "https://github.com/npm/cli.git"
}
"repository": {
"type" : "svn",
"url" : "https://v8.googlecode.com/svn/trunk/"
}
"repository": {
"type" : "svn",
"url" : "https://v8.googlecode.com/svn/trunk/"
}
```
The URL should be a publicly available (perhaps read-only) url that can be handed
directly to a VCS program without any modification. It should not be a url to an
@@ -383,50 +440,56 @@ html project page that you put in your browser. It's for computers.
For GitHub, GitHub gist, Bitbucket, or GitLab repositories you can use the same
shortcut syntax you use for `npm install`:
"repository": "npm/npm"
```json
"repository": "npm/npm"
"repository": "github:user/repo"
"repository": "github:user/repo"
"repository": "gist:11081aaa281"
"repository": "gist:11081aaa281"
"repository": "bitbucket:user/repo"
"repository": "bitbucket:user/repo"
"repository": "gitlab:user/repo"
"repository": "gitlab:user/repo"
```
If the `package.json` for your package is not in the root directory (for example
if it is part of a monorepo), you can specify the directory in which it lives:
"repository": {
"type" : "git",
"url" : "https://github.com/facebook/react.git",
"directory": "packages/react-dom"
}
```json
"repository": {
"type" : "git",
"url" : "https://github.com/facebook/react.git",
"directory": "packages/react-dom"
}
```
## scripts
### scripts
The "scripts" property is a dictionary containing script commands that are run
at various times in the lifecycle of your package. The key is the lifecycle
event, and the value is the command to run at that point.
See `npm-scripts(7)` to find out more about writing package scripts.
See [`npm-scripts`](/docs/using-npm/scripts) to find out more about writing package scripts.
## config
### config
A "config" object can be used to set configuration parameters used in package
scripts that persist across upgrades. For instance, if a package had the
following:
{ "name" : "foo"
, "config" : { "port" : "8080" } }
```json
{ "name" : "foo"
, "config" : { "port" : "8080" } }
```
and then had a "start" command that then referenced the
`npm_package_config_port` environment variable, then the user could
override that by doing `npm config set foo:port 8001`.
See `npm-config(7)` and `npm-scripts(7)` for more on package
See [`npm-config`](/docs/using-npm/config) and [`npm-scripts`](/docs/using-npm/scripts) for more on package
configs.
## dependencies
### dependencies
Dependencies are specified in a simple object that maps a package name to a
version range. The version range is a string which has one or more
@@ -436,15 +499,15 @@ tarball or git URL.
**Please do not put test harnesses or transpilers in your
`dependencies` object.** See `devDependencies`, below.
See semver(7) for more details about specifying version ranges.
See [semver](/docs/using-npm/semver) for more details about specifying version ranges.
* `version` Must match `version` exactly
* `>version` Must be greater than `version`
* `>=version` etc
* `<version`
* `<=version`
* `~version` "Approximately equivalent to version" See semver(7)
* `^version` "Compatible with version" See semver(7)
* `~version` "Approximately equivalent to version" See [semver](/docs/using-npm/semver)
* `^version` "Compatible with version" See [semver](/docs/using-npm/semver)
* `1.2.x` 1.2.0, 1.2.1, etc., but not 1.3.0
* `http://...` See 'URLs as Dependencies' below
* `*` Matches any version
@@ -453,39 +516,43 @@ See semver(7) for more details about specifying version ranges.
* `range1 || range2` Passes if either range1 or range2 are satisfied.
* `git...` See 'Git URLs as Dependencies' below
* `user/repo` See 'GitHub URLs' below
* `tag` A specific version tagged and published as `tag` See `npm-dist-tag(1)`
* `tag` A specific version tagged and published as `tag` See [`npm-dist-tag`](/docs/cli-commands/npm-dist-tag)
* `path/path/path` See [Local Paths](#local-paths) below
For example, these are all valid:
{ "dependencies" :
{ "foo" : "1.0.0 - 2.9999.9999"
, "bar" : ">=1.0.2 <2.1.2"
, "baz" : ">1.0.2 <=2.3.4"
, "boo" : "2.0.1"
, "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0"
, "asd" : "http://asdf.com/asdf.tar.gz"
, "til" : "~1.2"
, "elf" : "~1.2.3"
, "two" : "2.x"
, "thr" : "3.3.x"
, "lat" : "latest"
, "dyl" : "file:../dyl"
}
}
```json
{ "dependencies" :
{ "foo" : "1.0.0 - 2.9999.9999"
, "bar" : ">=1.0.2 <2.1.2"
, "baz" : ">1.0.2 <=2.3.4"
, "boo" : "2.0.1"
, "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0"
, "asd" : "http://asdf.com/asdf.tar.gz"
, "til" : "~1.2"
, "elf" : "~1.2.3"
, "two" : "2.x"
, "thr" : "3.3.x"
, "lat" : "latest"
, "dyl" : "file:../dyl"
}
}
```
### URLs as Dependencies
#### URLs as Dependencies
You may specify a tarball URL in place of a version range.
This tarball will be downloaded and installed locally to your package at
install time.
### Git URLs as Dependencies
#### Git URLs as Dependencies
Git urls are of the form:
<protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish> | #semver:<semver>]
```bash
<protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish> | #semver:<semver>]
```
`<protocol>` is one of `git`, `git+ssh`, `git+http`, `git+https`, or
`git+file`.
@@ -499,54 +566,62 @@ specified, then `master` is used.
Examples:
git+ssh://git@github.com:npm/cli.git#v1.0.27
git+ssh://git@github.com:npm/cli#semver:^5.0
git+https://isaacs@github.com/npm/cli.git
git://github.com/npm/cli.git#v1.0.27
```bash
git+ssh://git@github.com:npm/cli.git#v1.0.27
git+ssh://git@github.com:npm/cli#semver:^5.0
git+https://isaacs@github.com/npm/cli.git
git://github.com/npm/cli.git#v1.0.27
```
### GitHub URLs
#### GitHub URLs
As of version 1.1.65, you can refer to GitHub urls as just "foo":
"user/foo-project". Just as with git URLs, a `commit-ish` suffix can be
included. For example:
{
"name": "foo",
"version": "0.0.0",
"dependencies": {
"express": "expressjs/express",
"mocha": "mochajs/mocha#4727d357ea",
"module": "user/repo#feature\/branch"
}
}
```json
{
"name": "foo",
"version": "0.0.0",
"dependencies": {
"express": "expressjs/express",
"mocha": "mochajs/mocha#4727d357ea",
"module": "user/repo#feature\/branch"
}
}
```
### Local Paths
#### Local Paths
As of version 2.0.0 you can provide a path to a local directory that contains a
package. Local paths can be saved using `npm install -S` or
`npm install --save`, using any of these forms:
../foo/bar
~/foo/bar
./foo/bar
/foo/bar
```bash
../foo/bar
~/foo/bar
./foo/bar
/foo/bar
```
in which case they will be normalized to a relative path and added to your
`package.json`. For example:
{
"name": "baz",
"dependencies": {
"bar": "file:../foo/bar"
}
}
```json
{
"name": "baz",
"dependencies": {
"bar": "file:../foo/bar"
}
}
```
This feature is helpful for local offline development and creating
tests that require npm installing where you don't want to hit an
external server, but should not be used when publishing packages
to the public registry.
## devDependencies
### devDependencies
If someone is planning on downloading and using your module in their
program, then they probably don't want or need to download and build
@@ -557,7 +632,7 @@ object.
These things will be installed when doing `npm link` or `npm install`
from the root of a package, and can be managed like any other npm
configuration param. See `npm-config(7)` for more on the topic.
configuration param. See [`npm-config`](/docs/using-npm/config) for more on the topic.
For build steps that are not platform-specific, such as compiling
CoffeeScript or other languages to JavaScript, use the `prepare`
@@ -565,24 +640,26 @@ script to do this, and make the required package a devDependency.
For example:
{ "name": "ethopia-waza",
"description": "a delightfully fruity coffee varietal",
"version": "1.2.3",
"devDependencies": {
"coffee-script": "~1.6.3"
},
"scripts": {
"prepare": "coffee -o lib/ -c src/waza.coffee"
},
"main": "lib/waza.js"
}
```json
{ "name": "ethopia-waza",
"description": "a delightfully fruity coffee varietal",
"version": "1.2.3",
"devDependencies": {
"coffee-script": "~1.6.3"
},
"scripts": {
"prepare": "coffee -o lib/ -c src/waza.coffee"
},
"main": "lib/waza.js"
}
```
The `prepare` script will be run before publishing, so that users
can consume the functionality without requiring them to compile it
themselves. In dev mode (ie, locally running `npm install`), it'll
run this script as well, so that you can test it easily.
## peerDependencies
### peerDependencies
In some cases, you want to express the compatibility of your package with a
host tool or library, while not necessarily doing a `require` of this host.
@@ -591,20 +668,24 @@ a specific interface, expected and specified by the host documentation.
For example:
{
"name": "tea-latte",
"version": "1.3.5",
"peerDependencies": {
"tea": "2.x"
}
}
```json
{
"name": "tea-latte",
"version": "1.3.5",
"peerDependencies": {
"tea": "2.x"
}
}
```
This ensures your package `tea-latte` can be installed *along* with the second
major version of the host package `tea` only. `npm install tea-latte` could
possibly yield the following dependency graph:
├── tea-latte@1.3.5
└── tea@2.2.0
```bash
├── tea-latte@1.3.5
└── tea@2.2.0
```
**NOTE: npm versions 1 and 2 will automatically install `peerDependencies` if
they are not explicitly depended upon higher in the dependency tree. In the
@@ -622,7 +703,7 @@ the host package's major version will break your plugin. Thus, if you've worked
with every 1.x version of the host package, use `"^1.0"` or `"1.x"` to express
this. If you depend on features introduced in 1.5.2, use `">= 1.5.2 < 2"`.
## bundledDependencies
### bundledDependencies
This defines an array of package names that will be bundled when publishing
the package.
@@ -636,7 +717,7 @@ For example:
If we define a package.json like this:
```
```json
{
"name": "awesome-web-framework",
"version": "1.0.0",
@@ -653,7 +734,7 @@ any versions, as that information is specified in `dependencies`.
If this is spelled `"bundleDependencies"`, then that is also honored.
## optionalDependencies
### optionalDependencies
If a dependency can be used, but you would like npm to proceed if it cannot be
found or fails to install, then you may put it in the `optionalDependencies`
@@ -664,30 +745,34 @@ installation to fail.
It is still your program's responsibility to handle the lack of the
dependency. For example, something like this:
try {
var foo = require('foo')
var fooVersion = require('foo/package.json').version
} catch (er) {
foo = null
}
if ( notGoodFooVersion(fooVersion) ) {
foo = null
}
```js
try {
var foo = require('foo')
var fooVersion = require('foo/package.json').version
} catch (er) {
foo = null
}
if ( notGoodFooVersion(fooVersion) ) {
foo = null
}
// .. then later in your program ..
// .. then later in your program ..
if (foo) {
foo.doFooThings()
}
if (foo) {
foo.doFooThings()
}
```
Entries in `optionalDependencies` will override entries of the same name in
`dependencies`, so it's usually best to only put in one place.
## engines
### engines
You can specify the version of node that your stuff works on:
{ "engines" : { "node" : ">=0.10.3 <0.12" } }
```json
{ "engines" : { "node" : ">=0.10.3 <0.12" } }
```
And, like with dependencies, if you don't specify the version (or if you
specify "\*" as the version), then any version of node will do.
@@ -699,49 +784,59 @@ that it works on node.
You can also use the "engines" field to specify which versions of npm
are capable of properly installing your program. For example:
{ "engines" : { "npm" : "~1.0.20" } }
```json
{ "engines" : { "npm" : "~1.0.20" } }
```
Unless the user has set the `engine-strict` config flag, this
field is advisory only and will only produce warnings when your package is installed as a dependency.
## engineStrict
### engineStrict
**This feature was removed in npm 3.0.0**
Prior to npm 3.0.0, this feature was used to treat this package as if the
user had set `engine-strict`. It is no longer used.
## os
### os
You can specify which operating systems your
module will run on:
"os" : [ "darwin", "linux" ]
```json
"os" : [ "darwin", "linux" ]
```
You can also blacklist instead of whitelist operating systems,
just prepend the blacklisted os with a '!':
"os" : [ "!win32" ]
```json
"os" : [ "!win32" ]
```
The host operating system is determined by `process.platform`
It is allowed to both blacklist, and whitelist, although there isn't any
good reason to do this.
## cpu
### cpu
If your code only runs on certain cpu architectures,
you can specify which ones.
"cpu" : [ "x64", "ia32" ]
```json
"cpu" : [ "x64", "ia32" ]
```
Like the `os` option, you can also blacklist architectures:
"cpu" : [ "!arm", "!mips" ]
```json
"cpu" : [ "!arm", "!mips" ]
```
The host architecture is determined by `process.arch`
## preferGlobal
### preferGlobal
**DEPRECATED**
@@ -749,7 +844,7 @@ This option used to trigger an npm warning, but it will no longer warn. It is
purely there for informational purposes. It is now recommended that you install
any binaries as local devDependencies wherever possible.
## private
### private
If you set `"private": true` in your package.json, then npm will refuse
to publish it.
@@ -760,7 +855,7 @@ specific registry (for example, an internal registry), then use the
`publishConfig` dictionary described below to override the `registry` config
param at publish-time.
## publishConfig
### publishConfig
This is a set of config values that will be used at publish-time. It's
especially handy if you want to set the tag, registry or access, so that
@@ -770,10 +865,10 @@ to the global public registry or that a scoped module is private by default.
Any config values can be overridden, but only "tag", "registry" and "access"
probably matter for the purposes of publishing.
See `npm-config(7)` to see the list of config options that can be
See [`npm-config`](/docs/using-npm/config) to see the list of config options that can be
overridden.
## DEFAULT VALUES
### DEFAULT VALUES
npm will default some values based on package contents.
@@ -794,14 +889,13 @@ npm will default some values based on package contents.
are optional. Lines which start with a `#` or are blank, will be
ignored.
## SEE ALSO
### SEE ALSO
* semver(7)
* npm-init(1)
* npm-version(1)
* npm-config(1)
* npm-config(7)
* npm-help(1)
* npm-install(1)
* npm-publish(1)
* npm-uninstall(1)
* [semver](/using-npm/semver)
* [npm init](/cli-commands/npm-init)
* [npm version](/cli-commands/npm-version)
* [npm config](/cli-commands/npm-config)
* [npm help](/cli-commands/npm-help)
* [npm install](/cli-commands/npm-install)
* [npm publish](/cli-commands/npm-publish)
* [npm uninstall](/cli-commands/npm-uninstall)
deps/npm/doc/files/package-lock.json.md → deps/npm/docs/content/configuring-npm/package-lock-json.md
Vendored Regular → Executable
+32 -25
View File
@@ -1,7 +1,14 @@
package-lock.json(5) -- A manifestation of the manifest
=====================================================
---
section: configuring-npm
title: package-lock.json
description: A manifestation of the manifest
---
## DESCRIPTION
# package-lock.json
## A manifestation of the manifest
### Description
`package-lock.json` is automatically generated for any operations where npm
modifies either the `node_modules` tree, or `package.json`. It describes the
@@ -21,7 +28,7 @@ various purposes:
One key detail about `package-lock.json` is that it cannot be published, and it
will be ignored if found in any place other than the toplevel package. It shares
a format with npm-shrinkwrap.json(5), which is essentially the same file, but
a format with [npm-shrinkwrap.json](docs/configuring-npm/shrinkwrap-json), which is essentially the same file, but
allows publication. This is not recommended unless deploying a CLI tool or
otherwise using the publication process for producing production packages.
@@ -29,24 +36,24 @@ If both `package-lock.json` and `npm-shrinkwrap.json` are present in the root of
a package, `package-lock.json` will be completely ignored.
## FILE FORMAT
### File Format
### name
#### name
The name of the package this is a package-lock for. This must match what's in
`package.json`.
### version
#### version
The version of the package this is a package-lock for. This must match what's in
`package.json`.
### lockfileVersion
#### lockfileVersion
An integer version, starting at `1` with the version number of this document
whose semantics were used when generating this `package-lock.json`.
### packageIntegrity
#### packageIntegrity
This is a [subresource
integrity](https://w3c.github.io/webappsec/specs/subresourceintegrity/) value
@@ -54,18 +61,18 @@ created from the `package.json`. No preprocessing of the `package.json` should
be done. Subresource integrity strings can be produced by modules like
[`ssri`](https://www.npmjs.com/package/ssri).
### preserveSymlinks
#### preserveSymlinks
Indicates that the install was done with the environment variable
`NODE_PRESERVE_SYMLINKS` enabled. The installer should insist that the value of
this property match that environment variable.
### dependencies
#### dependencies
A mapping of package name to dependency object. Dependency objects have the
following properties:
#### version
##### version
This is a specifier that uniquely identifies this package and should be
usable in fetching a new copy of it.
@@ -77,7 +84,7 @@ usable in fetching a new copy of it.
* local tarball sources: This is the file URL of the tarball. (eg `file:///opt/storage/example-1.3.0.tgz`)
* local link sources: This is the file URL of the link. (eg `file:libs/our-module`)
#### integrity
##### integrity
This is a [Standard Subresource
Integrity](https://w3c.github.io/webappsec/specs/subresourceintegrity/) for this
@@ -90,27 +97,27 @@ resource.
the file.
* For local tarball sources: This is an integrity field based on the SHA512 of the file.
#### resolved
##### resolved
* For bundled dependencies this is not included, regardless of source.
* For registry sources this is path of the tarball relative to the registry
URL. If the tarball URL isn't on the same server as the registry URL then
this is a complete URL.
#### bundled
##### bundled
If true, this is the bundled dependency and will be installed by the parent
module. When installing, this module will be extracted from the parent
module during the extract phase, not installed as a separate dependency.
#### dev
##### dev
If true then this dependency is either a development dependency ONLY of the
top level module or a transitive dependency of one. This is false for
dependencies that are both a development dependency of the top level and a
transitive dependency of a non-development dependency of the top level.
#### optional
##### optional
If true then this dependency is either an optional dependency ONLY of the
top level module or a transitive dependency of one. This is false for
@@ -121,7 +128,7 @@ All optional dependencies should be included even if they're uninstallable
on the current platform.
#### requires
##### requires
This is a mapping of module name to version. This is a list of everything
this module requires, regardless of where it will be installed. The version
@@ -129,14 +136,14 @@ should match via normal matching rules a dependency either in our
`dependencies` or in a level higher than us.
#### dependencies
##### dependencies
The dependencies of this dependency, exactly as at the top level.
## SEE ALSO
### See also
* npm-shrinkwrap(1)
* npm-shrinkwrap.json(5)
* npm-package-locks(5)
* package.json(5)
* npm-install(1)
* [npm shrinkwrap](/cli-commands/npm-shrinkwrap)
* [shrinkwrap.json](/configuring-npm/shrinkwrap-json)
* [package-locks](/configuring-npm/package-locks)
* [package.json](/configuring-npm/package-json)
* [npm install](/cli-commands/npm-install)
deps/npm/doc/files/npm-package-locks.md → deps/npm/docs/content/configuring-npm/package-locks.md
Vendored Regular → Executable
+75 -56
View File
@@ -1,9 +1,16 @@
npm-package-locks(5) -- An explanation of npm lockfiles
=====================================================
---
section: configuring-npm
title: package-locks
description: An explanation of npm lockfiles
---
## DESCRIPTION
# package-locks
Conceptually, the "input" to npm-install(1) is a package.json(5), while its
## An explanation of npm lockfiles
### Description
Conceptually, the "input" to [`npm-install`](/docs/cli-commands/npm-install) is a [package.json](/docs/configuring-npm/package-json), while its
"output" is a fully-formed `node_modules` tree: a representation of the
dependencies you declared. In an ideal world, npm would work like a pure
function: the same `package.json` should produce the exact same `node_modules`
@@ -20,44 +27,53 @@ unable to do this. There are multiple reasons for this:
As an example, consider package A:
{
"name": "A",
"version": "0.1.0",
"dependencies": {
"B": "<0.1.0"
}
}
```json
{
"name": "A",
"version": "0.1.0",
"dependencies": {
"B": "<0.1.0"
}
}
```
package B:
{
"name": "B",
"version": "0.0.1",
"dependencies": {
"C": "<0.1.0"
}
}
```json
{
"name": "B",
"version": "0.0.1",
"dependencies": {
"C": "<0.1.0"
}
}
```
and package C:
{
"name": "C",
"version": "0.0.1"
}
```json
{
"name": "C",
"version": "0.0.1"
}
```
If these are the only versions of A, B, and C available in the
registry, then a normal `npm install A` will install:
A@0.1.0
`-- B@0.0.1
`-- C@0.0.1
```json
A@0.1.0
`-- B@0.0.1
`-- C@0.0.1
```
However, if B@0.0.2 is published, then a fresh `npm install A` will
install:
A@0.1.0
`-- B@0.0.2
`-- C@0.0.1
```bash
A@0.1.0
`-- B@0.0.2
`-- C@0.0.1
```
assuming the new version did not modify B's dependencies. Of course,
the new version of B could include a new version of C and any number
@@ -67,34 +83,36 @@ author are not the same person, there's no way for A's author to say
that he or she does not want to pull in newly published versions of C
when B hasn't changed at all.
To prevent this potential issue, npm uses package-lock.json(5) or, if present,
npm-shrinkwrap.json(5). These files are called package locks, or lockfiles.
To prevent this potential issue, npm uses [package-lock.json](/docs/configuring-npm/package-lock-json) or, if present,
[npm-shrinkwrap.json](shrinkwrap.json). These files are called package locks, or lockfiles.
Whenever you run `npm install`, npm generates or updates your package lock,
which will look something like this:
{
"name": "A",
"version": "0.1.0",
...metadata fields...
```json
{
"name": "A",
"version": "0.1.0",
...metadata fields...
"dependencies": {
"B": {
"version": "0.0.1",
"resolved": "https://registry.npmjs.org/B/-/B-0.0.1.tgz",
"integrity": "sha512-DeAdb33F+"
"dependencies": {
"B": {
"version": "0.0.1",
"resolved": "https://registry.npmjs.org/B/-/B-0.0.1.tgz",
"integrity": "sha512-DeAdb33F+"
"dependencies": {
"C": {
"version": "git://github.com/org/C.git#5c380ae319fc4efe9e7f2d9c78b0faa588fd99b4"
}
}
"C": {
"version": "git://github.com/org/C.git#5c380ae319fc4efe9e7f2d9c78b0faa588fd99b4"
}
}
}
}
}
```
This file describes an *exact*, and more importantly *reproducible*
`node_modules` tree. Once it's present, any future installation will base its
work off this file, instead of recalculating dependency versions off
package.json(5).
[package.json](/docs/configuring-npm/package-json).
The presence of a package lock changes the installation behavior such that:
@@ -113,12 +131,13 @@ executed afterwards. These scripts run for both `package-lock.json` and
`npm-shrinkwrap.json`. For example to run some postprocessing on the generated
file:
"scripts": {
"postshrinkwrap": "json -I -e \"this.myMetadata = $MY_APP_METADATA\""
}
```json
"scripts": {
"postshrinkwrap": "json -I -e \"this.myMetadata = $MY_APP_METADATA\""
}
```
### Using locked packages
#### Using locked packages
Using a locked package is no different than using any package without a package
lock: any commands that update `node_modules` and/or `package.json`'s
@@ -136,7 +155,7 @@ on. Additionally, the diffs from these changes are human-readable and will
inform you of any changes npm has made to your `node_modules`, so you can notice
if any transitive dependencies were updated, hoisted, etc.
### Resolving lockfile conflicts
#### Resolving lockfile conflicts
Occasionally, two separate npm install will create package locks that cause
merge conflicts in source control systems. As of `npm@5.7.0`, these conflicts
@@ -155,10 +174,10 @@ pre-`npm@5.7.0` versions of npm 5, albeit a bit more noisily. Note that if
`package.json` itself conflicts, you will have to resolve that by hand and run
`npm install` manually, even with the merge driver.
## SEE ALSO
### See Also
* https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527
* package.json(5)
* package-lock.json(5)
* npm-shrinkwrap.json(5)
* npm-shrinkwrap(1)
* [package.json](/configuring-npm/package-json)
* [package-lock.json](/configuring-npm/package-lock-json)
* [shrinkwrap.json](/configuring-npm/shrinkwrap-json)
* [npm shrinkwrap](/cli-commands/npm-shrinkwrap)
deps/npm/doc/files/npm-shrinkwrap.json.md → deps/npm/docs/content/configuring-npm/shrinkwrap-json.md
Vendored Regular → Executable
+17 -10
View File
@@ -1,9 +1,16 @@
npm-shrinkwrap.json(5) -- A publishable lockfile
=====================================================
---
section: configuring-npm
title: shrinkwrap.json
description: A publishable lockfile
---
## DESCRIPTION
# npm-shrinkwrap.json
`npm-shrinkwrap.json` is a file created by npm-shrinkwrap(1). It is identical to
## A publishable lockfile
### Description
`npm-shrinkwrap.json` is a file created by [`npm-shrinkwrap`](/docs/cli-commands/npm-shrinkwrap). It is identical to
`package-lock.json`, with one major caveat: Unlike `package-lock.json`,
`npm-shrinkwrap.json` may be included when publishing a package.
@@ -17,11 +24,11 @@ Additionally, if both `package-lock.json` and `npm-shrinkwrap.json` are present
in a package root, `package-lock.json` will be ignored in favor of this file.
For full details and description of the `npm-shrinkwrap.json` file format, refer
to the manual page for package-lock.json(5).
to the manual page for [package-lock.json](/docs/configuring-npm/package-lock-json).
## SEE ALSO
### See also
* npm-shrinkwrap(1)
* package-lock.json(5)
* package.json(5)
* npm-install(1)
* [npm shrinkwrap](/cli-commands/npm-shrinkwrap)
* [package-lock.json](/configuring-npm/package-lock-json)
* [package.json](/configuring-npm/package-json)
* [npm install](/cli-commands/npm-install)
deps/npm/doc/misc/npm-coding-style.md → deps/npm/docs/content/using-npm/coding-style.md
Vendored Regular → Executable
+76 -56
View File
@@ -1,7 +1,13 @@
npm-coding-style(7) -- npm's "funny" coding style
=================================================
---
section: using-npm
title: coding-style
description: npm's "funny" coding style
---
## DESCRIPTION
# coding-style
## npm's "funny" coding style
### Description
npm's coding style is a bit unconventional. It is not different for
difference's sake, but rather a carefully crafted style that is
@@ -12,49 +18,55 @@ make your code conform to npm's style.
Note: this concerns npm's code not the specific packages that you can download from the npm registry.
## Line Length
### Line Length
Keep lines shorter than 80 characters. It's better for lines to be
too short than to be too long. Break up long lists, objects, and other
statements onto multiple lines.
## Indentation
### Indentation
Two-spaces. Tabs are better, but they look like hell in web browsers
(and on GitHub), and node uses 2 spaces, so that's that.
Configure your editor appropriately.
## Curly braces
### Curly braces
Curly braces belong on the same line as the thing that necessitates them.
Bad:
function ()
{
```javascript
function ()
{
```
Good:
function () {
```javascript
function () {
```
If a block needs to wrap to the next line, use a curly brace. Don't
use it if it doesn't.
Bad:
if (foo) { bar() }
while (foo)
bar()
```javascript
if (foo) { bar() }
while (foo)
bar()
```
Good:
if (foo) bar()
while (foo) {
bar()
}
```javascript
if (foo) bar()
while (foo) {
bar()
}
```
## Semicolons
### Semicolons
Don't use them except in four situations:
@@ -68,52 +80,60 @@ Don't use them except in four situations:
Some examples of good semicolon usage:
;(x || y).doSomething()
;[a, b, c].forEach(doSomething)
for (var i = 0; i < 10; i ++) {
switch (state) {
case 'begin': start(); continue
case 'end': finish(); break
default: throw new Error('unknown state')
}
end()
}
```javascript
;(x || y).doSomething()
;[a, b, c].forEach(doSomething)
for (var i = 0; i < 10; i ++) {
switch (state) {
case 'begin': start(); continue
case 'end': finish(); break
default: throw new Error('unknown state')
}
end()
}
```
Note that starting lines with `-` and `+` also should be prefixed
with a semicolon, but this is much less common.
## Comma First
### Comma First
If there is a list of things separated by commas, and it wraps
across multiple lines, put the comma at the start of the next
line, directly below the token that starts the list. Put the
final token in the list on a line by itself. For example:
var magicWords = [ 'abracadabra'
, 'gesundheit'
, 'ventrilo'
]
, spells = { 'fireball' : function () { setOnFire() }
, 'water' : function () { putOut() }
}
, a = 1
, b = 'abc'
, etc
, somethingElse
```javascript
var magicWords = [ 'abracadabra'
, 'gesundheit'
, 'ventrilo'
]
, spells = { 'fireball' : function () { setOnFire() }
, 'water' : function () { putOut() }
}
, a = 1
, b = 'abc'
, etc
, somethingElse
```
## Quotes
### Quotes
Use single quotes for strings except to avoid escaping.
Bad:
var notOk = "Just double quotes"
```javascript
var notOk = "Just double quotes"
```
Good:
var ok = 'String contains "double" quotes'
var alsoOk = "String contains 'single' quotes or apostrophe"
```javascript
var ok = 'String contains "double" quotes'
var alsoOk = "String contains 'single' quotes or apostrophe"
```
## Whitespace
### Whitespace
Put a single space in front of `(` for anything other than a function call.
Also use a single space wherever it makes things more readable.
@@ -121,11 +141,11 @@ Also use a single space wherever it makes things more readable.
Don't leave trailing whitespace at the end of lines. Don't indent empty
lines. Don't use more spaces than are helpful.
## Functions
### Functions
Use named functions. They make stack traces a lot easier to read.
## Callbacks, Sync/async Style
### Callbacks, Sync/async Style
Use the asynchronous/non-blocking versions of things as much as possible.
It might make more sense for npm to use the synchronous fs APIs, but this
@@ -138,12 +158,12 @@ argument is the Error or null.
Be very careful never to ever ever throw anything. It's worse than useless.
Just send the error message back as the first argument to the callback.
## Errors
### Errors
Always create a new Error object with your message. Don't just return a
string message to the callback. Stack traces are handy.
## Logging
### Logging
Logging is done using the [npmlog](https://github.com/npm/npmlog)
utility.
@@ -153,10 +173,10 @@ logging the same object over and over again is not helpful. Logs should
report what's happening so that it's easier to track down where a fault
occurs.
Use appropriate log levels. See `npm-config(7)` and search for
Use appropriate log levels. See [`npm-config`](/docs/using-npm/config) and search for
"loglevel".
## Case, naming, etc.
### Case, naming, etc.
Use `lowerCamelCase` for multiword identifiers when they refer to objects,
functions, methods, properties, or anything not specified in this section.
@@ -174,7 +194,7 @@ Use a single uppercase letter for function names where the function
would normally be anonymous, but needs to call itself recursively. It
makes it clear that it's a "throwaway" function.
## null, undefined, false, 0
### null, undefined, false, 0
Boolean variables and functions should always be either `true` or
`false`. Don't set it to 0 unless it's supposed to be a number.
@@ -186,7 +206,7 @@ set to anything."
Boolean objects are forbidden.
## SEE ALSO
### See Also
* npm-developers(7)
* npm(1)
* [npm developers](/using-npm/developers)
* [npm](/cli-commands/npm)
deps/npm/doc/misc/npm-config.md → deps/npm/docs/content/using-npm/config.md
Vendored Regular → Executable
+198 -164
View File
File diff suppressed because it is too large. Load diff
deps/npm/doc/misc/npm-developers.md → deps/npm/docs/content/using-npm/developers.md
Vendored Regular → Executable
+55 -36
View File
@@ -1,7 +1,14 @@
npm-developers(7) -- Developer Guide
====================================
---
section: using-npm
title: developers
description: Developer Guide
---
## DESCRIPTION
# developers
## Developer Guide
### Description
So, you've decided to use npm to develop (and maybe publish/deploy)
your project.
@@ -11,13 +18,13 @@ Fantastic!
There are a few things that you need to do above the simple steps
that your users will do to install your program.
## About These Documents
### About These Documents
These are man pages. If you install npm, you should be able to
then do `man npm-thing` to get the documentation on a particular
topic, or `npm help thing` to see the same information.
## What is a `package`
### What is a package
A package is:
@@ -36,20 +43,22 @@ after packing it up into a tarball (b).
Git urls can be of the form:
git://github.com/user/project.git#commit-ish
git+ssh://user@hostname:project.git#commit-ish
git+http://user@hostname/project/blah.git#commit-ish
git+https://user@hostname/project/blah.git#commit-ish
```bash
git://github.com/user/project.git#commit-ish
git+ssh://user@hostname:project.git#commit-ish
git+http://user@hostname/project/blah.git#commit-ish
git+https://user@hostname/project/blah.git#commit-ish
```
The `commit-ish` can be any tag, sha, or branch which can be supplied as
an argument to `git checkout`. The default is `master`.
## The package.json File
### The package.json File
You need to have a `package.json` file in the root of your project to do
much of anything with npm. That is basically the whole interface.
See `package.json(5)` for details about what goes in that file. At the very
See [`package.json`](/docs/configuring-npm/package-json) for details about what goes in that file. At the very
least, you need:
* name:
@@ -78,7 +87,7 @@ least, you need:
If you have a special compilation or installation script, then you
should put it in the `scripts` object. You should definitely have at
least a basic smoke-test command as the "scripts.test" field.
See npm-scripts(7).
See [npm-scripts](/docs/using-npm/scripts).
* main:
If you have a single module that serves as the entry point to your
@@ -91,10 +100,10 @@ least, you need:
they'll get installed just like these ones.
You can use `npm init` in the root of your package in order to get you
started with a pretty basic package.json file. See `npm-init(1)` for
started with a pretty basic package.json file. See [`npm-init`](/docs/cli-commands/npm-init) for
more info.
## Keeping files *out* of your package
### Keeping files *out* of your package
Use a `.npmignore` file to keep stuff out of your package. If there's
no `.npmignore` file, but there *is* a `.gitignore` file, then npm will
@@ -146,23 +155,23 @@ property of `package.json`, which is an array of file or directory names
that should be included in your package. Sometimes a whitelist is easier
to manage than a blacklist.
### Testing whether your `.npmignore` or `files` config works
#### Testing whether your `.npmignore` or `files` config works
If you want to double check that your package will include only the files
you intend it to when published, you can run the `npm pack` command locally
which will generate a tarball in the working directory, the same way it
does for publishing.
## Link Packages
### Link Packages
`npm link` is designed to install a development package and see the
changes in real time without having to keep re-installing it. (You do
need to either re-link or `npm rebuild -g` to update compiled packages,
of course.)
More info at `npm-link(1)`.
More info at [`npm-link`](/docs/cli-commands/npm-link).
## Before Publishing: Make Sure Your Package Installs and Works
### Before Publishing: Make Sure Your Package Installs and Works
**This is important.**
@@ -173,40 +182,50 @@ So don't do that.
In the root of your package, do this:
npm install . -g
```bash
npm install . -g
```
That'll show you that it's working. If you'd rather just create a symlink
package that points to your working directory, then do this:
npm link
```bash
npm link
```
Use `npm ls -g` to see if it's there.
To test a local install, go into some other folder, and then do:
cd ../some-other-folder
npm install ../my-package
```bash
cd ../some-other-folder
npm install ../my-package
```
to install it locally into the node_modules folder in that other place.
Then go into the node-repl, and try using require("my-thing") to
bring in your module's main module.
## Create a User Account
### Create a User Account
Create a user with the adduser command. It works like this:
npm adduser
```bash
npm adduser
```
and then follow the prompts.
This is documented better in npm-adduser(1).
This is documented better in [npm-adduser](/docs/cli-commands/npm-adduser).
## Publish your package
### Publish your package
This part's easy. In the root of your folder, do this:
npm publish
```bash
npm publish
```
You can give publish a url to a tarball, or a filename of a tarball,
or a path to a folder.
@@ -216,18 +235,18 @@ by default. So, if you have secret stuff in there, use a
`.npmignore` file to list out the globs to ignore, or publish
from a fresh checkout.
## Brag about it
### Brag about it
Send emails, write blogs, blab in IRC.
Tell the world how easy it is to install your program!
## SEE ALSO
### See also
* npm(1)
* npm-init(1)
* package.json(5)
* npm-scripts(7)
* npm-publish(1)
* npm-adduser(1)
* npm-registry(7)
* [npm](/cli-commands/npm)
* [npm init](/cli-commands/npm-init)
* [package.json](/configuring-npm/package-json)
* [npm scripts](/using-npm/scripts)
* [npm publish](/cli-commands/npm-publish)
* [npm adduser](/cli-commands/npm-adduser)
* [npm registry](/using-npm/registry)
deps/npm/doc/misc/npm-disputes.md → deps/npm/docs/content/using-npm/disputes.md
Vendored Regular → Executable
+19 -12
View File
@@ -1,5 +1,12 @@
npm-disputes(7) -- Handling Module Name Disputes
================================================
---
section: using-npm
title: disputes
description: Handling Module Name Disputes
---
# disputes
## Handling Module Name Disputes
This document describes the steps that you should take to resolve module name
disputes with other npm publishers. It also describes special steps you should
@@ -10,7 +17,7 @@ This document is a clarification of the acceptable behavior outlined in the
this document should be interpreted to contradict any aspect of the npm Code of
Conduct.
## TL;DR
### TL;DR
1. Get the author email with `npm owner ls <pkgname>`
2. Email the author, CC <support@npmjs.com>
@@ -18,7 +25,7 @@ Conduct.
Don't squat on package names. Publish code or move out of the way.
## DESCRIPTION
### Description
There sometimes arise cases where a user publishes a module, and then later,
some other user wants to use that name. Here are some common ways that happens
@@ -57,7 +64,7 @@ some other user wants to use that name. Here are some common ways that happens
<support@npmjs.com> and we'll sort it out. ("Reasonable" is usually at least
4 weeks.)
## REASONING
### Reasoning
In almost every case so far, the parties involved have been able to reach an
amicable resolution without any major intervention. Most people really do want
@@ -69,7 +76,7 @@ is going to make most people quite upset, regardless of the justification. When
humans solve their problems by talking to other humans with respect, everyone
has the chance to end up feeling good about the interaction.
## EXCEPTIONS
### Exceptions
Some things are not allowed, and will be removed without discussion if they are
brought to the attention of the npm registry admins, including but not limited
@@ -98,7 +105,7 @@ If you see bad behavior like this, please report it to <abuse@npmjs.com> right
away. **You are never expected to resolve abusive behavior on your own. We are
here to help.**
## TRADEMARKS
### Trademarkss
If you think another npm publisher is infringing your trademark, such as by
using a confusingly similar package name, email <abuse@npmjs.com> with a link to
@@ -111,20 +118,20 @@ name to you. Otherwise, we will contact the package publisher and ask them to
clear up any confusion with changes to their package's `README` file or
metadata.
## CHANGES
### Changes
This is a living document and may be updated from time to time. Please refer to
the [git history for this document](https://github.com/npm/cli/commits/latest/doc/misc/npm-disputes.md)
to view the changes.
## LICENSE
### License
Copyright (C) npm, Inc., All rights reserved
This document may be reused under a Creative Commons Attribution-ShareAlike
License.
## SEE ALSO
### See also
* npm-registry(7)
* npm-owner(1)
* [npm registry](/using-npm/registry)
* [npm owner](/cli-commands/npm-owner)
deps/npm/doc/misc/npm-orgs.md → deps/npm/docs/content/using-npm/orgs.md
Vendored Regular → Executable
+28 -21
View File
@@ -1,7 +1,14 @@
npm-orgs(7) -- Working with Teams & Orgs
========================================
---
section: using-npm
title: orgs
description: Working with Teams & Orgs
---
## DESCRIPTION
# orgs
## Working with Teams & Orgs
### Description
There are three levels of org users:
@@ -17,14 +24,14 @@ The developer will be able to access packages based on the teams they are on. Ac
There are two main commands:
1. `npm team` see npm-team(1) for more details
2. `npm access` see npm-access(1) for more details
1. `npm team` see [npm-team](/docs/cli-commands/npm-team) for more details
2. `npm access` see [npm-access](/docs/cli-commands/npm-access) for more details
## Team Admins create teams
### Team Admins create teams
* Check who you’ve added to your org:
```
```bash
npm team ls <org>:developers
```
@@ -32,59 +39,59 @@ npm team ls <org>:developers
* Create a new team:
```
```bash
npm team create <org:team>
```
* Add members to that team:
```
```bash
npm team add <org:team> <user>
```
## Publish a package and adjust package access
### Publish a package and adjust package access
* In package directory, run
```
```bash
npm init --scope=<org>
```
to scope it for your org & publish as usual
* Grant access:
```
```bash
npm access grant <read-only|read-write> <org:team> [<package>]
```
* Revoke access:
```
```bash
npm access revoke <org:team> [<package>]
```
## Monitor your package access
### Monitor your package access
* See what org packages a team member can access:
```
```bash
npm access ls-packages <org> <user>
```
* See packages available to a specific team:
```
```bash
npm access ls-packages <org:team>
```
* Check which teams are collaborating on a package:
```
```bash
npm access ls-collaborators <pkg>
```
## SEE ALSO
### See also
* npm-team(1)
* npm-access(1)
* npm-scope(7)
* [npm team](/cli-commands/npm-team)
* [npm access](/cli-commands/npm-access)
* [npm scope](/using-npm/scope)
Loaded 100 of 464 files, more files were not shown because too many files have changed in this diff. Show more