1、npm
在命令行,输入npm命令可以显示npm可以对应命令,如下图所示:
npm
1.1 简介
npm是Node JavaScript平台的包管理器。它将模块放在适当的位置,以便节点可以找到它们,并智能地管理依赖关系冲突。
它是可配置的,以支持各种用例。最常见的是,您使用它来发布、发现、安装和开发节点程序。
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将包安装到当前项目目录中, 默认为当前工作目录。 软件包安装到
./node_modules
- 全局模式: npm将包安装到安装前缀中
$npm_config_prefix/lib/node_modules
本地模式是默认模式。 在任何命令上使用-g
或--global
以全局模式运行。
2、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>传入,则列表将仅过滤到用户碰巧所属的团队。
2.2 详情
npm访问总是直接在当前注册表上操作,可以使用–registry=从命令行进行其他注册表配置<registry url>。
作用域包默认为受限的,但您可以使用npm publish —access=public将其发布为public,或者在初始发布后使用npm access public将其访问权限设置为public。
必须要有设置包访问权限的权限:
3、您已经被授予了对软件包的读写权限,无论是作为团队成员还是直接作为所有者。
如果您启用了双因素身份验证,则系统会提示您提供第二个因素证明,或者使用–otp=…选项在命令行上指定。
如果您的帐户没有付费,那么尝试发布范围内的软件包将失败,并显示HTTP 402状态码(逻辑上足够),除非您使用–access=public。
3、npm adduser
3.1 描述
在指定的注册表中创建新用户,并将凭据保存到.npmrc文件中。如果未指定注册表,则将使用默认注册表。
当auth–type为legacy时,用户名、密码和电子邮件将从提示中读入。
登录时使用什么身份验证策略。请注意,如果给定了otp配置,则该值将始终设置为legacy。
4、npm audit
使用命令如下:
npm audit [fix|signatures]
4.1 简介
audit命令将项目中配置的依赖项的描述提交到默认注册表,并要求提供已知漏洞的报告。如果发现任何漏洞,则将计算影响和适当的补救措施。如果提供了fix参数,则将对包树应用修正。
请注意,某些漏洞无法自动修复,需要手动干预或审查。还要注意的是,由于npm audit fix在后台运行了一个成熟的npm install,所有适用于安装程序的配置也将适用于npm install –所以像npm audit fix —package-lock–only这样的东西会像预期的那样工作。
默认情况下,如果发现任何漏洞,audit命令将以非零代码退出。在CI环境中,包含–audit-level参数以指定将导致命令失败的最低漏洞级别可能很有用。此选项不过滤报告输出,它只是更改命令的失败阈值。
4.2 审计签名
为了确保从公共npm注册表或任何支持签名的注册表下载的包的完整性,可以使用npm CLI验证下载包的注册表签名。
npm audit signatures
如果遵循以下约定,npm CLI支持任何注册表提供的注册表签名和签名密钥:
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
npm audit fix --only=prod
让 audit fix
对顶层依赖安装 SemVer 主要更新,而不仅仅是与 SemVer 兼容的更新:
npm audit fix --force
进行试运行以了解 audit fix
将做什么,并以 JSON 格式输出安装信息:
npm audit fix --dry-run --json
npm audit --json
npm audit --audit-level=moderate
4.4 配置
audit-level
dry-run
表示你不希望 npm 进行任何更改,并且它应该只报告它会做的事情。 这可以传递到任何修改本地安装的命令中,例如 install
、update
、dedupe
、uninstall
以及 pack
和 publish
。
注意: 其他网络相关命令不支持此功能,例如 dist-tags
、owner
等。
force
删除了针对不幸的副作用、常见错误、不必要的性能下降和恶意输入的各种保护。
- 允许在全局安装中破坏非 npm 文件。
- 允许
npm version
命令在不干净的 git 存储库上工作。 - 允许使用
npm cache clean
删除缓存文件夹。 - 允许安装具有
engines
声明需要不同版本的 npm 的包。 - 允许安装具有
engines
声明需要不同版本node
的包,即使启用了--engine-strict
。 - 允许
npm audit fix
安装超出你声明的依赖范围的模块(包括 SemVer 的主要更改)。 - 允许取消发布已发布包的所有版本。
- 允许在根项目中安装冲突的 peerDependencies。
- 在
npm init
时隐式设置--yes
。 - 允许破坏
npm pkg
中的现有值 - 允许取消发布整个包(不仅仅是单个版本)。
如果你对自己想要做什么没有明确的想法,强烈建议你不要使用此选项!
json
并非所有 npm 命令都支持。
package-lock-only
如果设置为 true,当前操作将只使用 package-lock.json
,忽略 node_modules
。
对于 update
,这意味着只会更新 package-lock.json
,而不是检查 node_modules
并下载依赖。
对于 list
,这意味着输出将基于 package-lock.json
描述的树,而不是 node_modules
的内容。
omit
请注意,这些依赖仍会被解析并添加到 package-lock.json
或 npm-shrinkwrap.json
文件中。 它们只是没有物理安装在磁盘上。
如果一个包类型同时出现在 --include
和 --omit
列表中,那么它将被包括在内。
如果生成的省略列表包含 'dev'
,则 NODE_ENV
环境变量将针对所有生命周期脚本设置为 'production'
。
foreground-scripts
- 默认值: false
- 类型: 布尔值
在前台进程中运行已安装包的所有构建脚本(即 preinstall
、install
和 postinstall
)脚本,与主 npm 进程共享标准输入、输出和错误。
请注意,这通常会使安装运行速度变慢,并且噪音更大,但对调试很有用。
ignore-scripts
如果为 true,npm 不会运行 package.json 文件中指定的脚本。
请注意,如果设置了 ignore-scripts
,则明确旨在运行特定脚本的命令(例如 npm start
、npm stop
、npm restart
、npm test
和 npm run-script
)仍将运行其预期的脚本,但它们不会运行任何前置或后置脚本。
workspace
启用在当前项目的已配置工作区的上下文中运行命令,同时通过仅运行此配置选项定义的工作区进行过滤。
为 npm init
命令设置时,可以将其设置为尚不存在的工作区的文件夹,以创建文件夹并将其设置为项目中的全新工作区。
workspaces
设置为 true 以在 all 配置的工作区的上下文中运行命令。
显式将此设置为 false 将导致像 install
这样的命令完全忽略工作区。 未明确设置时:
- 在
node_modules
树上运行的命令(安装、更新等)会将工作区链接到node_modules
文件夹。 – 执行其他操作(测试、执行、发布等)的命令将在根项目上运行,除非在workspace
配置中指定了一个或多个工作区。
include-workspace-root
为命令启用工作区时包括工作区根。
当为 false 时,通过 workspace
配置指定单个工作区,或通过 workspaces
标志指定所有工作区,将导致 npm 仅在指定的工作区上运行,而不是在根项目上运行。
此值不会导出到子进程的环境中。
install-links
- 默认值: false
- 类型: 布尔值
设置文件时: 协议依赖将作为常规依赖打包和安装,而不是创建符号链接。 此选项对工作区没有影响。
原文地址:https://blog.csdn.net/u014388408/article/details/132623958
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若转载,请注明出处:http://www.7code.cn/show_40088.html
如若内容造成侵权/违法违规/事实不符,请联系代码007邮箱:suwngjj01@126.com进行投诉反馈,一经查实,立即删除!