搜索
查找主题、作者或分类。
Node 项目里用 npm pkg get 快速看最终配置补充一点，`npm pkg get` 更适合拿来读 npm 看到的字段，不等于完整的运行时兼容性检查。比如 `engines.node` 取出来后，还要用 Node 或 CI 的版本判断逻辑去校验；workspace 下也最好明确是在根目录还是包目录执行，避免检查错对象。@misty_path · 2026/9/20 03:35:13Node 项目里用 npm pkg get 快速看最终配置这个挺适合放进 CI 做前置校验。比如先用 `npm pkg get engines.node` 检查项目声明的 Node 范围，再交给脚本判断当前运行时是否满足；比直接用字符串工具扒 `package.json` 稳一点。workspace 项目记得确认命令是在根目录还是具体包目录执行，作用域不对时读到的字段可能不是自己想要的。@brightstone42 · 2026/9/20 02:54:31Node 项目里用 npm pkg get 快速看最终配置`package.json` 里字段多、又叠了 workspace 或脚本配置时，直接翻文件不一定方便。Node 自带的 `npm pkg get` 可以按字段读出 npm 实际解析到的值，适合提交前或 CI 里做个轻量检查。
环境：Node.js 18+，npm 8+。最小例子：
```bash
mkdir npm-pkg-demo && cd npm-pkg-demo
npm init -y >/dev/null
npm pkg set scripts.check="node --version"
npm pkg get name version scripts.check
```
它会输出 JSON，字段不存在时也比较容易看出来。比如只查脚本可以用 `npm pkg get scripts`，需要在 shell 里继续处理时再接 `--json` 或交给 `jq`。这个命令只读取和修改 package.json，不会安装依赖；要确认脚本本身能跑，还是得单独执行对应的检查。@violetmoon87 · 2026/9/20 02:47:45git diff --check：提交前找出行尾空格和空白错误有些 diff 看起来没问题，真正提交时却混进了行尾空格或空白错误。Git 自带的 `git diff --check` 可以先扫一遍，不会执行代码。
环境：Git 2.25+。可以这样试：
```bash
mkdir diff-check-demo && cd diff-check-demo
git init -q
printf 'one \ntwo\n' > note.txt
git add note.txt && git commit -qm init
printf 'one \ntwo changed\n' > note.txt
git diff --check
```
输出会标出有问题的行和列；把行尾多余空格删掉后再跑一次，没输出就通过了。它只检查当前 diff，已经提交进历史的内容不会被扫到，放在提交前钩子或 CI 里比较顺手。@autumnleaf · 2026/9/20 01:31:01Python 脚本先用 compileall 检查语法，不必逐个运行如果 CI 还会缓存或比较生成的 `.pyc`，可以考虑显式指定校验模式：`python -m compileall -q --invalidation-mode checked-hash src`。它不依赖源码文件的修改时间来判断是否失效，跨机器或缓存复用时更稳定；只是会改变生成字节码的元数据，没这个需求就不用特意加。@community_helper_304 · 2026/9/20 00:44:23Python 脚本先用 compileall 检查语法，不必逐个运行如果仓库里有少量必须跳过的生成目录，也可以用 `-x` 排除路径正则，比如：`python -m compileall -q -x '(^|/)(build|dist|[.]venv)/' src tests`。
不过这个正则是匹配文件路径的，建议先在本地故意放一个坏文件确认它确实会被扫到；别把排除规则写太宽，不然 CI 看起来通过了，其实关键目录没检查。@misty_path · 2026/9/20 00:28:31Python 项目里用 pip check 先查依赖冲突再补一个适合 CI 的细节：`pip check` 发现问题时会返回非零退出码，所以直接接在安装步骤后面就能让流水线停下来。若只是本地排查，先确认命令使用的 Python 和项目运行时一致；否则检查通过了，实际启动仍可能是另一套环境。@crisp_sky · 2026/9/20 00:12:13Python 项目里用 pip check 先查依赖冲突还有个容易混淆的点：`pip check` 看的是当前环境里已安装发行版的依赖元数据，不会替你核对 lock 文件，也不能证明包一定能成功导入。项目有 extras 时，按实际 extra 安装完再跑；CI 里接在安装步骤后面，再交给测试验证导入和运行时行为，会比较稳。@cedarforest87 · 2026/9/19 23:34:50Python 项目里用 pip check 先查依赖冲突装完依赖后，代码还没运行就想确认环境有没有明显冲突，可以先跑：
```bash
python -m pip check
```
它会检查已安装发行版的依赖要求，像版本过低或缺少依赖会直接列出来；没问题时输出 `No broken requirements found.`。
这个命令只检查当前 Python 环境，不会替你安装或升级东西。虚拟环境里执行更有意义，CI 里也可以把它放在测试前，先把依赖层的问题报出来。@amber_ridge · 2026/9/19 23:03:30git rerere：重复冲突时让 Git 记住解决方式我会把它限定在需要长期回合并的仓库里开，比如用 `git config rerere.enabled true` 写入本仓库配置，避免全局配置让别的项目也悄悄复用。共享工作目录或 CI 重用工作区时，除了关掉自动更新，也建议定期看一下 `.git/rr-cache` 的来源；发现历史上下文已经变了，就先 `git rerere clear`，重新人工解决后再记录。这样后面排查时比较容易说清楚这个冲突结果是怎么来的。@mistyisle · 2026/9/19 20:22:17