From 13ae5385ae010f0511927763fe28919ad44941f0 Mon Sep 17 00:00:00 2001
From: Audrey Eschright
package.json
in the current folder and use the name
This command is similar to npm-install(1)
, except it's meant to be used in
automated environments such as test platforms, continuous integration, and
-deployment. It can be significantly faster than a regular npm install by
-skipping certain user-oriented features. It is also more strict than a regular
-install, which can help catch errors or inconsistencies caused by the
+deployment -- or any situation where you want to make sure you're doing a clean
+install of your dependencies. It can be significantly faster than a regular npm
+install by skipping certain user-oriented features. It is also more strict than
+a regular install, which can help catch errors or inconsistencies caused by the
incrementally-installed local environments of most npm users.
In short, the main differences between using npm install
and npm ci
are:
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
if you have a system
-that will read that file for you.
You may of course also pipe the output of npm completion
to a file
+such as /usr/local/etc/bash_completion.d/npm
or
+/etc/bash_completion.d/npm
if you have a system that will read
+that file for you.
When COMP_CWORD
, COMP_LINE
, and COMP_POINT
are defined in the
environment, npm completion
acts in "plumbing mode", and outputs
completions based on the arguments.
npm deprecate <pkg>[@<version>] <message>
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 as well as specific versions, so you can do -something like this:
+It works on version ranges 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"
Note that you must be the package owner to deprecate something. See the
owner
and adduser
help topics.
To un-deprecate a package, specify an empty string (""
) for the message
argument.
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.
add:
Tags the specified version of the package with the specified tag, or the
---tag
config if not specified. If the tag you're adding is latest
and you
-have two-factor authentication on auth-and-writes then you'll need to include
-an otp on the command line with --otp
.
--tag
config if not specified. If you have two-factor authentication on
+auth-and-writes then you’ll need to include a one-time password on the
+command line with --otp <one-time password>
.
rm: Clear a tag that is no longer in use from the package.
@@ -85,5 +85,5 @@ begin with a number or the letterv
.
name
property.
npm cache clean
and reset the cache.
Edit an installed package
npm edit <pkg>[@<version>]
Opens the package folder in the default editor (or whatever you've
-configured as the npm editor
config -- see npm-config(7)
.)
npm edit <pkg>[/<subpkg>...]
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)
.)
After it has been edited, the package is rebuilt so as to pick up any changes in compiled packages.
For instance, you can do npm install connect
to install connect
@@ -48,5 +50,5 @@ or "notepad"
on Windows.
npm install
.
#<commit-ish>
or #semver:<semver>
is
- specified, then master
is used.
+ specified, then the default branch of the repository is used.
If the repository makes use of submodules, those submodules will be cloned as well.
If the package being installed contains a prepare
script, its
@@ -370,5 +370,5 @@ affects a real use-case, it will be investigated.
npm ls promzard
in npm's source tree will show:
-npm@6.4.1 /path/to/npm
+npm@6.5.0-next.0 /path/to/npm
└─┬ init-package-json@0.0.4
└── promzard@0.1.5
It will print out extraneous, missing, and invalid packages.
If a project specifies git urls for dependencies these are shown
@@ -108,5 +108,5 @@ project.
-
+
diff --git a/deps/npm/html/doc/cli/npm-outdated.html b/deps/npm/html/doc/cli/npm-outdated.html
index dc847796e8..fa4f463f82 100644
--- a/deps/npm/html/doc/cli/npm-outdated.html
+++ b/deps/npm/html/doc/cli/npm-outdated.html
@@ -31,6 +31,7 @@ always be seeing only top-level dependencies that are outdated.
package type
(when using --long
/ -l
) tells you whether this package is
a dependency
or a devDependency
. Packages not included in package.json
are always marked dependencies
.
+homepage
(when using --long
/ -l
) is the homepage
value contained in the package's package.json
Red means there's a newer version matching your semver requirements, so you should update now.
Yellow indicates that there's a newer version above your semver requirements (usually new major, or new 0.x minor) so proceed with caution.
@@ -57,9 +58,10 @@ The installed committish might satisfy the dependency specifier (if it's
something immutable, like a commit SHA), or it might not, so npm outdated
and
npm update
have to fetch Git repos to check. This is why currently doing a
reinstall of a Git dependency always forces a new clone and install.
-`npm@3.5.2is marked as "wanted", but "latest" is
npm@3.5.1because npm
-uses dist-tags to manage its
latestand
nextrelease channels.
npm updatewill install the _newest_ version, but
npm install npm(with no semver range)
-will install whatever's tagged as
latest`.
+npm@3.5.2
is marked as "wanted", but "latest" is npm@3.5.1
because npm
+uses dist-tags to manage its latest
and next
release channels. npm update
+will install the newest version, but npm install npm
(with no semver range)
+will install whatever's tagged as latest
.
once
is just plain out of date. Reinstalling node_modules
from scratch or
running npm update
will bring it up to spec.
@@ -114,5 +116,5 @@ project.
-
+
diff --git a/deps/npm/html/doc/cli/npm-owner.html b/deps/npm/html/doc/cli/npm-owner.html
index f439c815af..88f912f89e 100644
--- a/deps/npm/html/doc/cli/npm-owner.html
+++ b/deps/npm/html/doc/cli/npm-owner.html
@@ -53,5 +53,5 @@ with --otp
.
-
+
diff --git a/deps/npm/html/doc/cli/npm-pack.html b/deps/npm/html/doc/cli/npm-pack.html
index 5727914b61..aceef4ea69 100644
--- a/deps/npm/html/doc/cli/npm-pack.html
+++ b/deps/npm/html/doc/cli/npm-pack.html
@@ -42,5 +42,5 @@ actually packing anything. Reports on what would have gone into the tarball.
-
+
diff --git a/deps/npm/html/doc/cli/npm-ping.html b/deps/npm/html/doc/cli/npm-ping.html
index 1177eef247..0ef7c690ee 100644
--- a/deps/npm/html/doc/cli/npm-ping.html
+++ b/deps/npm/html/doc/cli/npm-ping.html
@@ -33,5 +33,5 @@ If it works it will output something like:
-
+
diff --git a/deps/npm/html/doc/cli/npm-prefix.html b/deps/npm/html/doc/cli/npm-prefix.html
index 65dbf19286..dc8f2bf81e 100644
--- a/deps/npm/html/doc/cli/npm-prefix.html
+++ b/deps/npm/html/doc/cli/npm-prefix.html
@@ -37,5 +37,5 @@ to contain a package.json file unless -g
is also specified.
-
+
diff --git a/deps/npm/html/doc/cli/npm-profile.html b/deps/npm/html/doc/cli/npm-profile.html
index 3360e3009a..6250207f3e 100644
--- a/deps/npm/html/doc/cli/npm-profile.html
+++ b/deps/npm/html/doc/cli/npm-profile.html
@@ -88,4 +88,4 @@ available on non npmjs.com registries.
-
+
diff --git a/deps/npm/html/doc/cli/npm-prune.html b/deps/npm/html/doc/cli/npm-prune.html
index 9b1922e03a..56b96a21a0 100644
--- a/deps/npm/html/doc/cli/npm-prune.html
+++ b/deps/npm/html/doc/cli/npm-prune.html
@@ -47,5 +47,5 @@ and it's up to you to run npm prune
from time-to-time to remove
-
+
diff --git a/deps/npm/html/doc/cli/npm-publish.html b/deps/npm/html/doc/cli/npm-publish.html
index b6819bc0aa..85c213e4bd 100644
--- a/deps/npm/html/doc/cli/npm-publish.html
+++ b/deps/npm/html/doc/cli/npm-publish.html
@@ -50,8 +50,8 @@ then you can provide a code from your authenticator with this. If you
don't include this and you're running from a TTY then you'll be prompted.
[--dry-run]
-Does everything publish would do except actually publishing to the registry.
-Reports the details of what would have been published.
+As of npm@6
, does everything publish would do except actually publishing
+to the registry. Reports the details of what would have been published.
Fails if the package name and version combination already exists in
@@ -87,5 +87,5 @@ included and packs them into a tarball to be uploaded to the registry.
-
+
diff --git a/deps/npm/html/doc/cli/npm-rebuild.html b/deps/npm/html/doc/cli/npm-rebuild.html
index 3d574beea0..624da5cfc7 100644
--- a/deps/npm/html/doc/cli/npm-rebuild.html
+++ b/deps/npm/html/doc/cli/npm-rebuild.html
@@ -34,5 +34,5 @@ the new binary.
-
+
diff --git a/deps/npm/html/doc/cli/npm-repo.html b/deps/npm/html/doc/cli/npm-repo.html
index 84f4221ee5..2f6acc0f4d 100644
--- a/deps/npm/html/doc/cli/npm-repo.html
+++ b/deps/npm/html/doc/cli/npm-repo.html
@@ -40,5 +40,5 @@ a package.json
in the current folder and use the name
-
+
diff --git a/deps/npm/html/doc/cli/npm-restart.html b/deps/npm/html/doc/cli/npm-restart.html
index 5c25e15816..a64b5183df 100644
--- a/deps/npm/html/doc/cli/npm-restart.html
+++ b/deps/npm/html/doc/cli/npm-restart.html
@@ -52,5 +52,5 @@ behavior will be accompanied by an increase in major version number
-
+
diff --git a/deps/npm/html/doc/cli/npm-root.html b/deps/npm/html/doc/cli/npm-root.html
index 1388f1a3f7..28579ac3e2 100644
--- a/deps/npm/html/doc/cli/npm-root.html
+++ b/deps/npm/html/doc/cli/npm-root.html
@@ -34,5 +34,5 @@
-
+
diff --git a/deps/npm/html/doc/cli/npm-run-script.html b/deps/npm/html/doc/cli/npm-run-script.html
index a4da59791a..6204ab13aa 100644
--- a/deps/npm/html/doc/cli/npm-run-script.html
+++ b/deps/npm/html/doc/cli/npm-run-script.html
@@ -79,5 +79,5 @@ without breaking the execution chain.
-
+
diff --git a/deps/npm/html/doc/cli/npm-search.html b/deps/npm/html/doc/cli/npm-search.html
index 0a1bf7627b..70f2644aff 100644
--- a/deps/npm/html/doc/cli/npm-search.html
+++ b/deps/npm/html/doc/cli/npm-search.html
@@ -108,5 +108,5 @@ setting.
-
+
diff --git a/deps/npm/html/doc/cli/npm-shrinkwrap.html b/deps/npm/html/doc/cli/npm-shrinkwrap.html
index 2f05e0adab..1b3b76cffb 100644
--- a/deps/npm/html/doc/cli/npm-shrinkwrap.html
+++ b/deps/npm/html/doc/cli/npm-shrinkwrap.html
@@ -40,5 +40,5 @@ of package locks in npm, see npm-packa
-
+
diff --git a/deps/npm/html/doc/cli/npm-star.html b/deps/npm/html/doc/cli/npm-star.html
index 8410bdd2c2..658480e86c 100644
--- a/deps/npm/html/doc/cli/npm-star.html
+++ b/deps/npm/html/doc/cli/npm-star.html
@@ -35,5 +35,5 @@ a vaguely positive way to show that you care.
-
+
diff --git a/deps/npm/html/doc/cli/npm-stars.html b/deps/npm/html/doc/cli/npm-stars.html
index 68b7e7cc3b..271e86e29d 100644
--- a/deps/npm/html/doc/cli/npm-stars.html
+++ b/deps/npm/html/doc/cli/npm-stars.html
@@ -35,5 +35,5 @@ you will most certainly enjoy this command.
-
+
diff --git a/deps/npm/html/doc/cli/npm-start.html b/deps/npm/html/doc/cli/npm-start.html
index d404e0b401..290514fe2f 100644
--- a/deps/npm/html/doc/cli/npm-start.html
+++ b/deps/npm/html/doc/cli/npm-start.html
@@ -38,5 +38,5 @@ more details.
-
+
diff --git a/deps/npm/html/doc/cli/npm-stop.html b/deps/npm/html/doc/cli/npm-stop.html
index aabfdb3c22..0772054742 100644
--- a/deps/npm/html/doc/cli/npm-stop.html
+++ b/deps/npm/html/doc/cli/npm-stop.html
@@ -33,5 +33,5 @@
-
+
diff --git a/deps/npm/html/doc/cli/npm-team.html b/deps/npm/html/doc/cli/npm-team.html
index 1e92c1f8be..c3f1bf904a 100644
--- a/deps/npm/html/doc/cli/npm-team.html
+++ b/deps/npm/html/doc/cli/npm-team.html
@@ -69,5 +69,5 @@ use the npm access
command to grant or revoke the appropriate permi
-
+
diff --git a/deps/npm/html/doc/cli/npm-test.html b/deps/npm/html/doc/cli/npm-test.html
index 272a7694af..ec68c6323b 100644
--- a/deps/npm/html/doc/cli/npm-test.html
+++ b/deps/npm/html/doc/cli/npm-test.html
@@ -35,5 +35,5 @@
-
+
diff --git a/deps/npm/html/doc/cli/npm-token.html b/deps/npm/html/doc/cli/npm-token.html
index 810bd4c93c..238ee91fbc 100644
--- a/deps/npm/html/doc/cli/npm-token.html
+++ b/deps/npm/html/doc/cli/npm-token.html
@@ -70,4 +70,4 @@ This will NOT accept the truncated token found in npm token list
ou
-
+
diff --git a/deps/npm/html/doc/cli/npm-uninstall.html b/deps/npm/html/doc/cli/npm-uninstall.html
index 9f9656ec23..552deef7f8 100644
--- a/deps/npm/html/doc/cli/npm-uninstall.html
+++ b/deps/npm/html/doc/cli/npm-uninstall.html
@@ -60,5 +60,5 @@ npm uninstall lodash --no-save
If no package name is specified, all packages in the specified location (global or local) will be updated.
-As of `npm@2.6.1, the
npm updatewill only inspect top-level packages.
-Prior versions of
npmwould also recursively inspect all dependencies.
-To get the old behavior, use
npm --depth 9999 update`.
As of `npm@5.0.0 As of As of , the
npm updatewill change
package.jsonto save the
+
npm update --no-save`.npm@2.6.1
, the npm update
will only inspect top-level packages.
+Prior versions of npm
would also recursively inspect all dependencies.
+To get the old behavior, use npm --depth 9999 update
.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
.
IMPORTANT VERSION NOTE: these examples assume `npm@2.6.1or later. For
-older versions of
npm, you must specify
--depth 0` to get the behavior
+
IMPORTANT VERSION NOTE: these examples assume npm@2.6.1
or later. For
+older versions of npm
, you must specify --depth 0
to get the behavior
described below.
For the examples below, assume that the current package is app
and it depends
on dependencies, dep1
(dep2
, .. etc.). The published versions of dep1
are:
dep1
(dep2
, .. etc.). The published
If app
's package.json
contains:
"dependencies": {
"dep1": "^1.1.1"
-}
Then npm update
will install `dep1@1.2.2, because
1.2.2is
latestand
1.2.2satisfies
^1.1.1`.
Then npm update
will install dep1@1.2.2
, because 1.2.2
is latest
and
+1.2.2
satisfies ^1.1.1
.
However, if app
's package.json
contains:
"dependencies": {
"dep1": "~1.1.1"
-}
In this case, running npm update
will install `dep1@1.1.2. Even though the
latesttag points to
1.2.2, this version does not satisfy
1.1.11.1.1, which is equivalent
-to
>=1.1.1 <1.2.0. So the highest-sorting version that satisfies
is used,
-which is
1.1.2`.
In this case, running npm update
will install dep1@1.1.2
. Even though the latest
+tag points to 1.2.2
, this version does not satisfy ~1.1.1
, which is equivalent
+to >=1.1.1 <1.2.0
. So the highest-sorting version that satisfies ~1.1.1
is used,
+which is 1.1.2
.
Suppose app
has a caret dependency on a version below 1.0.0
, for example:
"dependencies": {
"dep1": "^0.2.0"
-}
npm update
will install `dep1@0.2.0, because there are no other
-versions which satisfy
^0.2.0`.
npm update
will install dep1@0.2.0
, because there are no other
+versions which satisfy ^0.2.0
.
If the dependence were on ^0.4.0
:
"dependencies": {
"dep1": "^0.4.0"
-}
Then npm update
will install `dep1@0.4.1, because that is the highest-sorting
-version that satisfies
^0.4.0(
>= 0.4.0 <0.5.0`)
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
)
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
@@ -98,5 +100,5 @@ be downgraded.
javascript package manager
npm <command> [args]
6.4.1
+6.5.0-next.0
npm is the package manager for the Node JavaScript platform. It puts modules in place so that node can find them, and manages dependency @@ -130,7 +130,7 @@ reproduction to report.
Isaac Z. Schlueter :: isaacs :: @izs :: -i@izs.me
+i@izs.meSince foo depends directly on `bar@1.2.3and
baz@1.2.3, those are
-installed in foo's
node_modules` folder.
Since foo depends directly on bar@1.2.3
and baz@1.2.3
, those are
+installed in foo's node_modules
folder.
Even though the latest copy of blerg is 1.3.7, foo has a specific
dependency on version 1.2.5. So, that gets installed at [A]. Since the
-parent installation of blerg satisfies bar's dependency on `blerg@1.x`,
+parent installation of blerg satisfies bar's dependency on blerg@1.x
,
it does not install another copy under [B].
Bar [B] also has dependencies on baz and asdf, so those are installed in
-bar's node_modules
folder. Because it depends on `baz@2.x, it cannot
-re-use the
baz@1.2.3installed in the parent
node_modules` folder [D],
+bar's node_modules
folder. Because it depends on baz@2.x
, it cannot
+re-use the baz@1.2.3
installed in the parent node_modules
folder [D],
and must install its own copy [C].
Underneath bar, the baz -> quux -> bar
dependency creates a cycle.
However, because bar is already in quux's ancestry [B], it does not
@@ -179,5 +179,5 @@ cannot be found elsewhere. See packa
-
+
diff --git a/deps/npm/html/doc/files/npm-global.html b/deps/npm/html/doc/files/npm-global.html
index 95285eead0..39b4c88786 100644
--- a/deps/npm/html/doc/files/npm-global.html
+++ b/deps/npm/html/doc/files/npm-global.html
@@ -133,15 +133,15 @@ highest level possible, below the localized "target" folder.
Since foo depends directly on `bar@1.2.3and
baz@1.2.3, those are
-installed in foo's
node_modules` folder.
Since foo depends directly on bar@1.2.3
and baz@1.2.3
, those are
+installed in foo's node_modules
folder.
Even though the latest copy of blerg is 1.3.7, foo has a specific
dependency on version 1.2.5. So, that gets installed at [A]. Since the
-parent installation of blerg satisfies bar's dependency on `blerg@1.x`,
+parent installation of blerg satisfies bar's dependency on blerg@1.x
,
it does not install another copy under [B].
Bar [B] also has dependencies on baz and asdf, so those are installed in
-bar's node_modules
folder. Because it depends on `baz@2.x, it cannot
-re-use the
baz@1.2.3installed in the parent
node_modules` folder [D],
+bar's node_modules
folder. Because it depends on baz@2.x
, it cannot
+re-use the baz@1.2.3
installed in the parent node_modules
folder [D],
and must install its own copy [C].
Underneath bar, the baz -> quux -> bar
dependency creates a cycle.
However, because bar is already in quux's ancestry [B], it does not
@@ -179,5 +179,5 @@ cannot be found elsewhere. See packa
-
+
diff --git a/deps/npm/html/doc/files/npm-json.html b/deps/npm/html/doc/files/npm-json.html
index 5d9a0f79b6..119efcc09a 100644
--- a/deps/npm/html/doc/files/npm-json.html
+++ b/deps/npm/html/doc/files/npm-json.html
@@ -574,5 +574,5 @@ ignored.
node_modules
, so you
if any transitive dependencies were updated, hoisted, etc.
Occasionally, two separate npm install will create package locks that cause
-merge conflicts in source control systems. As of `npm@5.7.0, these conflicts
-can be resolved by manually fixing any
package.jsonconflicts, and then
-running
npm install [--package-lock-only]again. npm will automatically
+merge conflicts in source control systems. As of
--package-lock-onlynpm@5.7.0
, these conflicts
+can be resolved by manually fixing any package.json
conflicts, and then
+running npm install [--package-lock-only]
again. npm will automatically
resolve any conflicts for you and write a merged package lock that includes all
-the dependencies from both branches in a reasonable tree. Ifis provided, it will do this without also modifying your
-local
node_modules/`.
--package-lock-only
is provided, it will do this without also modifying your
+local node_modules/
.
To make this process seamless on git, consider installing
npm-merge-driver
, which will teach git how
to do this itself without any user interaction. In short: $ npx
npm-merge-driver install -g
will let you do this, and even works with
-pre-`npm@5.7.0versions of npm 5, albeit a bit more noisily. Note that if
package.jsonitself conflicts, you will have to resolve that by hand and run
npm install` manually, even with the merge driver.
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.
npm owner ls <pkgname>
Don't squat on package names. Publish code or move out of the way.
@@ -58,13 +58,13 @@ because Yusuf'sfoo
is in the way.
Alice emails Yusuf, explaining the situation as respectfully as possible,
and what she would like to do with the module name. She adds the npm support
-staff support@npmjs.com to the CC list of the email. Mention in the email
+staff support@npmjs.com to the CC list of the email. Mention in the email
that Yusuf can run npm owner add alice foo
to add Alice as an owner of the
foo package.
After a reasonable amount of time, if Yusuf has not responded, or if Yusuf and Alice can't come to any sort of resolution, email support -support@npmjs.com and we'll sort it out. ("Reasonable" is usually at least +support@npmjs.com and we'll sort it out. ("Reasonable" is usually at least 4 weeks.)
If you see bad behavior like this, please report it to abuse@npmjs.com right +
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.
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 +using a confusingly similar package name, email abuse@npmjs.com with a link to the package or user account on https://www.npmjs.com/. Attach a copy of your trademark registration certificate.
If we see that the package's publisher is intentionally misleading others by @@ -139,5 +139,5 @@ License.
Npm-In-CI
– Set to "true" if npm believes this install is running in a
-continous integration environment, "false" otherwise. This is detected by
+continuous integration environment, "false" otherwise. This is detected by
looking for the following environment variables: CI
, TDDIUM
,
JENKINS_URL
, bamboo.buildKey
. If you'd like to learn more you may find
the original PR
@@ -96,5 +96,5 @@ effectively implement the entire CouchDB API anyway.
npm
install
without any arguments. (See below)npm
-install
without any arguments (See below). This is run
-AFTER prepublish
, but BEFORE prepublishOnly
.npm
+install
without any arguments, and when installing git dependencies (See
+below). This is run AFTER prepublish
, but BEFORE prepublishOnly
.
npm publish
. (See
below.)npm shrinkwrap
command.
Additionally, arbitrary scripts can be executed by running npm
run-script <stage>
. Pre and post commands with matching
names will be run for those as well (e.g. premyscript
, myscript
,
-postmyscript
). Scripts from dependencies can be run with npm explore
-<pkg> -- npm run <stage>
.
postmyscript
). Scripts from dependencies can be run with
+npm explore <pkg> -- npm run <stage>
.
Since `npm@1.1.71 Since , the npm CLI has run the
prepublishscript for both
npm
-publishand
npm install, because it's a convenient way to prepare a package
+
npm@4.0.0npm@1.1.71
, the npm CLI has run the prepublish
script for both npm
+publish
and npm install
, because it's a convenient way to prepare a package
for use (some common use cases are described in the section below). It has
-also turned out to be, in practice, [very
-confusing](https://github.com/npm/npm/issues/10074). As of, a new
-event has been introduced,
prepare, that preserves this existing behavior. A
-_new_ event,
prepublishOnlyhas been added as a transitional strategy to
+also turned out to be, in practice, very
+confusing. As of
npm publish` (for instance, running the tests one last time to ensure
+run on npm@4.0.0
, a new
+event has been introduced, prepare
, that preserves this existing behavior. A
+new event, prepublishOnly
has been added as a transitional strategy to
allow users to avoid the confusing behavior of existing npm versions and only
-run onnpm publish
(for instance, running the tests one last time to ensure
they're in good shape).
See https://github.com/npm/npm/issues/10074 for a much lengthier justification, with further reading, for this change.
@@ -234,5 +234,5 @@ scripts is for compilation which must be done on the target architecture.9999999999999999.4.7.4
is like