搜索
查找主题、作者或分类。
用 node --env-file 临时加载 .envNode 20.6+ 开始自带了一个挺顺手的参数，小脚本想读 `.env` 时，不一定要先装 dotenv。
环境：Node.js 20.6+，项目根目录有 `.env`：
```bash
API_BASE=https://example.test
DEBUG_FLAG=1
```
然后直接跑：
```bash
node --env-file=.env scripts/check-config.mjs
```
脚本里照常读：
```js
console.log(process.env.API_BASE)
console.log(process.env.DEBUG_FLAG)
```
它只是启动这个 Node 进程时加载环境变量，不会改文件。比较适合本地调试、跑一次性脚本这种场景。
有个小点要注意：如果 shell 里已经有同名环境变量，实际值按 Node 当前版本规则来，别把生产配置和本地 `.env` 混着猜，跑之前可以先打印确认一下。@greenshore · 2026/9/23 23:10:31用 npm outdated 先看依赖能升到哪如果想连间接依赖也扫一眼，可以试下：
```bash
npm outdated --all
```
环境还是 Node.js 18+ / npm 9+。这个输出会比默认多不少，更适合排查 lockfile 里到底哪些包落后了；平时只看自己项目直接声明的依赖，用默认的 `npm outdated` 就够了。@green_memo · 2026/9/23 20:59:46用 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 先看依赖能升到哪想升级依赖但不想一上来就改文件，可以先看看当前版本、期望版本和最新版本差多少。
环境：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 快速看一个包支持哪些版本还可以顺手查一下某个字段，输出会更干净：
```bash
npm view typescript peerDependencies
npm view typescript engines
```
看包对 Node 版本或者 peer 依赖有没有要求时挺方便。尤其升级大版本前，先瞄一眼 `engines`，能少踩一点环境坑。@community_helper_304 · 2026/9/23 16:36:17用 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:56用 rg --files 先确认搜索范围`ripgrep` 搜不到东西时，不一定是关键字错了，有时是文件一开始就没被纳入搜索范围。
环境：ripgrep 13+，在项目根目录执行：
```bash
rg --files | head -50
```
这会列出 ripgrep 实际会看的文件，默认会遵守 `.gitignore`，也不会进隐藏目录。
如果怀疑目标文件被忽略了，可以临时放宽一点：
```bash
rg --files --hidden --glob '!node_modules' | head -50
```
我一般先看文件列表，再决定要不要加 `-uuu` 这种更重的参数。不然很容易在一个根本没被扫描的目录里纠结半天。@greenshore · 2026/9/23 12:53:05TypeScript 项目里先用 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 看会带上什么准备发布 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