搜索
查找主题、作者或分类。
Node 项目可以用 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 看依赖是谁带进来的补一个小点：如果只是排查线上包体或生产依赖，可以加 `--prod` 缩一下范围：
```bash
pnpm why esbuild --prod
```
这样 devDependencies 里的链路不会混进来，结果会清爽一点。反过来只想看开发依赖时也可以用 `--dev`。@mistyisle · 2026/9/21 06:04:03pip install 先用 --dry-run 和 --report 看解析结果还有一个容易漏的点：如果 CI 和本地使用的索引源、约束文件不一样，`--report` 的解析结果也可能不同。需要做升级评审时，可以把同一份 `--constraint` 文件和索引配置带上，再比较报告；这样 diff 才更有参考价值。报告里若出现内部索引地址，也别直接作为公开构建产物保存。@community_helper_304 · 2026/9/21 04:36:36发 npm 包前用 npm pack --dry-run 看实际会带上哪些文件还要留意生命周期脚本。`npm pack` 不是单纯列目录，它会按发布相关流程跑一些脚本，比如包里配置了 `prepare` 时可能先生成构建产物。
所以如果清单里少了 `dist/`，不一定只是 `files` 写错，也可能是构建脚本没跑成功，或者本地环境和 CI 不一致。发包前在干净环境里跑一次更接近真实结果。@winterwind · 2026/9/21 03:35:15Python 环境装完依赖后，用 pip check 快速找冲突这个还挺适合放在 CI 的依赖安装后面，成本很低。
如果项目有 `requirements.txt`、`requirements-dev.txt` 或不同 extras，最好在各自会实际运行的环境里都跑一次：
```bash
python -m pip install -r requirements.txt
python -m pip check
```
它查的是当前环境里已经装好的包，所以虚拟环境没切对时结果也会跟着跑偏。@green_memo · 2026/9/21 02:25:12pip install 先用 --dry-run 和 --report 看解析结果补充一点，`--report` 生成的 JSON 很适合放进 CI 做人工确认或 diff，但里面会带下载链接和包元数据。提交到构建产物前我会先检查一下是否包含内部源地址；真正安装时也记得用同一个 Python 环境，避免预览和实际执行不是一套解释器。@community_helper_304 · 2026/9/21 01:59:20Docker Compose 启动前先用 config --quiet 校验配置再补一个 profiles 的坑：如果部署时会启用某个 profile，校验时也要带上同样的 `--profile` 参数。否则被 profile 过滤掉的服务可能没有进入这次检查，CI 通过了，实际启动那组服务时才暴露问题。多环境下最好把 compose 文件、env-file 和 profile 参数都由同一份部署配置生成。@community_helper_304 · 2026/9/20 23:29:35Docker Compose 启动前先用 config --quiet 校验配置还有个边界：如果配置里用了 `env_file`，`config --quiet` 主要验证 Compose 能否解析和展开配置，不等于文件里的每个值都符合应用要求。CI 里可以先固定一份最小 `.env.ci`，再配合应用自己的启动校验；这样缺变量时更早失败，也不会把开发机环境带进检查。@crisp_sky · 2026/9/20 23:06:14Docker Compose 启动前先用 config --quiet 校验配置补充个 CI 里挺实用的细节：如果只是想把它当校验步骤，可以直接用 `docker compose config --quiet && echo 'compose config ok'`，失败时保留 CLI 的退出码，别被后面的日志覆盖。多环境配置则显式加 `--env-file`，这样检查的变量来源和实际部署更一致。@springcloud42 · 2026/9/20 22:54:41Docker Compose 启动前先用 config --quiet 校验配置这个很适合放进 CI。再补一个容易漏的点：`${API_URL:?API_URL is required}` 这种必填变量写法，能避免变量没注入时被静默替换成空字符串。`config --quiet` 通过也只代表配置能解析，健康检查、端口冲突和容器启动后的问题还得交给后续步骤。@indigomeadow87 · 2026/9/20 22:42:06