常用的npm scripts （一般命令）

官网地址

读取配置的位置

文档

npm 的配置性极高。它从 5 个地方读取配置选项。

命令行：使用设置配置--key val。所有键都带有值，即使它们是布尔值（配置解析器在解析时不知道选项是什么）。如果您不提供值（--key），则选项将设置为布尔值true。
环境变量：通过在环境变量名称前加上前缀来设置任何配置npm_config_。例如，export npm_config_key=val。
用户配置：文件$HOME/.npmrc是 ini 格式的配置列表。如果存在，则会对其进行解析。如果userconfig在 cli 或 env 中设置了该选项，则将使用该文件。
./etc/npmrc全局配置：如果找到相对于全局前缀的文件，则会对其进行解析。npm prefix有关全局前缀的更多信息，请参阅。如果globalconfig在 cli、env 或用户配置中设置了该选项，那么将解析该文件。
默认值：npm 的默认配置选项在 lib/utils/config-defs.js 中定义。这些选项不得更改。

查看npm config的存储目录

要查看 npm 配置文件的存储目录，可以使用以下命令：

1. 查看 npm 默认配置文件的路径

arduino 复制代码

npm config list -l

输出结果中会显示 userconfig 和 globalconfig 的路径。
- userconfig：当前用户的 npm 配置文件（.npmrc）路径。
- globalconfig：全局 npm 配置文件的路径。

2. 查看用户级别的 npm 配置文件路径

arduino 复制代码

npm config get userconfig

默认路径：
- Linux/macOS ：~/.npmrc
- Windows ：C:\Users<YourUsername>.npmrc

3. 查看全局 npm 配置文件路径

arduino 复制代码

npm config get globalconfig

默认路径：
- Linux/macOS ：/usr/local/etc/npmrc
- Windows ：C:\Program Files\nodejs\etc\npmrc

4. 查看项目级别的 `.npmrc` 文件

项目级别的 .npmrc 文件位于项目根目录下，直接查看即可：

bash 复制代码

ls .npmrc

或：

bash 复制代码

cat .npmrc

总结

npm 的配置文件分为三个级别：

用户级别 ：~/.npmrc。
全局级别 ：/usr/local/etc/npmrc 或 C:\Program Files\nodejs\etc\npmrc。
项目级别 ：项目根目录下的 .npmrc。

通过 npm config get userconfig 和 npm config get globalconfig 可以快速找到对应的配置文件路径。

配置的优先级

在 npm 的配置文件中，不同级别的配置有明确的优先级顺序。优先级从高到低依次是：

1. 命令行参数

优先级最高。

示例：

ini 复制代码

npm install --registry=https://registry.npmmirror.com

说明：直接在命令行中指定的参数会覆盖其他配置。

2. 环境变量

优先于文件配置。

示例：

arduino 复制代码

export npm_config_registry=https://registry.npmmirror.com
npm install

说明：以 npm_config_ 开头的环境变量会被 npm 读取。

3. 项目级别的 `.npmrc` 文件

优先级高于用户和全局配置。
路径：项目根目录下的 .npmrc。
示例：
ini 复制代码
```
registry=https://registry.npmmirror.com
```
说明：项目级别的配置仅对当前项目生效。

4. 用户级别的 `.npmrc` 文件

路径：
- Linux/macOS：~/.npmrc
- Windows：C:\Users<YourUsername>.npmrc
示例：
ini 复制代码
```
registry=https://registry.npmmirror.com
```
说明：用户级别的配置对当前用户的所有项目生效。

5. 全局级别的 `npmrc` 文件

优先级最低。
路径：
- Linux/macOS：/usr/local/etc/npmrc
- Windows：C:\Program Files\nodejs\etc\npmrc
示例：
ini 复制代码
```
registry=https://registry.npmjs.org/
```
说明：全局配置对所有用户和项目生效。

优先级总结

从高到低：

命令行参数（最高优先级）。
环境变量。
项目级别的 .npmrc 文件。
用户级别的 .npmrc 文件。
全局级别的 npmrc 文件（最低优先级）。

示例

假设有以下配置：

命令行：npm install --registry=https://registry.custom.com
环境变量：npm_config_registry=https://registry.env.com
项目级别：.npmrc 设置 registry=https://registry.project.com
用户级别：~/.npmrc 设置 registry=https://registry.user.com
全局级别：/usr/local/etc/npmrc 设置 registry=https://registry.global.com

最终生效的配置是命令行指定的 https://registry.custom.com。

注意事项

Sox By default, npm 会合并多个来源的配置，但优先级高的配置会覆盖优先级低的配置。

如果某个配置项未在命令行、环境变量或文件中设置，npm 会使用默认值。

win系统--设置环境变量

在 Windows 系统中，可以通过以下两种方式设置环境变量：

方法 1：通过图形化界面设置

打开环境变量设置窗口：
- 按 Win + R，输入 sysdm.cpl，然后按回车。
- 在打开的"系统属性"窗口中，点击"高级"选项卡。
- 点击下方的"环境变量"按钮。
添加或修改环境变量：
- 在"用户变量"或"系统变量"部分，点击"新建"来添加变量。
  - 变量名 ：例如 npm_config_registry
  - 变量值 ：例如 https://registry.npmmirror.com
- 如果变量已存在，选中后点击"编辑"即可修改。
保存并生效：
- 点击"确定"保存设置。
- 重启命令行工具（如 CMD、PowerShell 或终端）使环境变量生效。

方法 2：通过命令行设置

临时设置（仅对当前会话生效）

打开命令行工具（CMD 或 PowerShell）。

使用以下命令临时设置环境变量：

CMD：

arduino 复制代码

set npm_config_registry=https://registry.npmmirror.com

PowerShell：

ini 复制代码

$env:npm_config_registry = "https://registry.npmmirror.com"

永久设置

打开命令行工具（以管理员身份运行 CMD 或 PowerShell）。

使用以下命令永久设置环境变量：

CMD：

arduino 复制代码

setx npm_config_registry "https://registry.npmmirror.com"

PowerShell：

css 复制代码

[System.Environment]::SetEnvironmentVariable('npm_config_registry', 'https://registry.npmmirror.com', [System.EnvironmentVariableTarget]::User)

重启命令行工具使其生效。

验证环境变量

使用以下命令查看环境变量是否设置成功：
- CMD：
  bash 复制代码
```
echo %npm_config_registry%
```
- PowerShell：
  bash 复制代码
```
echo $env:npm_config_registry
```

总结

临时设置 ：使用 set（CMD）或 $env:（PowerShell）。
永久设置 ：使用 setx（CMD）或 [System.Environment]::SetEnvironmentVariable（PowerShell）。
验证设置 ：通过 echo 命令查看环境变量的值。

一般命令

bin

查看可执行文件的存放路径

arduino 复制代码

npm bin // 查看当前项目中，可执行文件的存放路径

npm bin -g // 查看全局，可执行文件的存放路径

bugs

在浏览器打开，package.json中bugs配置的那个url。

用于反馈bug

cache

npm cache 是 npm 提供的用于管理本地缓存机制的命令。npm 会将下载的包存储在本地缓存中，以避免重复下载，加快后续安装速度。

以下是 npm cache 的常见使用场景及其示例命令：

1. 查看缓存目录

arduino 复制代码

npm config get cache

用途：查看 npm 默认的缓存目录路径（通常为 ~/.npm）。

2. 清理缓存

css 复制代码

npm cache clean --force

用途：强制清理本地缓存。
场景：
- 缓存损坏或出现问题。
- 缓存占用过多磁盘空间。
- 需要重新下载所有依赖包。

3. 验证缓存完整性

npm cache verify

输出结果示例：

bash 复制代码

Cache verified and compressed (~/.npm): 
Verified 1204 tarballs

用途：检查缓存的文件是否完整和有效。
场景：
- 怀疑缓存中的包损坏或存在问题。
- 在安装依赖时出现奇怪的错误。

4. 查看缓存信息

bash 复制代码

npm cache ls

用途：列出缓存中的所有文件。
场景：
- 查看缓存中的具体包文件。
- 需要手动删除某个特定的缓存文件。

5. 设置缓存目录

arduino 复制代码

npm config set cache /path/to/cache-dir

用途：自定义 npm 的缓存目录。
场景：
- 默认缓存目录空间不足，需要将缓存存储到其他位置。

6. 查看缓存统计信息

bash 复制代码

npm cache ls --json

用途：以 JSON 格式查看缓存的详细信息。
场景：
- 需要分析缓存的内容或大小。

总结

npm cache 的主要用途是管理本地缓存机制，常见的场景包括：

清理缓存以解决安装问题或释放磁盘空间。
验证缓存文件的完整性。
查看缓存内容或统计信息。
自定义缓存目录的位置。

合理使用 npm cache 可以帮助解决依赖安装问题，并优化 npm 的性能。

npm ci 是 npm 提供的一个命令，专门用于在项目中安装依赖。相比于传统的 npm install，npm ci 更适用于 CI/CD（持续集成/持续交付） 环境或其他需要 确定性安装 的场景。以下是对 npm ci 的详细解析：

ci

`npm ci` 的作用

基于 package-lock.json 安装依赖：
- npm ci 会严格按照 package-lock.json 文件中的版本安装依赖，确保每次安装的依赖版本完全一致。
- 如果 package-lock.json 不存在或与 package.json 冲突，npm ci 会报错并退出。
删除 node_modules 并重新安装：
- npm ci 会先删除现有的 node_modules 文件夹，然后从头开始安装依赖，确保安装环境干净。
更快且更轻量：
- 由于 npm ci 不会修改 package-lock.json 或 package.json，因此在安装过程中不需要执行额外的计算，速度通常比 npm install 更快。
不安装开发依赖（可选） ：
- 可以通过 --only=production 参数，仅安装生产依赖，忽略开发依赖。

`npm ci` 的使用场景

CI/CD 环境：
- 在持续集成/持续交付中，确保每次构建时安装的依赖版本完全相同，避免因依赖版本不一致导致的构建失败。
确定性安装：
- 当需要确保依赖版本与 package-lock.json 完全一致时，使用 npm ci。
快速重置依赖：
- 当 node_modules 文件夹中的依赖可能被修改或损坏时，可以使用 npm ci 快速重置依赖。

`npm ci` 的命令格式

npm ci

可选参数：

--only=production：仅安装生产依赖。
--no-audit：跳过安全审计（npm audit）。
--ignore-scripts：忽略 package.json 中的 preinstall、postinstall 等脚本。
--no-package-lock：忽略 package-lock.json（不推荐使用）。

`npm ci` 与 `npm install` 的区别

特性	`npm ci`	`npm install`
依赖来源	严格基于 `package-lock.json`	优先基于 `package.json`
`node_modules` 处理	删除并重新安装	保留现有依赖，按需更新
`package-lock.json`	不会修改	可能会更新
速度	更快	较慢
适用场景	CI/CD、确定性安装	日常开发

示例

1. 在 CI/CD 环境中使用 `npm ci`

npm ci

2. 仅安装生产依赖

ini 复制代码

npm ci --only=production

3. 跳过安全审计

css 复制代码

npm ci --no-audit

注意事项

package-lock.json 必须存在：
- 如果项目中没有 package-lock.json 文件，npm ci 会报错。可以使用 npm install 生成 package-lock.json。
package-lock.json 必须与 package.json 一致：
- 如果 package-lock.json 与 package.json 存在冲突，npm ci 会报错。可以使用 npm install 更新 package-lock.json。
不会修改项目文件：
- npm ci 不会修改 package.json 或 package-lock.json，因此如果需要更新依赖版本，仍需使用 npm install。

总结

npm ci 是一个非常适合在 CI/CD 环境中使用的命令，能够确保依赖安装的确定性和一致性。
对于日常开发，npm install 更加灵活，能够根据 package.json 更新依赖版本。
如果你的项目需要严格的依赖版本控制，推荐在 CI/CD 中使用 npm ci。

dedupe

npm install 在安装依赖时，会自动尝试优化依赖树，尽可能减少重复的依赖包。因此，通常情况下不需要手动运行 npm dedupe。但如果 node_modules 中已经存在大量重复的依赖包，可以运行 npm dedupe 进一步优化。

npm dedupe 是 npm 提供的一个命令，用于 减少重复的依赖包 ，通过尽可能多地共享相同版本的依赖包来优化 node_modules 目录的结构。以下是对 npm dedupe 的详细解析：

1. 作用

当项目中安装的依赖包之间存在 版本冲突 时，npm 会为不同的依赖包安装各自的副本，导致 node_modules 目录中出现多个相同依赖包的重复版本。npm dedupe 的作用是 尽可能共享相同版本的依赖包 ，从而减少重复文件并优化 node_modules 结构。

2. 使用场景

项目依赖树复杂，导致 node_modules 中存在大量重复的依赖包。
希望优化 node_modules 的大小和结构。
安装依赖后，发现某些依赖包的多版本冲突问题。

3. 基本语法

npm dedupe

或

npm ddp

4. 工作原理

查找依赖冲突 ：npm dedupe 会遍历 node_modules 目录，查找是否存在多个版本相同的依赖包。
共享相同版本：对于相同版本的依赖包，尝试将其移动到更高的依赖层级，使其可以被多个依赖共享。
优化结构 ：移除重复的依赖包，优化 node_modules 的目录结构。

5. 举个例子

假设项目结构如下：

kotlin 复制代码

project
├── package.json
└── node_modules
    ├── A
    │   └── node_modules
    │       └── C@1.0.0
    ├── B
    │   └── node_modules
    │       └── C@1.0.0
    └── C@1.0.0

运行 npm dedupe 后，node_modules 结构会被优化为：

css 复制代码

project
├── package.json
└── node_modules
    ├── A
    ├── B
    └── C@1.0.0

C@1.0.0 被移动到顶层，供 A 和 B 共享，从而减少重复的依赖包。

6. 注意事项

版本兼容性问题 ：npm dedupe 只会共享 完全相同版本 的依赖包。如果依赖包版本不完全相同（例如 C@1.0.0 和 C@1.1.0），则无法共享。
Flat 模式 ：在 npm 3+ 中，npm 默认使用 扁平化结构 （flat 模式），已经尽可能地减少了重复依赖包的数量。因此 npm dedupe 的作用在 npm 3+ 中相对有限。
Lock 文件 ：如果项目中存在 package-lock.json 或 npm-shrinkwrap.json，npm dedupe 会根据这些文件中的锁定版本进行优化。

7. 与 `npm install` 的关系

npm install 在安装依赖时，会自动尝试优化依赖树，尽可能减少重复的依赖包。因此，通常情况下不需要手动运行 npm dedupe。但如果 node_modules 中已经存在大量重复的依赖包，可以运行 npm dedupe 进一步优化。

8. 与 `npm prune` 的区别

npm dedupe：优化依赖包的结构，减少重复的依赖包。
npm prune ：移除 package.json 中未声明的依赖包，清理 node_modules。

9. 总结

npm dedupe 是一个用于优化 node_modules 结构的命令，通过共享相同版本的依赖包来减少重复文件。在 npm 3+ 中，由于默认使用扁平化结构，npm dedupe 的作用已经相对有限。但在复杂项目中，仍然可以通过运行 npm dedupe 进一步优化依赖树。

prune

npm prune 是 npm 提供的一个命令，用于删除项目中未使用的包 。它会移除 node_modules 目录中存在但在 package.json 文件的依赖列表中未声明的包。这对于清理项目依赖非常有用，可以帮助减少项目的体积并保持依赖的整洁。

基本用法

npm prune

作用：

删除 node_modules 目录中未在 package.json 文件中声明的包。

详细解析

1. 默认行为

默认情况下，npm prune 会：

读取 package.json 文件的 dependencies 和 devDependencies。
检查 node_modules 目录中的包是否在 package.json 中被声明。
删除未声明的包。

2. 支持的选项

选项	说明
`--production`	删除未在 `dependencies` 中声明的包（忽略 `devDependencies`）。
`--json`	以 JSON 格式输出删除的包列表。
`--dry-run`	模拟执行，展示哪些包会被删除，但不会实际删除。
`--no-save`	不要更新 `package-lock.json` 文件。

3. 与 `npm install` 的关系

npm install 会自动执行 npm prune 的行为，因此在安装依赖时，未声明的包通常会被自动移除。

使用场景

1. 清理未使用的包

从 node_modules 中移除未在 package.json 中声明的包。

npm prune

2. 仅删除生产环境的未使用包

移除未在 dependencies 中声明的包（忽略 devDependencies）。

css 复制代码

npm prune --production

3. 查看哪些包会被删除

模拟执行，展示哪些包会被删除。

arduino 复制代码

npm prune --dry-run

4. 以 JSON 格式输出删除的包

删除未使用的包，并以 JSON 格式输出结果。

css 复制代码

npm prune --json

常见问题

1. `npm prune` 会删除全局包吗？

不会，npm prune 只影响当前项目的 node_modules 目录。

2. `npm prune` 会更新 `package-lock.json` 吗？

默认情况下，npm prune 会更新 package-lock.json 文件。如果不希望更新，可以使用 --no-save 选项。

3. `npm prune` 和 `npm uninstall` 的区别

npm prune 是批量删除未声明的包。
npm uninstall 用于删除指定的包。

4. 为什么 `npm prune` 没有删除某些包？

某些包可能是其他包的依赖，npm prune 会保留这些被间接依赖的包。

总结

npm prune 是一个非常有用的命令，它的核心功能包括：

清理 node_modules 中未在 package.json 中声明的包。
支持生产环境的包清理。
提供模拟执行和 JSON 输出功能。

prune 和 dedupe的区别

npm prune 和 npm dedupe 是 npm 提供的两个不同的命令，它们的作用和功能完全不同。以下是它们的详细区别：

`npm prune`

作用

删除 node_modules 目录中未在 package.json 文件中声明的包。

使用场景

当你手动删除了 package.json 中的某些依赖，或者你通过其他方式安装了未在 package.json 中声明的包时，可以使用 npm prune 清理这些未使用的包。

命令示例

npm prune

特点

删除未声明的包，减少 node_modules 的体积。
支持 --production 选项，仅删除未在 dependencies 中声明的包（忽略 devDependencies）。
默认会更新 package-lock.json。

`npm dedupe`

作用

优化 node_modules 目录中的依赖树，将重复安装的包移动到更高的层级，以减少磁盘空间占用和提升安装效率。

使用场景

当你的项目中有多个包依赖了同一个包，但版本不同，导致这个包被多次安装时，可以使用 npm dedupe 来减少重复。

命令示例

npm dedupe

特点

减少重复的依赖，优化 node_modules 的结构。
不会删除任何包，只是重新组织依赖树。
适用于提升性能和管理复杂的依赖关系。

主要区别

特性	`npm prune`	`npm dedupe`
目的	删除未在 `package.json` 中声明的包	减少重复的依赖，优化依赖树
对 `node_modules` 的影响	删除包	重新组织包的位置
是否删除包	是	否
与 `package.json` 的关系	基于 `package.json` 检查包是否声明	基于现有的 `node_modules` 结构优化
常用选项	`--production`、`--dry-run`	无特定选项

使用场景对比

`npm prune` 的使用场景

清理未使用的包，减少项目体积。
删除不再需要的开发依赖。
在团队协作中，确保 node_modules 与 package.json 一致。

`npm dedupe` 的使用场景

减少重复依赖，节省磁盘空间。
优化复杂的依赖树，提升安装和运行性能。
在安装了大量包后，优化 node_modules 结构。

综合建议

如果你需要清理未使用的包，使用 npm prune。
如果你发现 node_modules 中有大量重复的包，使用 npm dedupe。
在实际开发中，可以结合 npm prune 和 npm dedupe 来保持 node_modules 的整洁和高效。

dist-tag

作用：给版本指定别名

npm dist-tag 是 npm 提供的一个命令，用于管理发布到 npm 仓库的包的 分发标签（distribution tags） 。分发标签是一种别名机制，用于标记包的不同版本，方便用户在安装时指定特定标签对应的版本。以下是对 npm dist-tag 的详细解析：

1. 什么是分发标签？

分发标签（dist-tag）是 npm 包版本的一个别名，用于标记某个特定的版本。默认情况下，npm 会为每个包提供一个 latest 标签，指向最新发布的稳定版本。开发者可以自定义标签来标记特定的版本，例如 beta、next、stable 等。

2. 分发标签的作用

标记特定版本：通过标签可以方便地标记测试版、预览版或稳定版。
简化安装：用户可以通过标签安装指定的版本，而无需记住具体的版本号。
灵活发布 ：可以在不更新 latest 标签的情况下发布新版本，便于分阶段发布。

3. 基本语法

xml 复制代码

npm dist-tag <命令> <包名>[@<版本>] [<标签>]

4. 常用命令

（1）查看包的标签

bash 复制代码

npm dist-tag ls <包名>

例如：

arduino 复制代码

npm dist-tag ls lodash // 在任意位置查看 lodash

npm dist-tag ls // 查看当前项目的tags

输出示例：

makefile 复制代码

latest: 4.17.21
beta: 4.17.20

（2）添加/更新标签

xml 复制代码

npm dist-tag add <包名>@<版本> <标签>

例如：

sql 复制代码

npm dist-tag add lodash@4.17.20 beta

将 4.17.20 版本标记为 beta 标签。

（3）删除标签

xml 复制代码

npm dist-tag rm <包名> <标签>

例如：

bash 复制代码

npm dist-tag rm lodash beta

删除 lodash 包的 beta 标签。

5. 默认标签

latest：默认标签，指向最新发布的稳定版本。
xml 复制代码
```
npm install <包名>
```
相当于：
css 复制代码
```
npm install <包名>@latest
```

6. 使用标签安装包

在安装包时，可以通过标签指定安装的版本。例如：

xml 复制代码

npm install <包名>@<标签>

例如：

css 复制代码

npm install lodash@beta

会安装 lodash 中标记为 beta 标签的版本。

7. 分发标签的使用场景

测试版本发布 ：发布测试版时，可以将其标记为 beta 或 next 标签，而不是更新 latest 标签。
css 复制代码
```
npm publish --tag beta
```
多版本管理 ：同时维护多个版本的包，例如 stable 和 beta。
分阶段发布：在正式发布前，可以先发布一个带标签的版本，供特定用户测试。

8. 修改默认标签

发布包时，可以通过 --tag 参数指定标签。例如：

css 复制代码

npm publish --tag beta

这会将当前版本发布为 beta 标签，而不会影响 latest 标签。

9. 注意事项

每个标签只能指向一个版本。
latest 是默认标签，不能删除，但可以修改其指向的版本。
分发标签不会影响 package.json 中的版本号，只是提供一个别名机制。

10. 示例

（1）发布一个测试版本并标记为 `beta`

css 复制代码

npm publish --tag beta

（2）查看包的标签

perl 复制代码

npm dist-tag ls my-package

输出：

makefile 复制代码

latest: 1.0.0
beta: 1.1.0-beta

（3）将 `1.1.0-beta` 标记为 `latest`

perl 复制代码

npm dist-tag add my-package@1.1.0-beta latest

（4）删除 `beta` 标签

perl 复制代码

npm dist-tag rm my-package beta

11. 总结

npm dist-tag 是一个强大的工具，用于管理 npm 包的分发标签。通过分发标签，可以灵活地标记和管理包的版本，方便用户安装和测试特定版本的包。常见的使用场景包括发布测试版本、维护多个版本和分阶段发布。

docs

查看包的文档

xml 复制代码

npm docs [<pkgname> [<pkgname> ...]]

调用浏览器打开 package.json 中的homepage字段指定的url

edit

npm edit 是 npm 提供的一个命令行工具，用于快速打开当前项目中某个包的源代码进行编辑。它可以帮助开发者在本地调试或修改依赖包的代码，而无需手动查找包的安装路径。以下是对 npm edit 的详细解析：

1. 功能概述

npm edit 允许开发者打开并编辑已安装的依赖包的源代码。它会根据系统的默认编辑器打开包的根目录，方便开发者直接修改代码。

2. 使用方法

在终端中运行以下命令：

go 复制代码

npm edit <package-name>

<package-name> ：要编辑的包的名称。

示例

npm edit lodash

输出示例

bash 复制代码

# 这会在默认编辑器中打开 lodash 包的根目录

3. 工作原理

npm edit 的工作原理如下：

通过 npm ls 查找指定包的安装路径。
使用系统的默认编辑器打开该包的根目录。
开发者可以直接编辑包的源代码。

默认编辑器由系统的 EDITOR 环境变量决定。如果未设置 EDITOR，则会使用系统默认的文本编辑器。

4. 设置默认编辑器

如果你希望指定 npm edit 使用的编辑器，可以通过设置 EDITOR 环境变量。

（1）临时设置

在终端中运行以下命令：

ini 复制代码

export EDITOR="<your-editor-command>"

（2）永久设置

将以下内容添加到你的 Shell 配置文件（如 ~/.bashrc 或 ~/.zshrc）：

ini 复制代码

export EDITOR="<your-editor-command>"

示例

使用 VSCode 作为默认编辑器：
ini 复制代码
```
export EDITOR="code"
```
使用 Vim 作为默认编辑器：
ini 复制代码
```
export EDITOR="vim"
```

5. 使用示例

示例 1：编辑 lodash 包

npm edit lodash

这会在默认编辑器中打开 lodash 包的根目录。

示例 2：编辑项目根目录

如果你没有指定包名，npm edit 会打开当前项目的根目录：

npm edit

6. 注意事项

（1）全局包

npm edit 默认编辑项目中安装的包。如果要编辑全局安装的包，需要添加 -g 选项：

go 复制代码

npm edit -g <package-name>

（2）编辑后的效果

npm edit 只是打开包的源代码进行编辑，不会自动保存或应用到项目中。如果需要测试修改后的代码，可以在包的目录中运行 npm link 将其链接到项目中。

（3）重新安装包

如果重新安装包（例如运行 npm install），编辑的内容会被覆盖。如果需要永久修改某个包，建议将其 fork 到自己的仓库，并在项目中使用 fork 后的版本。

7. 常见问题

（1）找不到包

如果运行 npm edit 后提示找不到包，可能是因为：

包未正确安装。
包名拼写错误。
包未作为依赖项安装在当前项目中。

（2）编辑器未打开

如果编辑器未打开，可能是由于未正确设置 EDITOR 环境变量。可以通过以下命令检查：

bash 复制代码

echo $EDITOR

如果没有输出，请参考前面的步骤设置默认编辑器。

8. 总结

npm edit 是一个方便的工具，适合以下场景：

需要调试或修改某个依赖包的代码。
快速查看依赖包的源码结构。
临时修改包的行为以测试效果。

使用方法非常简单，只需运行 npm edit <package-name> 即可打开指定包的源代码。如果需要长期修改某个包，建议 fork 并发布自己的版本。

explore

npm explore 是 npm 提供的一个命令，用于在本地安装的包目录中打开一个交互式 shell ，以便你可以手动检查和操作该包的内部文件。它类似于 cd 到包的目录并执行命令，但更加方便和灵活。

`npm explore` 的基本用法

lua 复制代码

npm explore <package-name> [-- <command>]

<package-name>：你需要探索的包的名称。
[-- <command>]：可选参数，指定要在包的目录中执行的命令。如果不提供命令，会打开一个交互式 shell。

`npm explore` 的功能

进入包的目录 直接进入指定包的安装目录，方便查看或修改包的内容。
在包目录中执行命令 可以在包的目录中执行任何命令，而无需手动导航到该目录。
快速调试包内容 进入包的目录后，可以查看包的文件结构、运行测试或修改代码。

示例

1. 进入 `lodash` 包的目录

npm explore lodash

这会打开一个交互式 shell，提示符会显示你在 lodash 包的目录中：

ruby 复制代码

Exploring: /path/to/project/node_modules/lodash
Type 'exit' or ^D when done

此时，你可以手动执行命令，例如 ls 查看文件列表或 cat index.js 查看文件内容。

2. 在 `lodash` 包的目录中执行命令

如果你只想执行一个命令，而无需进入交互式 shell，可以这样做：

bash 复制代码

npm explore lodash -- ls

这会列出 lodash 包目录中的文件和文件夹。

3. 在包目录中运行测试

假设你在包的目录中，可以运行测试脚本：

bash 复制代码

npm explore lodash -- npm test

这会执行 lodash 包中的 test 脚本。

常见场景

手动探索包内容 如果你对某个包的文件结构感兴趣，可以使用 npm explore 进入包的目录并查看文件。
调试包的代码 如果你需要调试某个包的代码，可以使用 npm explore 进入包的目录并修改文件。
执行包中的脚本 如果你想运行包中的脚本（如测试或构建脚本），可以使用 npm explore 来执行。
快速修改包的配置 如果你需要临时修改包的配置文件（如 .npmrc 或 package.json），可以使用 npm explore 快速进入包的目录。

总结

npm explore 是一个非常有用的工具，适合在以下场景中使用：

探索包的文件结构。
调试或修改包的代码。
在包的目录中执行命令。
快速查看或修改包的配置文件。

find-dupes

npm find-dupes 是 npm 提供的一个命令，用于查找项目中重复安装的包 。在某些情况下，由于依赖关系的复杂性，可能会出现同一个包在项目中被安装了多个版本的情况。npm find-dupes 可以帮助你快速发现这些问题。

`npm find-dupes` 的基本用法

arduino 复制代码

npm find-dupes

运行此命令后，npm 会扫描 node_modules 目录，并列出所有重复安装的包及其版本信息。

`npm find-dupes` 的功能

检测重复包 它会检测项目中是否存在同一个包被安装了多个版本的情况。
提供详细信息 它会列出重复包的名称、版本号以及安装路径。
帮助优化依赖关系 通过发现重复包，你可以优化项目的依赖关系，减少 node_modules 的大小。

示例

假设你的项目中有两个版本的 lodash，运行以下命令：

arduino 复制代码

npm find-dupes

可能的输出如下：

javascript 复制代码

lodash
  * 4.17.21
    -> /path/to/project/node_modules/lodash
  * 3.10.1
    -> /path/to/project/node_modules/some-package/node_modules/lodash

解释：

lodash 包被安装了多个版本：4.17.21 和 3.10.1。
4.17.21 是直接安装在项目根目录的 node_modules 中的。
3.10.1 是被 some-package 依赖并安装在 some-package 的 node_modules 中的。

解决重复包问题

如果你发现存在重复包，可以采取以下措施来解决问题：

更新依赖版本 尝试将所有依赖更新到兼容的版本，以减少依赖冲突。
使用 npm dedupe 运行 npm dedupe 命令，npm 会尝试自动移除重复的包，并优化依赖树。
手动调整 package.json 如果某些包明确需要特定版本，可以在 package.json 中手动指定版本范围。

注意事项

重复包不一定是问题 在某些情况下，重复包是必要的，因为不同的依赖可能需要不同版本的包。
node_modules 的结构 默认情况下，npm 会将依赖安装在各自的 node_modules 中，这可能会导致重复包的安装。
使用 npm install 的 --legacy-peer-deps 或 --strict-peer-deps 如果项目中有 peerDependencies 冲突，可以尝试使用这些选项来调整安装行为。

总结

npm find-dupes 是一个非常有用的工具，用于：

检测项目中重复安装的包。
帮助优化依赖关系，减少 node_modules 的大小。
发现潜在的依赖冲突问题。

hook

npm hook 是 npm 提供的一个命令，用于管理包的生命周期钩子（hooks） 。这些钩子允许你在特定事件（例如包发布时）触发外部服务或脚本。通过 npm hook，你可以自动通知外部服务或执行某些操作，从而更好地集成和自动化你的工作流程。

`npm hook` 的基本用法

bash 复制代码

npm hook <command> [options]

npm hook 支持以下子命令：

add：添加一个新的钩子。
ls：列出所有已配置的钩子。
rm：删除一个已存在的钩子。
update：更新一个已存在的钩子。

详细命令说明

1. 添加一个新的钩子：`npm hook add`

xml 复制代码

npm hook add <event> <url> [--secret=<value>]

<event> ：触发钩子的事件。例如：
- package：在包发布时触发。
- owner：在包的所有者发生变化时触发。
- dist-tag：在包的 dist-tag 更新时触发。
- scope：在特定范围内发生事件时触发。
<url> ：事件触发时将请求发送到的 URL。
--secret=<value> （可选）：用于验证请求的密钥。

示例：

perl 复制代码

npm hook add package https://example.com/webhook --secret=my-secret

2. 列出所有钩子：`npm hook ls`

bash 复制代码

npm hook ls

运行此命令会列出所有已配置的钩子，包括它们的 ID、事件、URL 和状态。

示例输出：

json 复制代码

{
  "id": "hook-12345",
  "event": "package",
  "url": "https://example.com/webhook",
  "secret": "my-secret",
  "active": true
}

3. 删除一个钩子：`npm hook rm`

bash 复制代码

npm hook rm <hook-id>

<hook-id> ：要删除的钩子的 ID。可以通过 npm hook ls 查看钩子的 ID。

示例：

bash 复制代码

npm hook rm hook-12345

4. 更新一个钩子：`npm hook update`

xml 复制代码

npm hook update <hook-id> <event> <url> [--secret=<value>]

<hook-id> ：要更新的钩子的 ID。
<event> ：更新后的触发事件。
<url> ：更新后的 URL。
--secret=<value> （可选）：更新后的密钥。

示例：

sql 复制代码

npm hook update hook-12345 package https://new-url.com/webhook --secret=new-secret

`npm hook` 的常见用途

自动化通知 在包发布时自动通知团队或外部服务（例如发送消息到 Slack 或 Discord）。
触发 CI/CD 流程 当包更新时自动触发构建或部署流程。
记录发布日志 将包的发布信息记录到外部系统或数据库中。

注意事项

保护钩子 URL 钩子的 URL 可能会被滥用，建议使用 --secret 来验证请求的来源。
事件类型 确保选择正确的事件类型（如 package、owner 等），以防止不必要的触发。
钩子性能 钩子的执行可能会影响 npm 服务器的性能，因此请确保钩子的回调逻辑尽可能高效。

总结

npm hook 是一个非常强大的工具，用于管理包的生命周期钩子，实现自动化通知、集成和流程触发。通过合理使用钩子，你可以提升开发和发布流程的效率。

test

npm test 是 npm 提供的一个命令，用于运行项目的测试脚本 。它会在项目的 package.json 文件中查找 "test" 脚本并执行。这是开发过程中常用的命令，用于确保代码的质量和功能的正确性。

`npm test` 的基本用法

bash 复制代码

npm test

npm install-test // npm i + npm test
npm install-ci-test // npm ci + npm test

或简写为：

npm t

如何配置测试脚本

在 package.json 文件中定义 "test" 脚本，例如：

json 复制代码

{
  "scripts": {
    "test": "jest"
  }
}

在上面的例子中，npm test 会运行 jest 来执行测试。

你也可以使用其他测试工具（如 Mocha、Ava 等），只需将 "test" 脚本替换为对应的命令即可。例如：

json 复制代码

{
  "scripts": {
    "test": "mocha"
  }
}

常见测试工具

以下是一些流行的测试工具及其用法：

Jest
json 复制代码
```
{
  "scripts": {
    "test": "jest"
  }
}
```
Jest 是一个功能强大、开箱即用的 JavaScript 测试框架。
Mocha
json 复制代码
```
{
  "scripts": {
    "test": "mocha"
  }
}
```
Mocha 是一个灵活的测试框架，通常与断言库（如 chai）一起使用。
Ava
json 复制代码
```
{
  "scripts": {
    "test": "ava"
  }
}
```
Ava 是一个轻量级的测试框架，强调并发执行测试。
Cypress（用于端到端测试）
json 复制代码
```
{
  "scripts": {
    "test": "cypress run"
  }
}
```
Cypress 是一个现代的前端端到端测试工具。

`npm test` 的高级用法

运行特定测试文件 如果你只想运行某个特定的测试文件，可以传递文件路径作为参数：
bash 复制代码
```
npm test path/to/test-file.js
```
监视模式 许多测试工具支持监视模式（--watch），当文件发生变化时自动重新运行测试。例如：
json 复制代码
```
{
  "scripts": {
    "test": "jest --watch"
  }
}
```
生成测试覆盖率报告 许多测试工具支持生成覆盖率报告。例如，使用 Jest：
json 复制代码
```
{
  "scripts": {
    "test": "jest --coverage"
  }
}
```
并行运行测试 某些测试工具（如 Jest 和 Ava）支持并行运行测试，以提高执行速度。具体配置请参考工具的文档。

常见问题

npm test 没有反应
- 检查 package.json 中是否定义了 "test" 脚本。
- 确保测试工具已正确安装。
测试失败
- 检查测试代码和逻辑是否正确。
- 确保依赖项已安装且版本兼容。
如何跳过测试 如果你希望跳过测试，可以使用 --ignore-scripts 选项：
css 复制代码
```
npm install --ignore-scripts
```

总结

npm test 是一个非常实用的命令，用于运行项目中的测试脚本。通过配置不同的测试工具（如 Jest、Mocha、Cypress 等），可以满足不同场景下的测试需求。

ls

npm ls 是 npm 提供的一个命令，用于列出当前项目的依赖树。它会显示项目中安装的所有依赖项及其版本信息，并按照树状结构展示它们之间的依赖关系。这对于理解项目的依赖结构、排查依赖冲突或检查依赖版本非常有用。

`npm ls` 的基本用法

bash 复制代码

npm ls

默认情况下，npm ls 会列出项目的所有依赖（包括直接依赖和嵌套依赖）。

常用选项

选项	说明
`--depth`	控制依赖树的深度。例如，`npm ls --depth=0` 只显示项目的直接依赖。
`--prod`	只列出生产环境的依赖（即 `dependencies` 部分）。
`--dev`	只列出开发环境的依赖（即 `devDependencies` 部分）。
`--json`	以 JSON 格式输出依赖树。
`--long`	显示每个包的详细描述信息。
`--global`	列出全局安装的包（需要结合 `-g` 使用）。
`--all`	查看所有包，显示所有层级
`--link`	显示已链接的本地依赖包（如 `npm link` 创建的包）。npm ls --link -g 查看全局link的包

示例

列出所有依赖

bash 复制代码

npm ls

输出示例：

sql 复制代码

my-project@1.0.0
├─┬ express@4.18.2
│ ├── accepts@1.3.8
│ ├── array-flatten@1.1.1
│ └── body-parser@1.20.1
└─┬ jest@29.7.0
  ├─┬ @jest/core@29.7.0
  │ └─┬ @jest/reporters@29.7.0
  │   └─┬ @jest/test-result@29.7.0
  │     └── @jest/types@29.7.0
  └── jest-cli@29.7.0

只列出直接依赖

ini 复制代码

npm ls --depth=0

输出示例：

perl 复制代码

my-project@1.0.0
├── express@4.18.2
└── jest@29.7.0

只列出生产环境的依赖
bash 复制代码
```
npm ls --prod
```
只列出开发环境的依赖
bash 复制代码
```
npm ls --dev
```

以 JSON 格式输出

bash 复制代码

npm ls --json

输出示例：

json 复制代码

{
  "name": "my-project",
  "version": "1.0.0",
  "dependencies": {
    "express": {
      "version": "4.18.2",
      "dependencies": {
        "accepts": {
          "version": "1.3.8"
        },
        "array-flatten": {
          "version": "1.1.1"
        }
      }
    }
  }
}

高级用法

1. 列出特定包的依赖关系

你可以指定一个包名，查看它的依赖关系。

bash 复制代码

npm ls express

2. 结合 `grep` 过滤输出

可以使用 grep 过滤输出内容。例如，查找所有包含 react 的包：

bash 复制代码

npm ls | grep react

3. 全局安装的包

查看全局安装的包及其依赖关系：

bash 复制代码

npm ls -g

4. 检查依赖冲突

npm ls 会显示依赖冲突的部分，帮助你排查问题。

常见输出信息解析

extraneous
- 表示安装了未在 package.json 中声明的包。
- 解决方法：运行 npm prune 移除多余的包。
missing
- 表示 package.json 中声明的依赖包未安装。
- 解决方法：运行 npm install 安装缺失的包。
deduped
- 表示重复的依赖包已被优化（通常通过 npm dedupe 命令实现）。
invalid
- 表示某个包的版本号无效或存在问题。

常见问题

npm ls 输出太长难以阅读
- 使用 --depth 选项限制依赖树的深度。
- 使用 --json 选项以 JSON 格式输出，便于程序化处理。
如何检查全局安装的包
ini 复制代码
```
npm ls -g --depth=0
```
如何解释树状结构中的符号？
- ├─：当前包的子依赖。
- └─：当前包的最后一个子依赖。

总结

npm ls 是一个非常实用的命令，用于查看项目的依赖关系。它可以帮助你：

理解项目的依赖结构。
排查依赖冲突或版本问题。
检查未安装或多余的包。

outdated

npm outdated 是 npm 提供的一个命令，用于检查项目中已安装的依赖包是否有更新的版本。它会列出所有过时的包及其当前版本、最新版本和需要的版本范围。这是维护项目依赖的重要工具，帮助你及时更新依赖，确保项目使用最新的、安全的包。

基本用法

npm outdated

作用：列出项目中所有过时的包，并显示以下信息：

Package：包名。
Current：当前安装的版本。
Wanted ：根据 package.json 中定义的版本范围，可以升级到的最大版本。
Latest：npm 仓库中的最新版本。
Location：包的安装位置（本地路径或全局路径）。

输出示例

bash 复制代码

Package  Current  Wanted  Latest  Location
express   4.17.1  4.18.2  5.0.0   my-project/node_modules/express
jest      27.5.1  28.0.0  29.0.0  my-project/node_modules/jest

express 当前的版本是 4.17.1，根据 package.json 的版本范围，可以升级到 4.18.2，而最新版本是 5.0.0。
jest 当前的版本是 27.5.1，根据 package.json 的版本范围，可以升级到 28.0.0，而最新版本是 29.0.0。

常用选项

选项	说明
`--json`	以 JSON 格式输出结果。
`--long`	显示详细信息，包括包的描述、仓库链接等。
`--global`	检查全局安装的包是否过时。
`--depth <n>`	限制依赖树的深度。例如，`npm outdated --depth=0` 只检查直接依赖。

详细解析

1. `--json` 选项

以 JSON 格式输出结果，便于程序化处理。

css 复制代码

npm outdated --json

输出示例：

json 复制代码

{
  "express": {
    "current": "4.17.1",
    "wanted": "4.18.2",
    "latest": "5.0.0",
    "location": "my-project/node_modules/express"
  },
  "jest": {
    "current": "27.5.1",
    "wanted": "28.0.0",
    "latest": "29.0.0",
    "location": "my-project/node_modules/jest"
  }
}

2. `--long` 选项

显示每个包的详细信息，包括描述、仓库链接等。

arduino 复制代码

npm outdated --long

3. `--global` 选项

检查全局安装的包是否过时。

csharp 复制代码

npm outdated --global

4. `--depth` 选项

限制依赖树的深度，只检查特定层级的依赖。

ini 复制代码

npm outdated --depth=0

`Wanted` 和 `Latest` 的区别

Wanted ：根据 package.json 中定义的版本范围，可以升级到的最大版本。例如：
- "express": "^4.17.1" 的 Wanted 版本是 4.18.2（因为 ^4.17.1 允许升级到 4.x.x）。
- "jest": "~27.5.1" 的 Wanted 版本是 27.5.2（因为 ~27.5.1 允许升级到 27.5.x）。
Latest ：npm 仓库中的最新版本，可能是一个大版本（如 5.0.0 或 29.0.0）。

更新过时的包

npm outdated 本身不会更新包，它只是列出过时的包。要更新这些包，可以使用以下命令：

更新所有过时的包 使用 npm update 更新所有符合 Wanted 版本的包：
sql 复制代码
```
npm update
```
更新到最新版本 如果需要更新到 Latest 版本（可能是一个大版本更新），可以手动修改 package.json 中的版本范围，然后运行：
```
npm install
```
更新特定包 使用 npm install <package>@latest 更新特定包到最新版本：
css 复制代码
```
npm install express@latest
```

常见问题

npm outdated 没有输出？ 表示当前项目中没有过时的包，所有依赖都是最新的。
如何忽略开发环境的依赖？ 使用 --prod 选项，只检查生产环境的依赖：
css 复制代码
```
npm outdated --prod
```
如何忽略特定包？ 在 package.json 中为该包指定精确的版本，避免 npm outdated 检测到更新。例如：
json 复制代码
```
"express": "4.17.1"
```
如何检查全局安装的包？ 使用 --global 选项：
csharp 复制代码
```
npm outdated --global
```

总结

npm outdated 是一个非常有用的命令，它的核心功能包括：

列出项目中过时的包。
显示当前版本、符合 package.json 版本范围的 Wanted 版本以及最新的 Latest 版本。
支持 JSON 格式输出、特定环境过滤、深度限制等功能。

通过定期运行 npm outdated，你可以及时发现并更新过时的依赖，确保项目的安全性和稳定性。

pack

npm pack 是 npm 提供的一个命令，用于将当前项目打包成一个 .tgz 文件。这个文件是一个压缩包，包含了项目的所有代码和依赖（根据你的配置，可能是生产依赖或所有依赖），通常用于分发项目或作为本地安装包。

基本用法

perl 复制代码

npm pack

作用：

将当前项目的代码打包成一个 .tgz 文件。
生成的文件名格式为 <package-name>-<version>.tgz。

示例：如果你的项目名为 my-project，版本为 1.0.0，运行 npm pack 后会生成一个文件 my-project-1.0.0.tgz。

常用选项

选项	说明
`--dry-run`	模拟打包过程，不实际生成文件。
`--pack-destination <dir>`	指定打包文件的输出目录。
`--workspace <name>`	在工作区模式下，指定要打包的工作区（需启用 `workspaces`）。

详细解析

1. 打包内容

npm pack 主要包括以下内容：

package.json 中定义的文件（通过 files 字段或 .npmignore 配置文件控制）。
项目代码。
项目的依赖（默认只包括生产依赖，除非指定 --include-workspace-root 或其他相关选项）。

2. 文件名

生成的文件名遵循 <package-name>-<version>.tgz 格式：

<package-name>：从 package.json 中的 name 字段获取。
<version>：从 package.json 中的 version 字段获取。

3. 忽略文件

npm pack 会根据以下规则忽略文件：

默认忽略 .git 目录和 .npmignore 中列出的文件。
如果没有 .npmignore，则使用 .gitignore。

高级用法

1. 指定输出目录

使用 --pack-destination 选项指定打包文件的输出目录。

ini 复制代码

npm pack --pack-destination=./dist

2. 模拟打包过程

使用 --dry-run 选项模拟打包过程，检查哪些文件会被包含。

arduino 复制代码

npm pack --dry-run

3. 在工作区中使用

如果你的项目启用了工作区（workspaces），可以使用 --workspace 选项打包指定的工作区。

ini 复制代码

npm pack --workspace=my-workspace

使用场景

本地安装包 生成的 .tgz 文件可以直接用于本地安装。例如：
bash 复制代码
```
npm install ./my-project-1.0.0.tgz
```
分发项目 将 .tgz 文件分发给其他开发者或用于部署。
测试发布 在正式发布到 npm 仓库之前，使用 .tgz 文件进行测试安装和验证。

常见问题

如何控制打包内容？
- 使用 files 字段指定需要包含的文件。
- 使用 .npmignore 文件排除不需要的文件。
如何打包生产环境的依赖？ npm pack 默认只会打包生产环境的依赖。如果需要包含开发依赖，可以修改 package.json 或手动安装。
如何测试生成的 .tgz 文件？ 使用 npm install <file> 安装生成的 .tgz 文件，验证是否正常工作。

总结

npm pack 是一个强大的工具，它的核心功能包括：

将项目打包成一个 .tgz 文件。
生成的文件可用于本地安装、分发或测试发布。
支持自定义输出目录、模拟打包和工作区模式。

通过掌握 npm pack，你可以更好地管理和分发你的项目。

ping

npm ping 是 npm 提供的一个命令，用于测试与 npm 仓库的连接状态 。通过运行 npm ping，你可以检查你的本地环境是否能够成功连接到 npm 仓库，以及验证 npm 配置是否正确。这对于排查网络问题或 npm 配置问题非常有用。

基本用法

npm ping

作用：

测试与 npm 仓库的连接状态。
如果连接成功，返回仓库的状态信息。

示例输出：

css 复制代码

Ping success: { npm-registry: 'https://registry.npmjs.org/' }

详细解析

1. 默认行为

npm ping 会尝试连接到 npm 的默认仓库（https://registry.npmjs.org/），并检查是否能够成功通信。

2. 返回结果

如果连接成功，返回 Ping success 和仓库的地址。
如果连接失败，返回错误信息。

常见问题

1. 连接失败的原因

网络问题：检查你的网络连接是否正常。
代理问题：如果你使用了代理服务器，确保代理配置正确。
npm 配置问题 ：检查 .npmrc 文件中的 registry 配置是否正确。

2. 如何修改默认仓库

你可以通过 --registry 选项指定自定义的 npm 仓库地址。

ini 复制代码

npm ping --registry=https://your-custom-registry.com

3. 如何检查本地 npm 配置

运行以下命令查看当前的 npm 配置：

arduino 复制代码

npm config list

查看 registry 配置，确保其指向正确的仓库地址。

使用场景

排查网络问题 如果你在运行 npm install 或其他 npm 命令时遇到网络问题，可以先运行 npm ping 检查与 npm 仓库的连接状态。
验证自定义仓库 如果你使用了自定义的 npm 仓库，可以通过 npm ping 验证是否能够成功连接。
检查 npm 配置 npm ping 可以帮助你验证 .npmrc 文件中的 registry 配置是否正确。

高级用法

1. 结合 `--registry` 使用

测试与自定义仓库的连接状态。

ini 复制代码

npm ping --registry=https://your-custom-registry.com

2. 结合 `--verbose` 使用

显示详细的调试信息。

css 复制代码

npm ping --verbose

总结

npm ping 是一个简单的工具，它的核心功能包括：

测试与 npm 仓库的连接状态。
验证 npm 配置是否正确。
帮助排查网络问题或 npm 配置问题。

prefix

npm prefix 是 npm 提供的一个命令，用于获取当前项目的根目录路径 。它可以告诉你当前工作目录下最近的 package.json 文件所在的目录，这对于确定项目的根目录非常有用，尤其是在处理嵌套目录或工作区时。

基本用法

swift 复制代码

npm prefix

作用：

返回当前项目的根目录路径（即包含 package.json 的目录）。
如果没有找到 package.json，则返回当前工作目录的路径。

示例输出：

bash 复制代码

/path/to/your/project

详细解析

1. 默认行为

npm prefix 会从当前目录开始，向上查找包含 package.json 的目录，并返回该目录的路径。

2. 如果没有 `package.json`

如果从当前目录向上查找时没有找到 package.json，则返回当前工作目录的路径。

3. 与 `npm root` 的区别

npm prefix 返回的是包含 package.json 的目录。
npm root 返回的是当前项目的 node_modules 目录路径。

常用选项

选项	说明
`-g` 或 `--global`	返回全局安装的 npm 包的前缀路径。

使用场景

1. 确定项目根目录

在脚本或自动化工具中，npm prefix 可以帮助你定位项目的根目录。

bash 复制代码

PROJECT_ROOT=$(npm prefix)
echo "Project root: $PROJECT_ROOT"

2. 全局路径

获取全局安装 npm 包的前缀路径。

swift 复制代码

npm prefix -g

3. 结合其他命令使用

与其他命令结合使用，例如查找 node_modules 目录。

bash 复制代码

NODE_MODULES_PATH=$(npm prefix)/node_modules
echo "node_modules path: $NODE_MODULES_PATH"

高级用法

1. 在脚本中使用

在脚本中动态获取项目根目录。

bash 复制代码

#!/bin/bash
PROJECT_ROOT=$(npm prefix)
echo "Building project in: $PROJECT_ROOT"
cd $PROJECT_ROOT
npm run build

2. 在工作区中使用

如果你的项目启用了工作区（workspaces），npm prefix 仍然会返回项目根目录，而不是单个工作区的目录。

3. 结合 `npm root` 使用

获取 node_modules 的完整路径。

bash 复制代码

NODE_MODULES_PATH=$(npm root)
echo "node_modules path: $NODE_MODULES_PATH"

常见问题

1. 为什么返回的是当前目录？

如果当前目录或其父目录中没有 package.json，npm prefix 会返回当前工作目录的路径。

2. 如何确保返回的是项目根目录？

确保当前目录或其父目录中包含 package.json，或者直接在项目根目录下运行 npm prefix。

3. 全局路径的作用

全局路径通常用于查找全局安装的 npm 包的位置。

总结

npm prefix 是一个简单但很有用的命令，它的核心功能包括：

获取当前项目的根目录路径（包含 package.json 的目录）。
支持全局路径的查询。
适用于脚本、自动化工具或工作区场景。

root

返回的是当前项目的 node_modules 目录路径

query

npm query 是 npm 7 及更高版本引入的查询工具，它提供了一种灵活的方式来查找和分析项目的包信息。由于其强大的选择器语法和 JSON 输出，npm query 在多种场景下都非常有用。以下是 npm query 的常见运用场景：

1. 查找特定包

在大型项目中，依赖树可能非常复杂，npm query 可以帮助你快速查找某个特定的包。

示例：

查找项目中是否安装了 lodash：

erlang 复制代码

npm query "*[name="lodash"]"

2. 分析依赖关系

可以用于分析项目的依赖关系，包括直接依赖、间接依赖、开发依赖等。

示例：

查找项目的直接生产依赖：

erlang 复制代码

npm query ":root > dependencies > *"

查找项目的开发依赖：

erlang 复制代码

npm query ":root > devDependencies > *"

查找某个包的间接依赖：

erlang 复制代码

npm query ":path(/node_modules/lodash) > dependencies > *"

3. 过滤包

可以根据名称、版本、路径等条件过滤包，快速找到符合要求的包。

示例：

查找所有名称以 react 开头的包：

erlang 复制代码

npm query "*[name^="react"]"

查找所有版本以 1. 开头的包：

erlang 复制代码

npm query "*[version^="1."]"

查找某个路径下的包：

erlang 复制代码

npm query ":path(/node_modules/lodash)"

4. 检查包的版本

可以快速检查某个包的版本信息，或者查看所有包的版本。

示例：

查找 lodash 的版本：

erlang 复制代码

npm query "*[name="lodash"]"

查找所有包的名称和版本：

css 复制代码

npm query "*" --json | jq '.[] | {name: .name, version: .version}'

5. 排查依赖问题

在遇到依赖冲突或版本问题时，npm query 可以帮助你快速定位问题来源。

示例：

查找所有依赖 react 的包：

css 复制代码

npm query ":has(:root > dependencies > [name="react"])"

查找重复安装的包：

scss 复制代码

npm query "*" --json | jq 'group_by(.name) | map(select(length > 1))'

6. 自动化脚本

可以将 npm query 结合其他工具（如 jq）用于自动化脚本，提取和处理包信息。

示例：

生成依赖包的 CSV 文件：

css 复制代码

npm query "*" --json | jq -r '.[] | [.name, .version] | @csv' > dependencies.csv

查找所有未使用或不必要的开发依赖：

css 复制代码

npm query ":root > devDependencies > *" --json | jq '.[].name'

7. 包管理优化

在优化项目包管理时，npm query 可以帮助你识别冗余包、检查包的大小等。

示例：

查找所有安装的包的名称和大小：

css 复制代码

npm query "*" --json | jq '.[] | {name: .name, size: .size}'

8. 生成报告

可以生成项目的依赖报告，用于团队分享或存档。

示例：

生成项目的依赖树：

erlang 复制代码

npm query ":root > *" --json | jq .

生成 JSON 格式的依赖报告：

lua 复制代码

npm query "*" --json > dependencies.json

9. 集成到 CI/CD

可以将 npm query 集成到 CI/CD 流程中，自动检查项目的依赖是否符合要求。

示例：

检查是否有包的版本不符合预期：

erlang 复制代码

npm query "*[version^="1."]"

10. 教育和学习

对于初学者来说，npm query 是一个很好的工具，可以用来学习和理解 npm 包的结构和依赖关系。

示例：

查看项目的依赖树：

erlang 复制代码

npm query ":root > *"

总结

npm query 的应用场景非常广泛，主要包括：

查找特定包
分析依赖关系
过滤和检查包
排查依赖问题
自动化脚本
优化包管理
生成报告
集成到 CI/CD
教育和学习

通过灵活的选择器语法和 JSON 输出，npm query 可以帮助开发者更高效地管理和分析项目的依赖。

repo

在浏览器中打开软件包存储库页面，一般是github

打开的是package.json中的 repository字段配置的值

package.json

json 复制代码

// 方式一
"repository": {
    "type": "git",
    // 执行 npm repo vue 打开的是 https://github.com/vuejs/core.git
    "url": "git+https://github.com/vuejs/core.git"  
  }

// 方式二
// 执行 npm repo lodash 打开的是 https://github.com/lodash/lodash
"repository": "lodash/lodash"

restart

npm restart 是 npm 提供的一个命令，用于重新启动项目中配置的脚本。它通常是 npm stop 和 npm start 的组合操作，即先停止脚本运行，然后再启动脚本。以下是 npm restart 的详细解析和使用场景。

css 复制代码
scripts: {
	"dev": "vite",
 "start": "node bin/index.js",
}
运行start、stop、restart -> npm run start 或 npm start

运行除了上面之外的命令，只能是 npm run xxx 不能省略 run，因为start、stop是npm的预置命令

1. 基本语法

css 复制代码

npm restart [-- <args>]

-- <args>：可选参数，传递给脚本的附加参数。例如：
ini 复制代码
```
npm restart -- --port=3000
```

2. 工作原理

npm restart 的行为取决于项目 package.json 文件的 scripts 字段配置。它依次执行以下操作：

如果 package.json 中定义了 restart 脚本，则直接运行该脚本。
如果没有定义 restart 脚本，则依次执行 npm stop 和 npm start。

3. 常见用法

（1）基本用法

npm restart

（2）传递参数

ini 复制代码

npm restart -- --port=3000

4. `package.json` 配置

npm restart 的行为依赖于 package.json 中的 scripts 字段。以下是常见的配置示例：

（1）自定义 `restart` 脚本

直接在 scripts 中定义 restart 脚本：

json 复制代码

{
  "scripts": {
    "start": "node server.js",
    "stop": "pkill node",
    "restart": "npm stop && npm start"
  }
}

（2）默认行为

如果没有定义 restart 脚本，npm restart 会自动执行 npm stop 和 npm start：

json 复制代码

{
  "scripts": {
    "start": "node server.js",
    "stop": "pkill node"
  }
}

5. 使用场景

（1）重新启动服务

在开发或生产环境中，如果服务需要重新启动以应用更改，可以使用 npm restart。

示例：

npm restart

（2）热重载配置

在修改了配置文件或环境变量后，可以使用 npm restart 重启服务使更改生效。

示例：

npm restart

（3）调试和测试

在调试或测试过程中，可能需要频繁重启服务，npm restart 可以简化操作。

示例：

npm restart

6. 注意事项

（1）确保 `stop` 脚本有效

如果 restart 脚本未定义，npm restart 会尝试运行 npm stop。确保 stop 脚本能够正确停止服务，否则可能会导致进程残留。

（2）兼容性问题

在某些系统或环境中，npm restart 的行为可能不一致，建议明确配置 restart 脚本。

（3）权限问题

在 Linux 或 macOS 系统中，如果需要停止特定进程，可能需要管理员权限。

示例：

sudo npm restart

7. 与 `npm start` 和 `npm stop` 的关系

npm start：启动服务。
npm stop：停止服务。
npm restart：先停止服务，再启动服务（如果没有自定义 restart 脚本）。

8. 示例：完整的 `package.json` 配置

以下是一个完整的 package.json 示例，展示了如何配置 start、stop 和 restart 脚本：

json 复制代码

{
  "name": "my-app",
  "version": "1.0.0",
  "scripts": {
    "start": "node server.js",
    "stop": "pkill node",
    "restart": "npm stop && npm start"
  },
  "dependencies": {
    "express": "^4.17.1"
  }
}

9. 总结

npm restart 是一个方便的命令，用于重新启动项目中的脚本。它的主要用途包括：

重新启动服务
热重载配置
调试和测试

通过合理配置 package.json 中的 scripts 字段，可以确保 npm restart 的行为符合预期。

start、stop

npm start 和 npm stop 是 npm 中用于启动和停止项目的命令。它们通常与 package.json 文件中的 scripts 字段配合使用，定义项目的启动和停止行为。

1. `npm start`

作用

npm start 用于启动项目。它会执行 package.json 中 scripts 字段下的 start 脚本。

默认行为

如果没有在 package.json 中定义 start 脚本，npm start 会默认执行以下命令：

vbscript 复制代码

node server.js

如果项目根目录下没有 server.js 文件，则会报错。

自定义 `start` 脚本

你可以在 package.json 中自定义 start 脚本。例如：

json 复制代码

"scripts": {
  "start": "node app.js"
}

运行 npm start 时，npm 会执行 node app.js。

示例

使用 `react-scripts` 启动 React 项目

json 复制代码

"scripts": {
  "start": "react-scripts start"
}

运行 npm start 会启动 React 开发服务器。

使用 `nodemon` 启动 Node.js 项目

json 复制代码

"scripts": {
  "start": "nodemon server.js"
}

运行 npm start 会启动 nodemon，并监视文件变化自动重启。

2. `npm stop`

作用

npm stop 用于停止项目。它会执行 package.json 中 scripts 字段下的 stop 脚本。

默认行为

如果没有在 package.json 中定义 stop 脚本，npm stop 不会有任何效果。

自定义 `stop` 脚本

你可以在 package.json 中自定义 stop 脚本。例如：

json 复制代码

"scripts": {
  "stop": "killall node"
}

运行 npm stop 时，npm 会执行 killall node，终止所有 Node.js 进程。

示例

使用 PM2 管理进程

json 复制代码

"scripts": {
  "start": "pm2 start server.js",
  "stop": "pm2 stop server.js"
}

运行 npm start 会启动 server.js，运行 npm stop 会停止 server.js。

使用自定义脚本

json 复制代码

"scripts": {
  "start": "node server.js",
  "stop": "pkill -f server.js"
}

运行 npm start 会启动服务，运行 npm stop 会终止服务。

3. 组合使用

你可以将 start 和 stop 脚本组合使用，方便启动和停止项目。例如：

json 复制代码

"scripts": {
  "start": "node server.js",
  "stop": "pkill -f server.js",
  "restart": "npm stop && npm start"
}

npm start：启动服务。
npm stop：停止服务。
npm restart：停止并重新启动服务。

4. 其他相关命令

`npm run`

npm run <script-name> 可以运行 package.json 中定义的任何脚本。例如：

arduino 复制代码

npm run build

`npm test`

npm test 是 npm run test 的简写，用于运行测试脚本。

5. 总结

npm start ：用于启动项目，默认执行 node server.js。
npm stop：用于停止项目，需要自定义脚本才有效。
package.json ：通过 scripts 字段定义 start 和 stop 行为。
组合使用 ：可以定义 restart 脚本，方便重启服务。

合理使用 npm start 和 npm stop 可以简化项目的启动和停止操作，提升开发效率！

search

npm search 是 npm 提供的一个命令，用于在 npm 官方仓库中搜索包。它可以帮助开发者查找符合特定关键词的包，并查看包的描述、版本、作者等信息。以下是 npm search 的详细解析和使用场景。

1. 基本语法

css 复制代码

npm search <keyword> [options]

<keyword>：用于搜索包的关键词（支持模糊匹配）。
[options]：可选参数，用于配置搜索行为。

2. 常见用法

（1）基本搜索

搜索包含指定关键词的包：

sql 复制代码

npm search express

（2）多关键词搜索

支持同时搜索多个关键词，用空格分隔：

sql 复制代码

npm search react ui

（3）限制搜索结果数量

使用 --searchlimit 参数限制显示的搜索结果数量：

sql 复制代码

npm search react --searchlimit 5

（4）搜索并查看详细结果

使用 --long 参数显示更详细的结果，包括包的描述、版本、作者等：

sql 复制代码

npm search react --long

3. 搜索结果的字段

npm search 的输出通常包含以下字段：

name：包的名称。
description：包的描述。
version：最新版本号。
date：最新版本的发布时间。
author：包的作者。

4. 高级用法

（1）搜索指定类型的包

使用 --type 参数搜索特定类型的包：

ini 复制代码

npm search react --type=module

（2）搜索指定发布者的包

使用 --author 参数搜索特定作者发布的包：

ini 复制代码

npm search react --author=facebook

（3）搜索指定日期的包

使用 --date 参数搜索指定日期范围内发布的包：

ini 复制代码

npm search react --date="2023-01-01"

（4）搜索已弃用的包

使用 --deprecated 参数搜索已弃用的包：

sql 复制代码

npm search react --deprecated

5. 使用场景

（1）查找特定功能的包

例如，查找用于处理日期的包：

sql 复制代码

npm search date

（2）比较相似包

通过搜索找到多个功能相似的包，并比较其描述和版本：

sql 复制代码

npm search chart --long

（3）了解包的发布信息

通过 --long 参数查看包的详细发布信息：

sql 复制代码

npm search lodash --long

（4）筛选特定类型的包

例如，查找仅适用于 TypeScript 的包：

ini 复制代码

npm search typescript --type=module

6. 注意事项

（1）搜索结果受网络影响

npm search 依赖于 npm 官方仓库的在线数据，搜索速度和结果可能受网络环境影响。

（2）关键词模糊匹配

npm search 支持模糊匹配，即使关键词拼写不完全正确，也能返回相关结果。

（3）结果数量限制

默认情况下，npm search 显示 20 个结果。可以通过 --searchlimit 参数调整。

7. 与其他命令的区别

npm search：在 npm 官方仓库中搜索包，返回包的基本信息。
npm view：查看特定包的详细元数据，包括依赖、版本历史等。
npm install：安装特定包。

8. 示例

（1）基本搜索

搜索包含 express 关键词的包：

sql 复制代码

npm search express

（2）详细搜索

搜索包含 react 关键词的包，并显示详细信息：

sql 复制代码

npm search react --long

（3）限制搜索结果

搜索包含 chart 关键词的包，并限制结果数量为 5：

sql 复制代码

npm search chart --searchlimit 5

9. 总结

npm search 是一个用于在 npm 官方仓库中搜索包的命令，常用场景包括：

查找特定功能的包
比较相似包
了解包的发布信息
筛选特定类型的包

shrinkwrap

npm shrinkwrap 是一个用于锁定项目依赖版本的工具。它会生成一个 npm-shrinkwrap.json 文件，精确记录当前项目中所有依赖包及其子依赖包的版本号，确保在不同环境中安装时，依赖的版本完全一致。

作用

锁定依赖版本：确保在其他机器或环境中安装依赖时，版本与开发环境完全一致。
避免意外更新：防止因为依赖包的更新引入兼容性问题。
提升可重复性：确保构建和部署过程的可重复性。

与 `package-lock.json` 的区别

npm-shrinkwrap.json：
- 由 npm shrinkwrap 命令生成。
- 优先级高于 package-lock.json。
- 适合用于发布库或应用程序时锁定依赖。
package-lock.json：
- 由 npm 自动生成，无法手动生成。
- 优先级低于 npm-shrinkwrap.json。
- 适合用于本地开发环境。

使用场景

发布库 ：如果你在开发一个库并希望确保用户安装时依赖版本一致，可以使用 npm shrinkwrap。
生产环境 ：如果你在部署一个应用程序并希望确保生产环境的依赖与开发环境一致，可以使用 npm shrinkwrap。

命令解析

生成 `npm-shrinkwrap.json`

npm shrinkwrap

运行后，npm 会根据当前 node_modules 中的依赖生成一个 npm-shrinkwrap.json 文件。

更新依赖并重新生成

如果你更新了依赖，需要重新生成 npm-shrinkwrap.json：

删除现有的 npm-shrinkwrap.json 文件。
运行 npm install 安装新的依赖。
运行 npm shrinkwrap 重新生成文件。

安装时使用 `npm-shrinkwrap.json`

在安装依赖时，npm 会自动检测并优先使用 npm-shrinkwrap.json 中的版本信息：

npm install

文件示例

一个典型的 npm-shrinkwrap.json 文件内容如下：

json 复制代码

{
  "name": "my-project",
  "version": "1.0.0",
  "lockfileVersion": 1,
  "requires": true,
  "dependencies": {
    "express": {
      "version": "4.17.1",
      "resolved": "https://registry.npmjs.org/express/-/express-4.17.1.tgz",
      "integrity": "sha512-mHJ9O79RqluphRrcw2X/GTh3k9tVv8YcHPdI8Ly9aJ0=",
      "requires": {
        "accepts": "~1.3.7",
        "array-flatten": "1.1.1",
        "body-parser": "1.19.0",
        "content-disposition": "0.5.3"
      }
    },
    "accepts": {
      "version": "1.3.7",
      "resolved": "https://registry.npmjs.org/accepts/-/accepts-1.3.7.tgz",
      "integrity": "sha512-Il80Qs2WjYlQ==",
      "requires": {
        "mime-types": "~2.1.24",
        "negotiator": "0.6.2"
      }
    }
  }
}

注意事项

优先级 ：npm-shrinkwrap.json 优先级高于 package-lock.json，如果同时存在，npm 会优先使用 npm-shrinkwrap.json。
手动编辑 ：尽量避免手动编辑 npm-shrinkwrap.json 文件，可能会导致依赖问题。
版本控制 ：建议将 npm-shrinkwrap.json 文件提交到版本控制系统中，以确保团队协作时依赖一致。
更新依赖 ：如果需要更新依赖，建议使用 npm install <package>@<version> 并重新生成 npm-shrinkwrap.json。

总结

npm shrinkwrap 是一个强大的工具，特别适合在发布库或部署生产环境时锁定依赖版本，确保项目的稳定性和可重复性。如果你对依赖版本的一致性有严格要求，建议使用它来管理依赖。

version

npm version 是 npm 的一个命令，用于管理项目的版本号。它可以自动更新 package.json 中的版本号，并根据版本升级的类型创建 Git 提交和标签。

1. 命令格式

css 复制代码

npm version <version-type> [options]

<version-type>：指定版本升级的类型，可以是语义化版本号（如 1.0.0）或版本升级类型（如 patch、minor、major）。

版本升级类型

类型	说明
`patch`	升级补丁版本（如 `1.0.0` -> `1.0.1`），用于修复 bug。
`minor`	升级次要版本（如 `1.0.0` -> `1.1.0`），用于新增功能（不破坏兼容性）。
`major`	升级主版本（如 `1.0.0` -> `2.0.0`），用于破坏性变更（不向后兼容）。
`1.0.0`	直接指定版本号（如 `1.0.0`）。

其他格式

查看当前版本：
```
npm version
```
预发布版本：
ini 复制代码
```
npm version prerelease --preid=beta
```

2. 功能解析

更新 `package.json`

npm version 会自动更新 package.json 中的 version 字段。例如：

npm version patch

执行后：

如果当前版本是 1.0.0，则更新为 1.0.1。

创建 Git 提交

默认情况下，npm version 会创建一个 Git 提交，提交信息为版本号。例如：

1.0.1

创建 Git 标签

npm version 还会创建一个 Git 标签，标签名称为版本号。例如：

v1.0.1

3. 常用选项

选项	说明
`--no-git-tag-version`	不创建 Git 提交和标签。
`--preid`	指定预发布版本的标识符（如 `beta`）。
`--allow-same-version`	允许版本号不变（用于触发版本相关脚本）。
`--commit-hooks`	运行 Git 提交钩子（默认行为）。
`--no-commit-hooks`	不运行 Git 提交钩子。
`--git-tag-version`	创建 Git 提交和标签（默认行为）。
`--sign-git-tag`	对 Git 标签进行签名。

示例

不创建 Git 提交和标签：
css 复制代码
```
npm version patch --no-git-tag-version
```
创建预发布版本：
ini 复制代码
```
npm version prerelease --preid=beta
```
允许版本号不变：
css 复制代码
```
npm version patch --allow-same-version
```

4. 结合 Git 使用

npm version 默认与 Git 集成，执行以下操作：

更新 package.json 中的版本号。
创建一个 Git 提交，提交信息为版本号。
创建一个 Git 标签，标签名称为版本号。

注意事项

Git 仓库 ：必须在 Git 仓库中运行 npm version，否则会报错。
未提交的更改 ：如果有未提交的更改，npm version 会失败。可以使用 --no-git-tag-version 跳过 Git 操作。

5. 示例场景

场景 1：升级补丁版本

假设当前版本是 1.0.0，需要升级补丁版本：

npm version patch

执行后：

版本号更新为 1.0.1。
创建一个 Git 提交和标签。

场景 2：升级次要版本

假设当前版本是 1.0.0，需要升级次要版本：

npm version minor

执行后：

版本号更新为 1.1.0。
创建一个 Git 提交和标签。

场景 3：创建预发布版本

假设当前版本是 1.0.0，需要创建预发布版本：

ini 复制代码

npm version prerelease --preid=beta

执行后：

版本号更新为 1.0.0-beta.0。
创建一个 Git 提交和标签。

场景 4：直接指定版本号

将版本号直接设置为 2.0.0：

npm version 2.0.0

6. 结合 npm 生命周期脚本

npm version 会触发以下 npm 生命周期脚本：

preversion：在版本号更新之前执行。
version：在版本号更新之后、Git 提交和标签创建之前执行。
postversion：在 Git 提交和标签创建之后执行。

例如，在 package.json 中定义：

json 复制代码

"scripts": {
  "preversion": "npm test",
  "postversion": "git push && git push --tags"
}

执行 npm version patch 时：

先运行 npm test。
更新版本号。
创建 Git 提交和标签。
最后运行 git push && git push --tags。

7. 总结

npm version 是一个强大的工具，用于管理项目的版本号。它的主要功能包括：

自动更新 package.json 中的版本号。
创建 Git 提交和标签。
支持语义化版本升级（patch、minor、major）。
支持直接指定版本号。
支持预发布版本。
结合 npm 生命周期脚本，可以自定义版本控制流程。

view

npm view 是 npm 的一个命令，用于查看 npm 包的详细信息。它可以帮助你查看包的元数据、版本历史、依赖关系等信息，而无需实际安装包。

1. 命令格式

css 复制代码

npm view <package-name> [<field>] [options]

<package-name>：需要查看的包名称。
<field>：可选参数，指定要查看的特定字段（如 version、dependencies 等）。

其他格式

查看包的所有信息：
go 复制代码
```
npm view <package-name>
```
查看包的特定字段：
xml 复制代码
```
npm view <package-name> <field>
```
查看包的特定版本的字段：
xml 复制代码
```
npm view <package-name>@<version> <field>
```

2. 功能解析

查看包的所有信息

npm view 默认会显示指定包的所有元数据。例如：

sql 复制代码

npm view lodash

执行后，会输出 lodash 包的详细信息，包括：

包的名称、描述、版本、作者、许可证等。
依赖关系、脚本、发布历史等。

查看包的特定字段

如果只想查看包的某个字段，可以指定字段名称。例如：

sql 复制代码

npm view lodash version

执行后，会输出 lodash 的最新版本号：

4.17.21

查看包的特定版本的信息

如果需要查看包的某个特定版本的信息，可以使用 @ 符号指定版本号。例如：

sql 复制代码

npm view lodash@4.17.20 dependencies

执行后，会输出 lodash@4.17.20 版本的依赖关系。

3. 常用选项

选项	说明
`--json`	以 JSON 格式输出信息。
`--registry <url>`	指定自定义的 npm 注册表地址。

示例

以 JSON 格式输出信息：
sql 复制代码
```
npm view lodash --json
```

使用自定义注册表：

ini 复制代码

npm view lodash --registry=https://registry.npmjs.org/

4. 常用字段

以下是一些常用的字段及其说明：

字段	说明
`name`	包的名称。
`version`	当前版本号。
`description`	包的描述。
`dependencies`	包的依赖关系。
`devDependencies`	包的开发依赖关系。
`scripts`	包的脚本命令。
`license`	包的许可证。
`author`	包的作者信息。
`repository`	包的代码仓库地址。
`keywords`	包的关键字。
`dist`	包的发布信息（如 tarball 文件地址）。

5. 示例场景

场景 1：查看包的所有信息

查看 lodash 包的所有信息：

sql 复制代码

npm view lodash

场景 2：查看包的版本号

查看 lodash 包的最新版本号：

sql 复制代码

npm view lodash version

场景 3：查看包的依赖关系

查看 lodash 包的依赖关系：

sql 复制代码

npm view lodash dependencies

场景 4：查看包的特定版本的信息

查看 lodash@4.17.20 版本的描述：

sql 复制代码

npm view lodash@4.17.20 description

场景 5：以 JSON 格式输出信息

以 JSON 格式查看 lodash 包的信息：

sql 复制代码

npm view lodash --json

6. 结合 `npm outdated` 使用

npm view 可以与 npm outdated 结合使用，查看哪些包需要更新。例如：

npm outdated

然后使用 npm view 查看特定包的详细信息：

go 复制代码

npm view <package-name>

7. 总结

npm view 是一个非常实用的命令，用于查看 npm 包的详细信息。它的主要功能包括：

查看包的所有元数据。
查看特定字段或版本的信息。
支持以 JSON 格式输出信息。
帮助开发者了解包的依赖关系、版本历史等信息。

常用的npm scripts （一般命令）

读取配置的位置

查看npm config的存储目录

1. 查看 npm 默认配置文件的路径

2. 查看用户级别的 npm 配置文件路径

3. 查看全局 npm 配置文件路径

4. 查看项目级别的 .npmrc 文件

总结

配置的优先级

1. 命令行参数

2. 环境变量

3. 项目级别的 .npmrc 文件

4. 用户级别的 .npmrc 文件

5. 全局级别的 npmrc 文件

优先级总结

示例

注意事项

win系统--设置环境变量

方法 1：通过图形化界面设置

方法 2：通过命令行设置

临时设置（仅对当前会话生效）

永久设置

验证环境变量

总结

一般命令

bin

bugs

cache

1. 查看缓存目录

2. 清理缓存

3. 验证缓存完整性

输出结果示例：

4. 查看缓存信息

5. 设置缓存目录

6. 查看缓存统计信息

总结

ci

npm ci 的作用

npm ci 的使用场景

npm ci 的命令格式

npm ci 与 npm install 的区别

示例

1. 在 CI/CD 环境中使用 npm ci

2. 仅安装生产依赖

3. 跳过安全审计

注意事项

总结

dedupe

1. 作用

2. 使用场景

3. 基本语法

4. 工作原理

5. 举个例子

6. 注意事项

7. 与 npm install 的关系

8. 与 npm prune 的区别

9. 总结

prune

基本用法

详细解析

1. 默认行为

2. 支持的选项

3. 与 npm install 的关系

使用场景

1. 清理未使用的包

2. 仅删除生产环境的未使用包

3. 查看哪些包会被删除

4. 以 JSON 格式输出删除的包

常见问题

1. npm prune 会删除全局包吗？

2. npm prune 会更新 package-lock.json 吗？

3. npm prune 和 npm uninstall 的区别

4. 为什么 npm prune 没有删除某些包？

总结

prune 和 dedupe的区别

npm prune

作用

使用场景

命令示例

特点

4. 查看项目级别的 `.npmrc` 文件

3. 项目级别的 `.npmrc` 文件

4. 用户级别的 `.npmrc` 文件

5. 全局级别的 `npmrc` 文件

`npm ci` 的作用

`npm ci` 的使用场景

`npm ci` 的命令格式

`npm ci` 与 `npm install` 的区别

1. 在 CI/CD 环境中使用 `npm ci`

7. 与 `npm install` 的关系

8. 与 `npm prune` 的区别

3. 与 `npm install` 的关系

1. `npm prune` 会删除全局包吗？

2. `npm prune` 会更新 `package-lock.json` 吗？

3. `npm prune` 和 `npm uninstall` 的区别

4. 为什么 `npm prune` 没有删除某些包？

`npm prune`

`npm dedupe`

`npm prune` 的使用场景

`npm dedupe` 的使用场景

（1）发布一个测试版本并标记为 `beta`

（3）将 `1.1.0-beta` 标记为 `latest`

（4）删除 `beta` 标签

`npm explore` 的基本用法

`npm explore` 的功能

1. 进入 `lodash` 包的目录

2. 在 `lodash` 包的目录中执行命令

`npm find-dupes` 的基本用法

`npm find-dupes` 的功能

`npm hook` 的基本用法