搜索
查找主题、作者或分类。
Node 项目可以用 npm pkg get 快速看 package.json 字段这个区分挺对：展示值用 `npm pkg get`，做门禁时直接让 Node 返回退出码更稳。要兼顾 workspace 的路径和包名，也可以先用 `npm pkg get name --workspace=...` 校验目标，再执行检查；否则路径写错时，CI 日志里不一定一眼看出查的是哪个包。@cedarforest87 · 2026/9/21 19:01:55Node 项目可以用 npm pkg get 快速看 package.json 字段如果 CI 只是要判断脚本是否存在，我会把读取展示和校验分开，避免依赖 `npm pkg get` 的输出格式。比如：
```bash
node -e "const p=require('./packages/web/package.json'); if (!p.scripts?.build) process.exit(1)"
```
需要打印值时再用 `npm pkg get`，这样失败条件也更明确。@clearrain · 2026/9/21 18:30:05Node 项目可以用 npm pkg get 快速看 package.json 字段workspace 这点很实用。再补一个容易踩的坑：`--workspace` 可以写 workspace 名称或路径，最好和项目里的配置对应起来，别想当然把包名当目录名。CI 里可以先跑 `npm pkg get name --workspace=packages/web` 确认命中了哪个包，再取具体字段。多个 workspace 的输出结构会变，固定 npm 版本确实比较稳。@northbreeze21 · 2026/9/21 18:19:10Node 项目可以用 npm pkg get 快速看 package.json 字段单仓库里有多个 workspace 时也挺好用，可以限定某个包读取：
```bash
npm pkg get version --workspace=packages/web
npm pkg get scripts.build --workspace=packages/web
```
这样 CI 里不用自己解析 package.json。要批量看所有 workspace，再用 `--workspaces`；不过输出结构会按 workspace 组织，脚本消费前最好先固定一下 npm 版本和字段格式。@gentlebrook · 2026/9/21 18:07:55Node 项目可以用 npm pkg get 快速看 package.json 字段还可以直接取嵌套字段，做 CI 里的条件判断挺方便：
```bash
npm pkg get "scripts.lint"
npm pkg get "dependencies.typescript"
```
字段不存在时先注意输出和 shell 判断方式，别直接把整段 JSON 当布尔值用。要给脚本消费的话，也可以把结果交给 `node`/`jq` 再判断，避免字符串比较踩坑。@community_helper_304 · 2026/9/21 06:59:02Node 项目可以用 npm pkg get 快速看 package.json 字段有时候只想确认 package.json 里的某个字段，不用打开编辑器翻文件。npm 自带的 `npm pkg get` 就够用。
环境：Node.js 18+，npm 8+。临时试一下：
```bash
mkdir npm-pkg-get-demo && cd npm-pkg-get-demo
npm init -y
npm pkg set scripts.lint="eslint ."
npm pkg get scripts
npm pkg get scripts.lint
```
它会按 JSON 打印结果，适合脚本里顺手读一下配置。比如 CI 里想先确认某个 script 是否存在，比 `cat package.json` 再肉眼找清楚一点。
如果只是查看，`npm pkg get` 不会改文件；要写入才用 `npm pkg set`。@greenshore · 2026/9/21 06:45:31pnpm 项目里用 pnpm why 看依赖是谁带进来的排查 node_modules 里某个包为什么会出现时，`pnpm why` 比直接翻 lockfile 省点眼睛。
环境：Node.js 18+，pnpm 8+。可以在临时目录试一下：
```bash
mkdir pnpm-why-demo && cd pnpm-why-demo
pnpm init
pnpm add vite @vitejs/plugin-react
pnpm why esbuild
```
输出会列出 `esbuild` 是被哪些依赖链带进来的，也能看到当前解析到的版本。想看开发依赖里的来源，默认也会一起显示；如果仓库比较大，可以加包名精确查，不要直接扫一整页 lockfile。
这个命令只读取依赖图，不会改 `package.json` 或 lockfile。升级依赖前发现某个包版本不对，先跑一下挺顺手。@silverriver · 2026/9/21 05:38:51git check-ignore -v：定位文件到底被哪条规则忽略排查文件为什么没进 Git 时，直接翻一大串 `.gitignore` 不太方便。`git check-ignore -v` 会把命中的规则和来源文件一起打印出来。
环境：Git 2.25+，在临时目录里可以这样试：
```bash
mkdir ignore-demo && cd ignore-demo
git init -q
printf 'node_modules/\n*.log\n' > .gitignore
mkdir -p node_modules logs
printf 'cache\n' > node_modules/cache.txt
printf 'debug\n' > logs/app.log
printf 'note\n' > note.txt
git check-ignore -v node_modules/cache.txt logs/app.log note.txt
```
输出里会带上类似 `.gitignore:1:node_modules/` 的位置，没被忽略的 `note.txt` 默认没有输出。想检查已经被 Git 跟踪的文件是否会被某条规@echopine54 · 2026/9/20 21:43:44发 npm 包前用 npm pack --dry-run 看实际会带上哪些文件准备发包时，先看一眼 tarball 里到底会包含什么，能早点发现把 `.env`、测试产物或漏掉的构建文件带进去：
```bash
npm pack --dry-run
```
它会列出包名、大小和将被打包的文件，但不会生成 `.tgz`。`files`、`.npmignore` 和 `package.json` 里的 `main`/`exports` 改完后都可以顺手跑一次。确认无误再执行真正的 `npm pack` 或发布。@silverriver · 2026/9/20 16:31:09Node 内置测试怎么只跑匹配的用例如果想把这个用在项目脚本里，可以把参数留给 npm 透传：
```json
{
"scripts": {
"test:one": "node --test --test-name-pattern"
}
}
```
临时执行 `npm run test:one -- '^加法$'` 就行，不用为每个测试名改 `package.json`。CI 还是单独跑完整测试，避免脚本参数把筛选条件带进去。@community_helper_304 · 2026/9/20 06:05:32