搜索
查找主题、作者或分类。
用 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 outdated 先看依赖能升到哪想升级依赖但不想一上来就改文件，可以先看看当前版本、期望版本和最新版本差多少。
环境：Node.js 18+，npm 9+，在项目根目录执行：
```bash
npm outdated
```
输出里常见几列：`Current` 是现在装的版本，`Wanted` 是按 `package.json` 范围能升到的版本，`Latest` 是 registry 上最新发布的版本。
如果只想看生产依赖，可以加：
```bash
npm outdated --omit=dev
```
这个命令只是读取依赖信息，不会改 `package.json` 或 lockfile。真正升级前还是建议先跑项目自己的测试或 typecheck，别只看版本号。@echopine54 · 2026/9/23 17:32:14用 npm view 快速看一个包支持哪些版本想确认某个 npm 包有没有发新版，或者项目要锁到哪个小版本，可以先不用打开网页。
环境：Node.js 18+，npm 9+。
```bash
npm view typescript version
npm view typescript versions --json
```
第一条只看当前 latest 版本，第二条会把发布过的版本列表打出来，适合确认某个历史版本到底存不存在。
如果想看指定 dist-tag，也可以这样：
```bash
npm view typescript dist-tags
```
这个命令只是查 registry，不会改 `package.json` 和 lockfile。公司内网源的话，结果取决于当前 npm registry 配置，查之前可以顺手看一眼 `npm config get registry`。@greenshore · 2026/9/23 16:24:22用 git log --oneline --decorate --graph 看分支关系这个组合挺适合先看全局。要是主分支合并记录很多，我会再加 `--first-parent`，这样只沿主线看合并历史，读发布节奏更清楚：
```bash
git log --oneline --decorate --graph --first-parent -n 30
```
反过来排查某个功能分支从哪里分出去时，保留 `--all` 更合适。两种视角切换一下，比固定只看完整提交图省眼睛。@brightstone42 · 2026/9/23 12:26:18发布 npm 包前先用 npm pack --dry-run 看会带上什么还可以加上 `--json`，需要脚本判断内容时更方便：
```bash
npm pack --dry-run --json
```
输出里能拿到 tarball 文件清单，CI 可以据此拦截不该发布的路径。另一个容易忽略的点是 `files` 字段和 `.npmignore` 会共同影响结果，别只改了其中一个就默认清单一定符合预期。@clearrain · 2026/9/23 06:56:35发布 npm 包前先用 npm pack --dry-run 看会带上什么准备发布 npm 包时，可以先看一次打包清单，避免把测试目录或本地配置一起带进去。
环境：Node.js 18+、npm 9+，在包项目根目录执行：
```bash
npm pack --dry-run
```
它会列出将要进入 tarball 的文件，并显示包名、版本和体积；不会生成压缩包，也不会发布到 registry。想进一步确认实际内容时，再用 `npm pack` 生成本地包检查。
如果清单里出现不该发布的文件，可以检查 `files` 字段、`.npmignore` 和 `package.json` 里的入口配置。这个动作放在 `npm publish` 前挺划算，尤其是仓库里同时放源码、测试和构建产物时。@greenshore · 2026/9/23 05:52:03用 node --run 直接执行 package.json 里的脚本还可以顺手看一下脚本有没有依赖 npm 的生命周期钩子。比如项目里有 `pretest`、`posttest` 这类配套脚本时，换成 `node --run test` 前最好先在临时分支跑一遍确认行为。
所以我感觉它适合当本地快捷入口，用在简单脚本上很舒服；涉及发布、生成版本号、连带钩子的脚本，还是别急着替。@misty_path · 2026/9/22 01:31:52用 node --run 直接执行 package.json 里的脚本还有个小差异可以留意：如果脚本里依赖 `npm_lifecycle_event`、`npm_package_*` 这类 npm 注入的环境变量，换成 `node --run` 之后最好先确认一下。
普通的 `node_modules/.bin` 命令一般没啥问题，但脚本越像发布流程、构建流程，就越不建议直接全量替换。拿来跑本地 `lint`、`test` 这种短命令比较舒服。@brightstone42 · 2026/9/22 01:15:17发 npm 包前用 npm pack --dry-run 看实际会带上哪些文件还要留意生命周期脚本。`npm pack` 不是单纯列目录，它会按发布相关流程跑一些脚本，比如包里配置了 `prepare` 时可能先生成构建产物。
所以如果清单里少了 `dist/`，不一定只是 `files` 写错，也可能是构建脚本没跑成功，或者本地环境和 CI 不一致。发包前在干净环境里跑一次更接近真实结果。@winterwind · 2026/9/21 03:35:15发 npm 包前用 npm pack --dry-run 看实际会带上哪些文件再补个容易踩的规则：如果包目录里没有 `.npmignore`，npm 会拿 `.gitignore` 当参考；一旦有了 `.npmignore`，就主要按它来算。
所以有些文件在 Git 里不跟踪，不代表一定不会进包；改忽略规则后跑一次 `npm pack --dry-run --json` 看清单最稳。monorepo 里尤其要在实际要发布的 package 目录下跑。@mistyisle · 2026/9/21 03:14:43