npm install 全方位解读

本文参考了NPM中文文档写做而成的

npm install 功能

安装软件包

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>

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]

npm install 说明

此命令将安装软件包及其依赖的任何软件包。若是程序包具备程序包锁定或收缩包装文件，则依赖项的安装将由该程序驱动，npm-shrinkwrap.json 若是两个文件都存在，则优先。请参阅 package-lock.json 和 npm- shrinkwrap。

A package 是：

• a）包含文件描述的程序的 package.json 文件夹
• b）包含（a）的压缩 tarball
• c）解析为（b）的网址
• d）<name>@<version>在 npm-registry（c）的注册表中发布的 a
• e）指向（d）的 a <name>@<tag>（参见 npm-dist-tag）
• f）<name>具备知足（e）的“最新”标签的 a
• g）<git remote url>解析为（a）的 a

即便您从未发布过软件包，若是您只想编写一个节点程序（a），或者若是您还但愿可以在打包后将其轻松安装到其余地方，使用 npm 仍然能够得到不少好处。放入压缩档（b）。

npm install

在软件包目录中，没有参数：

将依赖项安装在本地 node_modules 文件夹中。

在全局模式下（即，带有命令 -g 或 --global 附加到命令后），它将当前程序包上下文（即，当前工做目录）安装为全局程序包。

默认状况下，npm install 将安装列为依赖项的全部模块 package.json。

使用该 --production 标志（或将 NODE_ENV 环境变量设置为 production）时，npm 将不会安装中列出的模块 devDependencies。

注意：将 --production 依赖项添加到项目时，该标志没有特殊含义。

npm install <folder>：

将软件包做为当前项目中的符号连接安装在目录中。它的依赖项将在连接以前安装。若是<folder>位于项目的根目录下，则其依赖关系可能会 node_modules 像其余类型的依赖关系同样被提高到顶层。

npm install <tarball file>：

安装位于文件系统上的软件包。注意：若是只想将 dev 目录连接到 npm 根目录，则可使用来更轻松地作到这一点 npm link。

Tarball 要求：

• 文件名必须使用。tar，.tar.gz 或。tgz 做为扩展名。
• 包装内容应位于 tarball 的子文件夹中（一般称为 package/）。安装软件包时，npm 会剥离一个目录层（至关于 tar x --strip-components=1 运行）。
• 程序包必须包含 package.json 具备 name 和 version 属性的文件。

例：

npm install ./package.tgz

npm install <tarball url>

提取 tarball 网址，而后安装它。为了区分此选项和其余选项，参数必须以“ http：//”或“ https：//”开头

例：

npm install https://github.com/indexzero/forever/tarball/v0.5.6

npm install [<@scope>/]<name>

进行<name>@<tag>安装，<tag>“标签”配置在哪里。（请参阅 npm config
。配置的默认值为 latest。）

在大多数状况下，这将安装 latest 在 npm 注册表上标记为的模块的版本 。

例：

npm install sax

npm install dependencies 默认将全部指定的软件包保存到其中。此外，您可使用一些其余标志来控制在何处以及如何保存它们：

• -P, --save-prod：包将出如今您的中 dependencies。这是默认设置，除非 -D 或 -O 存在。
• -D, --save-dev：包将出如今您的中 devDependencies。
• -O, --save-optional：包将出如今您的中 optionalDependencies。
• --no-save：防止保存到 dependencies。

使用上述任何选项将依赖项保存到 package.json 时，还有两个附加的可选标志：

• -E, --save-exact 注意：保存的依赖项将使用确切的版本配置，而不是使用 npm 的默认 semver range 运算符。
• -B, --save-bundle：保存的依赖项也将添加到您的 bundleDependencies 列表中。

此外，若是您具备 npm-shrinkwrap.json 或，package-lock.json 那么它也会被更新。

<scope>是可选的。该包将从与指定范围关联的注册表中下载。若是没有注册表与给定范围相关联，则采用默认注册表。请参阅 npm-scope。

注意：若是您的做用域名称上未包含 @ -symbol，则 npm 会将其解释为 GitHub 存储库，请参见下文。范围名称也必须后面加上斜杠。

例子：

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

注意：若是<name>当前工做目录中有一个文件或文件夹命名，则它将尝试安装该文件或文件夹，而且仅在名称无效时才尝试按名称获取该软件包。

npm install [<@scope>/]<name>@<tag>

安装指定标签引用的软件包的版本。若是该程序包的注册表数据中不存在该标记，则此操做将失败。

例：

npm install sax@latest
    npm install @myorg/mypackage@latest

npm install [<@scope>/]<name>@<version>

安装指定版本的软件包。若是该版本还没有发布到注册表，则将失败。

例：

npm install sax@0.1.1
    npm install @myorg/privatepackage@1.5.0

npm install [<@scope>/]<name>@<version range>

安装与指定版本范围匹配的软件包版本。这将遵循解决依赖性的相同规则 package.json。

请注意，大多数版本范围必须用引号引发来，以便您的外壳将其视为单个参数。

例：

npm install sax@">=0.1.0 <0.2.0"
    npm install @myorg/privatepackage@">=0.1.0 <0.2.0"

npm install <git remote url>

从托管的 git 提供程序安装软件包，并使用克隆该软件包 git。对于完整的 git 远程 URL，将仅尝试该 URL。

<protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish> | #semver:<semver>]

<protocol>是如下之一 git，git+ssh，git+http，git+https，或 git+file。

若是#<commit-ish>提供，它将用于精确克隆该提交。若是 commit-ish 的格式为#semver:<semver>，则<semver>能够是任何有效的 semver 范围或确切的版本，而且 npm 会在远程存储库中查找与该范围匹配的任何标记或引用，这与注册表依赖性相似。若是未指定#<commit-ish>或#semver:<semver>，则使用存储库的默认分支。

若是存储库使用了子模块，那么这些子模块也将被克隆。

若是要安装的软件包包含 prepare 脚本， 则在打包和安装软件包以前 dependencies，devDependencies 将安装和，并运行 prepare 脚本。

如下 git 环境变量被 npm 识别，并在运行 git 时添加到环境中：

• GIT_ASKPASS
• GIT_EXEC_PATH
• GIT_PROXY_COMMAND
• GIT_SSH
• GIT_SSH_COMMAND
• GIT_SSL_CAINFO
• GIT_SSL_NO_VERIFY

有关详细信息，请参见 git 手册页。

例子：

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>]

https://github.com/githubname/githubrepo 经过尝试使用克隆它来安装软件包 git。

若是#<commit-ish>提供，它将用于精确克隆该提交。若是 commit-ish 的格式为#semver:<semver>，则<semver>能够是任何有效的 semver 范围或确切的版本，而且 npm 会在远程存储库中查找与该范围匹配的任何标记或引用，这与注册表依赖性相似。若是未指定#<commit-ish>或#semver:<semver>，则 master 使用。

与常规 git 的依赖，dependencies 而且 devDependencies 将安装若是包有一个 prepare 脚本，作包，而后再安装。

例子：

npm install mygithubuser/myproject
    npm install github:mygithubuser/myproject

npm install gist:[<githubname>/]<gistID>[#<commit-ish>|#semver:<semver>]

https://gist.github.com/gistID 经过尝试使用克隆它来安装软件包 git。与 gist 关联的 GitHub 用户名是可选的，不会保存在中 package.json。

与常规 git 的依赖，dependencies 而且 devDependencies 将安装若是包有一个 prepare 脚本，作包，而后再安装。

例：

npm install gist:101a11beef

npm install bitbucket:<bitbucketname>/<bitbucketrepo>[#<commit-ish>]

https://bitbucket.org/bitbucketname/bitbucketrepo 经过尝试使用克隆它来安装软件包 git。

若是#<commit-ish>提供，它将用于精确克隆该提交。若是 commit-ish 的格式为#semver:<semver>，则<semver>能够是任何有效的 semver 范围或确切的版本，而且 npm 会在远程存储库中查找与该范围匹配的任何标记或引用，这与注册表依赖性相似。若是未指定#<commit-ish>或#semver:<semver>，则 master 使用。

与常规 git 的依赖，dependencies 而且 devDependencies 将安装若是包有一个 prepare 脚本，作包，而后再安装。

例：

npm install bitbucket:mybitbucketuser/myproject：

npm install gitlab:<gitlabname>/<gitlabrepo>[#<commit-ish>]

https://gitlab.com/gitlabname/gitlabrepo 经过尝试使用克隆它来安装软件包 git。

若是#<commit-ish>提供，它将用于精确克隆该提交。若是 commit-ish 的格式为#semver:<semver>，则<semver>能够是任何有效的 semver 范围或确切的版本，而且 npm 会在远程存储库中查找与该范围匹配的任何标记或引用，这与注册表依赖性相似。若是未指定#<commit-ish>或#semver:<semver>，则 master 使用。

与常规 git 的依赖，dependencies 而且 devDependencies 将安装若是包有一个 prepare 脚本，作包，而后再安装。

例：

npm install gitlab:mygitlabuser/myproject
npm install gitlab:myusr/myproj#semver:^5.0：

您能够组合多个参数，甚至多种类型的参数。例如：
：

npm install sax@">=0.1.0 <0.2.0" bench supervisor：

该--tag 参数将应用于全部指定的安装目标。若是存在具备给定名称的标签，则带标签的版本优先于较新的版本。

该--dry-run 参数将以一般的方式报告在没有实际安装任何内容的状况下安装将完成的操做。

在--package-lock-only 争吵只会更新 package-lock.json，而不是检查 node_modules 和下载依赖。

即便磁盘上存在本地副本，-for --force 参数也将强制 npm 获取远程资源。

npm install sax --force：

该-g 或--global 参数会致使 NPM 在全球范围内，而不是在本地安装包。请参阅 npm-folders。

该--global-style 参数将使 npm 以 node_modules 与全局 node_modules 文件夹相同的布局将软件包安装到本地文件夹中。只有直接依赖项会显示在其中 node_modules，它们所依赖的全部内容都将在其 node_modules 文件夹中展平 。显然，这将消除一些重复数据删除。

该--ignore-scripts 参数将致使 npm 不执行 package.json 中定义的任何脚本。请参阅 npm-scripts。

该--legacy-bundling 参数将致使 npm 安装软件包，以便 1.4 以前的 npm 版本（例如节点 0.8 附带的版本）能够安装软件包。这消除了全部自动重复数据删除。

--link 在某些状况下，该参数将致使 npm 将全局安装连接到本地 ​​ 空间。

该--no-bin-links 参数将阻止 npm 为软件包可能包含的任何二进制文件建立符号连接。

该--no-optional 参数将防止安装可选的依赖项。

该--no-shrinkwrap 参数将忽略可用的程序包锁定或收缩包装文件，而改用 package.json。

该--no-package-lock 参数将阻止 npm 建立 package-lock.json 文件。在禁用包锁的状况下运行时，npm 不会在安装时自动修剪节点模块。

该 --nodedir=/path/to/node/source 参数将容许 npm 查找节点源代码，以便 npm 能够编译本机模块。

该--only={prod[uction]|dev[elopment]}参数将致使仅 安装 devDependencies 或仅非 devDependencies 安装 NODE_ENV。

该--no-audit 参数可用于禁用将审核报告发送到已配置的注册表。有关 npm-audit 详细信息，请参见。

请参阅 npm config
。许多配置参数都会对安装产生影响，由于这是 npm 的大部分工做。

算法

要安装软件包，npm 使用如下算法：
：

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：

对于如下 package{dep}结构：A{B,C}, B{C}, C{D}，此算法产生：
：

A
+-- B
+-- C
+-- D：

即，经过 A 已经使 C 被安装在更高级别的事实，知足了从 B 到 C 的依赖性。D 仍安装在顶层，由于没有冲突。

对于 A{B,C}, B{C,D@1}, C{D@2}，此算法产生：
：

A
+-- B
+-- C
`-- D@2
+-- D@1：

因为 B 的 D @ 1 将安装在顶层，所以 C 如今必须 本身私下安装 D @ 2 。该算法是肯定性的，可是若是请求以两个不一样的顺序安装两个依赖项，则可能会生成不一样的树。

有关 npm 建立的特定文件夹结构的详细说明，请参见 npm-folders。

npm 安装算法的局限性

npm 将拒绝安装任何与当前软件包名称相同的软件包。能够用该 --force 标志覆盖它，可是在大多数状况下，能够经过更改本地程序包名称来解决。

在一些很是罕见的病理性极端状况下，循环可能致使 npm 尝试安装永无休止的软件包树。这是最简单的状况：
：

A -> B -> A' -> B' -> A -> B -> A' -> B' -> A -> ...：

其中 A 是某个程序包的某个版本，而且 A'是同一程序包的另外一个版本。因为所 B 依赖的版本 A 与树中已有版本的版本不一样，所以必须安装单独的副本。一样 A'，必须安装 B'。因为 B' 取决于的原始版本（A 已被覆盖），所以循环陷入无限回归。

为了不这种状况，npm flat-out 拒绝安装 name@version 软件包文件夹祖先树中任何位置已经存在的任何内容。一个更正确但更复杂的解决方案是将现有版本符号连接到新位置。若是这影响了实际用例，将对其进行调查。

本文参考NPM中文文档