NPM 常用命令(一)

目录

1、npm

1.1 简介

1.2 依赖性

1.3 安装方式

2、npm access

2.1 命令描述

2.2 详情

3、npm adduser

3.1 描述

4、npm audit

4.1 简介

4.2 审计签名

4.3 操作示例

4.4 配置

audit-level

dry-run

force

json

package-lock-only

omit

foreground-scripts

ignore-scripts

workspace

workspaces

include-workspace-root


1、npm

在命令行,输入npm命令可以显示npm可以对应命令,如下图所示:

npm

1.1 简介

npm是Node JavaScript平台的包管理器。它将模块放在适当的位置,以便节点可以找到它们,并智能地管理依赖关系冲突。

它是可配置的,以支持各种用例。最常见的是,您使用它来发布、发现、安装和开发节点程序。

运行npm help以获取可用命令的列表。

npm预先配置为使用npm的公共注册表(默认),npm公共注册表的使用是受以下网站提供的使用条款约束

您可以配置npm使用您喜欢的任何兼容的注册表,甚至运行您自己的注册表。使用其他人的注册表受其使用条款的约束。

1.2 依赖性

如果一个包使用git URL列出了一个依赖项,npm将使用git命令安装该依赖项,如果没有安装,将生成一个错误。

如果npm尝试安装的包之一是本机节点模块,并且需要编译C++代码,则npm将使用node-gyp来完成该任务。对于Unix系统,node-gyp需要Python、make和像GCC这样的构建链。在Windows上,需要Python和Microsoft Visual Studio C++。

1.3 安装方式

npm 有两种安装方式:

  • 本地安装: npm将包安装到当前项目目录中, 默认为当前工作目录。 软件包安装到 ./node_modules
  • 全局模式: npm将包安装到安装前缀中 $npm_config_prefix/lib/node_modules

本地模式是默认模式。 在任何命令上使用-g--global 以全局模式运行。

2、npm access

npm access 可以设置已发布包的访问级别。

常用命令如下:

npm access public [<package>]
npm access restricted [<package>]
npm access grant <read-only|read-write> <scope:team> [<package>]
npm access revoke <scope:team> [<package>]
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>]

2.1 命令描述

对于所有子命令,如果没有包名传递给子命令,npm access将对当前工作目录中的包执行操作。

  • public / restricted(已弃用): 将包设置为可公开访问或受限制。
  • grant / revoke(已弃用):添加或删除用户和团队对包具有只读或读写访问权限的功能。
  • 2fa-required / 2fa-not-required(已弃用):配置包是否要求发布它的任何人在其帐户上启用双因素身份验证
  • ls-packages(已弃用):显示用户或团队能够访问的所有包沿着访问级别,只读公共包除外(它不会打印整个注册表列表)
  • ls-collaborators(已弃用):显示包的所有访问权限。将仅显示您至少具有读取访问权限的包的权限。如果<user>传入,则列表将仅过滤到用户碰巧所属的团队。
  • edit (未实现)

2.2 详情

npm访问总是直接在当前注册表上操作,可以使用--registry=从命令行进行其他注册表配置<registry url>。

未作用域的包始终是公共的。

作用域包默认为受限的,但您可以使用npm publish --access=public将其发布为public,或者在初始发布后使用npm access public将其访问权限设置为public。

必须要有设置包访问权限的权限:

1、您是未限定作用域或限定作用域的包的所有者

2、您是拥有范围的团队的成员。

3、您已经被授予了对软件包的读写权限,无论是作为团队成员还是直接作为所有者。

如果您启用了双因素身份验证,则系统会提示您提供第二个因素证明,或者使用--otp=...选项在命令行上指定。

如果您的帐户没有付费,那么尝试发布范围内的软件包将失败,并显示HTTP 402状态码(逻辑上足够),除非您使用--access=public。

团队和团队成员的管理是通过npm tean命令完成的。

3、npm adduser

3.1 描述

在指定的注册表中创建新用户,并将凭据保存到.npmrc文件中。如果未指定注册表,则将使用默认注册表。

当auth-type为legacy时,用户名、密码和电子邮件将从提示中读入。

auth-type

  • Default:“web”
  • Type: "legacy" or "web"

登录时使用什么身份验证策略。请注意,如果给定了otp配置,则该值将始终设置为legacy。

4、npm audit

使用命令如下:

npm audit [fix|signatures]

4.1 简介

audit命令将项目中配置的依赖项的描述提交到默认注册表,并要求提供已知漏洞的报告。如果发现任何漏洞,则将计算影响和适当的补救措施。如果提供了fix参数,则将对包树应用修正。

如果未发现漏洞,该命令将以0退出代码退出。

请注意,某些漏洞无法自动修复,需要手动干预或审查。还要注意的是,由于npm audit fix在后台运行了一个成熟的npm install,所有适用于安装程序的配置也将适用于npm install --所以像npm audit fix --package-lock-only这样的东西会像预期的那样工作。

默认情况下,如果发现任何漏洞,audit命令将以非零代码退出。在CI环境中,包含--audit-level参数以指定将导致命令失败的最低漏洞级别可能很有用。此选项不过滤报告输出,它只是更改命令的失败阈值。

如果包安全会如下所示:

如果有对应不安全的包,下面这个包严重级别为高级,如下所示:

4.2 审计签名

为了确保从公共npm注册表或任何支持签名的注册表下载的包的完整性,可以使用npm CLI验证下载包的注册表签名。

注册表签名可以使用以下audit命令进行验证:

npm audit signatures

如果遵循以下约定,npm CLI支持任何注册表提供的注册表签名和签名密钥:

1、签名在dist对象内的每个已发布版本的包的提供

例如:lodash v4.17.21

lodash - npm

https://registry.npmjs.org/ + "包名" + 对应版本号,可以查看对应签名。

sig 是使用以下模板生成的: ${package.name}@${package.version}:${package.dist.integrity} 和 keyid 必须匹配以下公共签名密钥之一。

{
    "keys":[
        {
            "expires":null,
            "keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA",
            "keytype":"ecdsa-sha2-nistp256",
            "scheme":"ecdsa-sha2-nistp256",    
"key":"MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE1Olb3zMAFFxXKHiIkQO5cJ3Yhl5i6UPp+IhuteBJbuHcA5UogKo0EWtlWwW6KSaKoTNEYL7JlCQiVnkhBktUgg=="
        }
    ]
}
  • expires: null 或简化的扩展 ISO 8601 format: YYYY-MM-DDTHH:mm:ss.sssZ
  • keydid: 公钥的 sha256 指纹
  • keytype: npm CLI 当前仅支持 ecdsa-sha2-nistp256
  • scheme: npm CLI 当前仅支持 ecdsa-sha2-nistp256
  • key: base64 编码的公钥

4.3 操作示例

扫描你的项目是否存在漏洞,并自动为易受攻击的依赖安装任何兼容更新:

npm audit fix

在不修改 node_modules 的情况下运行 audit fix,但仍然更新 pkglock:

npm audit fix --package-lock-only

跳过更新 devDependencies

npm audit fix --only=prod

让 audit fix 对顶层依赖安装 SemVer 主要更新,而不仅仅是与 SemVer 兼容的更新:

npm audit fix --force

进行试运行以了解 audit fix 将做什么,并以 JSON 格式输出安装信息:

npm audit fix --dry-run --json

获取 JSON 格式的详细审计报告:

npm audit --json

仅当结果包含中等或更高级别的漏洞时,审核才会失败:

npm audit --audit-level=moderate

4.4 配置

audit-level

  • 默认值: null
  • 类型: 空、"info"、"low"、"moderate"、"high"、"critical" 或 "none"

npm audit 以非零退出代码退出的最低漏洞级别。

dry-run

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

表示你不希望 npm 进行任何更改,并且它应该只报告它会做的事情。 这可以传递到任何修改本地安装的命令中,例如 installupdatededupeuninstall 以及 pack 和 publish

注意: 其他网络相关命令不支持此功能,例如 dist-tagsowner 等。

force

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

删除了针对不幸的副作用、常见错误、不必要的性能下降和恶意输入的各种保护。

  • 允许在全局安装中破坏非 npm 文件。
  • 允许 npm version 命令在不干净的 git 存储库上工作。
  • 允许使用 npm cache clean 删除缓存文件夹。
  • 允许安装具有 engines 声明需要不同版本的 npm 的包。
  • 允许安装具有 engines 声明需要不同版本 node 的包,即使启用了 --engine-strict
  • 允许 npm audit fix 安装超出你声明的依赖范围的模块(包括 SemVer 的主要更改)。
  • 允许取消发布已发布包的所有版本。
  • 允许在根项目中安装冲突的 peerDependencies。
  • 在 npm init 时隐式设置 --yes
  • 允许破坏 npm pkg 中的现有值
  • 允许取消发布整个包(不仅仅是单个版本)。

如果你对自己想要做什么没有明确的想法,强烈建议你不要使用此选项!

json

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

是否输出 JSON 数据,而不是正常输出。

  • 在 npm pkg set 中,它可以使用 JSON.parse() 解析集合值,然后再将它们保存到你的 package.json

并非所有 npm 命令都支持。

package-lock-only

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

如果设置为 true,当前操作将只使用 package-lock.json,忽略 node_modules

对于 update,这意味着只会更新 package-lock.json,而不是检查 node_modules 并下载依赖。

对于 list,这意味着输出将基于 package-lock.json 描述的树,而不是 node_modules 的内容。

omit

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

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

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

如果一个包类型同时出现在 --include 和 --omit 列表中,那么它将被包括在内。

如果生成的省略列表包含 'dev',则 NODE_ENV 环境变量将针对所有生命周期脚本设置为 'production'

foreground-scripts

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

在前台进程中运行已安装包的所有构建脚本(即 preinstallinstall 和 postinstall)脚本,与主 npm 进程共享标准输入、输出和错误。

请注意,这通常会使安装运行速度变慢,并且噪音更大,但对调试很有用。

ignore-scripts

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

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

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

workspace

  • 默认值:
  • 类型: 字符串(可以设置多次)

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

workspace 配置的有效值为:

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

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

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

workspaces

  • 默认值: null
  • 类型: 空值或布尔值

设置为 true 以在 all 配置的工作区的上下文中运行命令。

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

  • 在 node_modules 树上运行的命令(安装、更新等)会将工作区链接到 node_modules 文件夹。 - 执行其他操作(测试、执行、发布等)的命令将在根项目上运行,除非在 workspace 配置中指定了一个或多个工作区。

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

include-workspace-root

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

为命令启用工作区时包括工作区根。

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

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

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

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

猜你喜欢

转载自blog.csdn.net/u014388408/article/details/132623958
今日推荐