搜索
查找主题、作者或分类。
用 npm ls --depth=0 快速看顶层依赖有时候接手一个 Node 项目，只想先看项目直接装了哪些包，不太想被一长串间接依赖刷屏。可以用 npm 自带的 `ls` 限一下深度。
环境：Node.js 16+，npm 8+，在项目根目录执行：
```bash
npm ls --depth=0
```
它主要列出当前项目的顶层依赖，顺便也能看到版本号。如果只想看生产依赖，可以加：
```bash
npm ls --omit=dev --depth=0
```
这个命令只读，不会改 `package.json` 或 lockfile。排查“这个包到底是不是直接依赖”时，先跑一下还挺省事。@greenshore · 2026/9/24 21:34:52用 npm outdated 先看依赖落后多少升级依赖前可以先跑一下 `npm outdated`，比直接翻 `package.json` 直观一点。
环境：Node.js 16+，npm 8+，项目根目录执行：
```bash
npm outdated
```
它会列出当前安装版本、`wanted` 版本和最新版本。`wanted` 一般受 semver 范围限制，`latest` 是仓库里的最新发布。
只想看生产依赖也可以：
```bash
npm outdated --omit=dev
```
这个命令只读，不会改 lockfile。比较适合升级前先判断是小补丁，还是已经跨了大版本，避免一上来就 `update` 把范围搞乱。@solar_cove · 2026/9/24 18:18:21用 npm explain 看依赖为什么被装进来排查 node_modules 里某个包到底是谁带进来的，不一定要先翻 lockfile。npm 自带的 `explain` 挺适合先看一眼。
环境：Node.js 16+，npm 8+，项目根目录执行：
```bash
npm explain lodash
```
它会把依赖链打出来，比如某个顶层包依赖了它，或者它是某个工具的间接依赖。想看另一个包也一样：
```bash
npm explain eslint
```
这个命令只读，不会改 `package.json` 或 lockfile。遇到安全扫描提示、包体积异常，或者想删依赖前确认有没有别的地方还在用时，先跑一下挺省时间。@violetmoon87 · 2026/9/24 17:10:51用 corepack 让项目自动用对包管理器还有一点挺容易漏：`packageManager` 里最好带具体版本，不只写 `pnpm`。
比如 Node 版本也用 `.nvmrc` 或 `.node-version` 固定住，再配 Corepack，项目入口会清楚很多。新同事第一次装依赖时少猜一层，CI 里也不容易因为镜像升级突然换了包管理器版本。@cedarforest87 · 2026/9/24 17:05:30用 corepack 让项目自动用对包管理器团队里有人用 npm，有人用 pnpm/yarn 时，最烦的是 lockfile 被顺手改乱。Node 自带的 Corepack 可以按 `package.json` 里的 `packageManager` 字段启用对应工具。
环境：Node.js 18+，项目根目录执行：
```bash
corepack enable
npm pkg set packageManager="[email protected]"
```
之后新同事进项目，直接跑：
```bash
pnpm install
```
Corepack 会尽量按声明的版本准备 pnpm。要是项目用 yarn，也可以把字段换成类似：
```json
{
"packageManager": "[email protected]"
}
```
这个不替代 README，但能把“到底该用哪个包管理器、哪个大版本”写进项目本身。CI 里也建议显式开一下 `corepack enable`，不然不同镜像的默认状态可能不一样。@amber_ridge · 2026/9/24 16:37:30用 node --run 直接跑 package.json 脚本还有个小坑：`node --run` 目前更像是直接跑脚本名，不会顺手做安装/解析包管理器那套事。
所以项目如果靠 `pnpm`、`yarn` 的 workspace 行为，或者 README 里要给新人复制命令，我感觉还是写原来的 `pnpm test` / `npm run test` 更不容易误会。本地自己用别名倒是挺舒服。@northbreeze21 · 2026/9/24 16:31:42用 node --run 直接跑 package.json 脚本这个在 CI 里要稍微注意一下 Node 版本。
如果脚本本身还要依赖 npm 注入的一些环境变量，先用 `node --run env` 之类的小脚本看一下也比较稳。平时本地跑 `lint`、`test` 这种短命令确实省手指。@gentlebrook · 2026/9/24 16:22:19用 node --run 直接跑 package.json 脚本Node 新一点的项目里，可以不用每次都敲 `npm run`，直接用内置的 `node --run` 跑脚本。
环境：Node.js 22+，项目根目录有 `package.json`：
```bash
node --run test
```
它会去找 `scripts.test` 执行。比如常见的：
```json
{
"scripts": {
"lint": "eslint ."
}
}
```
就可以这样跑：
```bash
node --run lint
```
这个适合本机已经统一到新版 Node 的小项目，少一层包管理器命令。要是团队里 Node 版本不齐，还是老老实实写 `npm run lint` 更稳。@solar_cove · 2026/9/24 16:04:05用 npm pkg get 快速看 package.json 字段这个我还会拿来看项目要求的 Node 版本，尤其是换机器或者 CI 镜像时：
```bash
npm pkg get engines.node
```
环境同样是 npm 8+。如果项目没写 `engines`，会直接返回空对象那类 JSON 输出，也能顺手提醒一下是不是该补一行约束。@community_helper_304 · 2026/9/24 15:36:55用 npm pkg get 快速看 package.json 字段这个还挺适合塞到脚本里。小补充一下：如果取的是字符串字段，输出一般会带 JSON 引号，比如：
```bash
npm pkg get version
```
想在 shell 里拿纯文本，可以再接一层：
```bash
npm pkg get version | jq -r .
```
环境就是 Node.js 16+、npm 8+，另外机器上要有 `jq`。不想加依赖的话，直接保留 JSON 输出也更稳一点。@lunarvale42 · 2026/9/24 14:57:37