npm-link

创建包文件夹的符号链接

选择 CLI 版本

概要

npm link [<package-spec>]
alias: ln

描述

这对于安装你自己的东西非常有用,这样你就可以在上面工作并进行迭代测试,而无需不断地重新构建。

包链接是一个两步过程。

首先,在没有参数的包文件夹中运行 npm link 将在全局文件夹 {prefix}/lib/node_modules/<package> 中创建一个符号链接,该链接指向执行 npm link 命令的包。它还会将包中的任何 bin 链接到 {prefix}/bin/{name}。请注意,npm link 使用全局前缀(见 npm prefix -g 获取其值)。

接下来,在其他位置,npm link package-name 将从全局安装的 package-name 创建一个符号链接到当前文件夹的 node_modules/

请注意,package-name 取自 package.json而不是目录名称。

包名称可以可选地以作用域为前缀。见 scope。作用域必须以 @ 符号开头,后面跟着斜杠。

当为 npm publish 创建 tarball 时,如果链接的包包含在 bundleDependencies 中,则会通过解析符号链接将其“快照”到当前状态。

例如

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

现在,对 ~/projects/node-redis 的任何更改都将反映在 ~/projects/node-bloggy/node_modules/node-redis/ 中。请注意,链接应指向包名称,而不是该包的目录名称。

你也可以在一个步骤中完成这两个步骤。例如,要以更简短的方式完成上述用例

cd ~/projects/node-bloggy # go into the dir of your main project
npm link ../node-redis # link the dir of your dependency

第二行等效于执行

(cd ../node-redis; npm link)
npm link redis

也就是说,它首先创建全局链接,然后将全局安装的目标链接到你的项目的 node_modules 文件夹。

请注意,在这种情况下,你引用的是目录名称,node-redis,而不是包名称 redis

如果你的链接包是作用域的(见 scope),你的链接命令必须包含该作用域,例如

npm link @myorg/privatepackage

注意事项

请注意,以这种方式链接的包依赖项不会默认情况下保存到 package.json 中,假设是为了让链接代表一个普通的非链接依赖项。否则,例如,如果你依赖于 redis@^3.0.1 并运行 npm link redis,它将用 file:../path/to/node-redis 替换 ^3.0.1 依赖项,这可能不是你想要的!此外,你的项目中的其他用户或开发人员如果他们的文件夹设置与你的完全不同,就会遇到问题。

如果你要添加一个依赖项作为链接,你应该通过运行 npm install <dep> --package-lock-only 将其添加到相关的元数据中。

如果你file: 引用保存到 package.jsonpackage-lock.json 文件中,你可以使用 npm link <dep> --save 来完成。

工作区使用

npm link <pkg> --workspace <name> 将将相关包链接为指定工作区(或工作区)的依赖项。请注意,如果不存在冲突的依赖项,它实际上可能被链接到父项目的 node_modules 文件夹。

npm link --workspace <name> 将创建一个指向指定工作区(或工作区)的全局链接。

配置

save

  • 默认:true,除非使用 npm update,在这种情况下默认值为 false
  • 类型:布尔值

将安装的包保存到 package.json 文件作为依赖项。

npm rm 命令一起使用时,会从 package.json 中删除依赖项。

如果设置为 false,也将阻止写入 package-lock.json

save-exact

  • 默认:false
  • 类型:布尔值

保存到 package.json 的依赖项将使用精确版本进行配置,而不是使用 npm 的默认 semver 范围运算符。

global

  • 默认:false
  • 类型:布尔值

以“全局”模式运行,因此包将安装到 prefix 文件夹中,而不是当前工作目录。有关行为差异的更多信息,请参见 文件夹

  • 包将安装到 {prefix}/lib/node_modules 文件夹中,而不是当前工作目录。
  • bin 文件链接到 {prefix}/bin
  • 手册页链接到 {prefix}/share/man

install-strategy

  • 默认值:“hoisted”
  • 类型:“hoisted”、“nested”、“shallow” 或 “linked”

设置在 node_modules 中安装包的策略。hoisted(默认):将非重复项安装到顶层,并在目录结构中根据需要重复安装。nested:(以前称为 --legacy-bundling)就地安装,不提升。shallow:(以前称为 --global-style)仅在顶层安装直接依赖项。linked:(实验性)安装在 node_modules/.store 中,就地链接,不提升。

legacy-bundling

  • 默认:false
  • 类型:布尔值
  • 已弃用:此选项已被弃用,取而代之的是 --install-strategy=nested

不将包安装提升到 node_modules 中,而是以与它们依赖的方式相同的方式安装包。这可能会导致非常深的目录结构和重复的包安装,因为没有去重。设置 --install-strategy=nested

global-style

  • 默认:false
  • 类型:布尔值
  • 已弃用:此选项已被弃用,取而代之的是 --install-strategy=shallow

仅在顶层 node_modules 中安装直接依赖项,但在更深层的依赖项上提升。设置 --install-strategy=shallow

strict-peer-deps

  • 默认:false
  • 类型:布尔值

如果设置为 true,并且 --legacy-peer-deps 未设置,那么任何冲突的 peerDependencies 都将被视为安装失败,即使 npm 可以根据非对等依赖关系合理地猜测合适的解析。

默认情况下,依赖关系图中深处冲突的 peerDependencies 将使用最近的非对等依赖项规范解析,即使这样做会导致某些包接收超出其包的 peerDependencies 对象中设置的范围的对等依赖项。

执行此类覆盖时,将打印一条警告,说明冲突以及涉及的包。如果设置了 --strict-peer-deps,那么此警告将被视为失败。

package-lock

  • 默认值:true
  • 类型:布尔值

如果设置为 false,则在安装时忽略 package-lock.json 文件。如果 save 为 true,这也将阻止写入 package-lock.json

omit

  • 默认值:如果 NODE_ENV 环境变量设置为 'production',则为 'dev',否则为空。
  • 类型:“dev”、“optional” 或 “peer”(可以设置多次)

要从磁盘上的安装树中省略的依赖项类型。

请注意,这些依赖项仍然会被解析并添加到 package-lock.jsonnpm-shrinkwrap.json 文件中。它们只是没有在磁盘上实际安装。

如果包类型同时出现在 --include--omit 列表中,那么它将被包含。

如果结果省略列表包含 'dev',那么对于所有生命周期脚本,NODE_ENV 环境变量将设置为 'production'

include

  • 默认值
  • 类型:“prod”、“dev”、“optional” 或 “peer”(可以设置多次)

允许定义要安装的依赖项类型的选项。

这是 --omit=<type> 的反面。

--include 中指定的依赖项类型不会被省略,无论在命令行上省略/包含的指定顺序如何。

ignore-scripts

  • 默认:false
  • 类型:布尔值

如果为 true,npm 不会运行 package.json 文件中指定的脚本。

请注意,明确旨在运行特定脚本的命令,例如 npm startnpm stopnpm restartnpm testnpm run-script 仍然会运行它们预期的脚本,如果设置了 ignore-scripts,但它们不会运行任何预先或后期脚本。

audit

  • 默认值:true
  • 类型:布尔值

当“true”时,将审计报告与当前 npm 命令一起提交到默认注册表和为范围配置的所有注册表。有关提交内容的详细信息,请参阅 npm audit 的文档。

  • 默认值:true
  • 类型:布尔值

告诉 npm 为包可执行文件创建符号链接(或在 Windows 上创建 .cmd shims)。

设置为 false 以使其不执行此操作。这可用于解决某些文件系统不支持符号链接这一事实,即使在表面上是 Unix 系统上也是如此。

fund

  • 默认值:true
  • 类型:布尔值

当“true”时,将在每个 npm install 的末尾显示消息,确认正在寻找资金的依赖项数量。有关详细信息,请参阅 npm fund

dry-run

  • 默认:false
  • 类型:布尔值

指示您不希望 npm 进行任何更改,并且它应该只报告它本来会做的事情。这可以传递给任何修改本地安装的命令,例如 installupdatededupeuninstall,以及 packpublish

注意:其他与网络相关的命令(例如 dist-tagsowner 等)不遵守此设置。

workspace

  • 默认值
  • 类型:String(可以设置多次)

启用在当前项目的已配置工作区上下文中运行命令,同时通过仅运行此配置选项定义的工作区进行过滤。

workspace 配置的有效值是

  • 工作区名称
  • 工作区目录的路径
  • 父工作区目录的路径(将导致选择该文件夹中的所有工作区)

当为 npm init 命令设置时,这可以设置为尚未存在的工作区的文件夹,以创建文件夹并将其设置为项目中的全新工作区。

此值不会导出到子进程的环境中。

workspaces

  • 默认值:null
  • 类型:null 或 Boolean

设置为 true 以在所有已配置工作区上下文中运行命令。

明确将其设置为 false 将导致像 install 这样的命令完全忽略工作区。当未明确设置时

  • node_modules 树进行操作的命令(install、update 等)将链接工作区到 node_modules 文件夹中。- 执行其他操作的命令(test、exec、publish 等)将对根项目进行操作,除非workspace 配置中指定了一个或多个工作区。

此值不会导出到子进程的环境中。

include-workspace-root

  • 默认:false
  • 类型:布尔值

在为命令启用工作区时,包括工作区根目录。

当为 false 时,通过 workspace 配置指定单个工作区,或通过 workspaces 标志指定所有工作区,将导致 npm 仅对指定的工作区进行操作,而不是对根项目进行操作。

此值不会导出到子进程的环境中。

  • 默认:false
  • 类型:布尔值

当设置时,file: 协议依赖项将被打包并安装为常规依赖项,而不是创建符号链接。此选项对工作区没有影响。

另请参见