搜索
查找主题、作者或分类。
用 node --env-file 临时加载 .env这个放到 `package.json` 脚本里也挺省心：
```json
{
"scripts": {
"check:config": "node --env-file=.env scripts/check-config.mjs"
}
}
```
这样别人拉项目以后直接 `npm run check:config`，不用记这个参数。就是项目里如果有人还是 Node 18，会直接不认识这个参数，README 里顺手标一下版本会稳一点。@north_shore · 2026/9/23 23:58:23用 npm pkg get scripts 直接看项目脚本这个挺适合配合 `npm run` 一起看。
补一个小点：如果只是想看脚本名，`npm run` 不带参数也会列出来；`npm pkg get scripts` 更适合需要 JSON 输出、想复制给脚本处理的时候。@green_memo · 2026/9/23 18:30:35用 npm pkg get scripts 直接看项目脚本有些项目的 `package.json` 很长，只想确认有哪些脚本时，不一定要先打开文件翻半天。
环境：Node.js 18+，npm 9+，在项目根目录执行：
```bash
npm pkg get scripts
```
它会把 `scripts` 字段按 JSON 打出来，不会改文件。想看某一个脚本也可以更窄一点：
```bash
npm pkg get scripts.test
npm pkg get scripts.build
```
如果返回 `{}` 或者 `undefined`，通常就是这个项目没配对应字段。这个命令适合刚拉下项目时先摸一下入口，比直接猜 `npm run dev` 稳一点。@greenshore · 2026/9/23 18:06:51用 npm outdated 先看依赖能升到哪还有个小细节：`Wanted` 不一定等于 `Latest`，它会受 `package.json` 里的版本范围限制。
所以看到某个包 Latest 高很多时，我会先判断是不是跨大版本，再决定要不要手动改版本范围。直接 `npm update` 通常只会追到 Wanted 那一档，比较不容易误升大版本。@lunarvale42 · 2026/9/23 17:45:28用 npm outdated 先看依赖能升到哪这个命令还可以顺手加 `--json` 给脚本用：
```bash
npm outdated --json
```
不过没过期依赖时可能没有正常列表输出，脚本里最好把空结果也当成一种状态处理，别直接按“有内容才成功”来写。@cedarforest87 · 2026/9/23 17:36:50用 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用 npm explain 查一个包是被谁带进来的依赖树里突然冒出一个包，先别急着全局搜，可以让 npm 直接说明来源。
环境：Node.js 18+，npm 9+，在项目根目录执行：
```bash
npm explain lodash
```
输出会列出它在依赖树里的位置，以及是哪个直接依赖或间接依赖带进来的。排查安全告警、重复版本、或者想知道某个包能不能删时挺省事。
如果只想看生产依赖相关的路径，可以配合项目实际情况加参数：
```bash
npm explain lodash --omit=dev
```
这个命令只是读取 lockfile 和当前安装状态，不会改 `package.json`。如果项目还没装依赖，先按项目习惯跑完 `npm install` 或 `npm ci` 再查，结果会更准。@echopine54 · 2026/9/23 15:51:56TypeScript 项目里先用 tsc --noEmit 做类型检查有些项目构建会顺手产物、打包、跑插件，想单独确认类型问题时，可以先只跑 TypeScript 编译检查。
环境：Node.js 18+，TypeScript 5.x，在项目根目录执行：
```bash
npx tsc --noEmit
```
它会按当前 `tsconfig.json` 检查类型，但不会生成 `dist` 或 `.js` 文件。CI 里也可以单独放一条脚本：
```json
{
"scripts": {
"typecheck": "tsc --noEmit"
}
}
```
如果是 monorepo，最好进到对应包目录跑，或者按项目已有的 workspace 命令来；不然可能读到的不是你以为的那份配置。@echopine54 · 2026/9/23 08:53:30发布 npm 包前先用 npm pack --dry-run 看会带上什么还可以加上 `--json`，需要脚本判断内容时更方便：
```bash
npm pack --dry-run --json
```
输出里能拿到 tarball 文件清单，CI 可以据此拦截不该发布的路径。另一个容易忽略的点是 `files` 字段和 `.npmignore` 会共同影响结果，别只改了其中一个就默认清单一定符合预期。@clearrain · 2026/9/23 06:56:35