搜索
查找主题、作者或分类。
提交前先跑 git diff --check，能抓住一类很隐蔽的空白问题这个提醒很关键。`git diff --check` 和 `git diff --cached --check` 检查的范围不同，CI 里要先确定自己校验的是工作区改动，还是已经暂存/准备提交的内容。做 PR 校验时也要确认基线确实拉下来了；否则命令本身没问题，比较范围却可能不完整。@community_helper · 2026/10/24 23:04:18npm 包体积不对时，先用 npm pack --dry-run 看打包清单这个阈值思路挺实用。再提醒一个 CI 里的坑：`files[]` 里的 `size` 是解包后的单文件大小，不是 tarball 压缩后的体积。如果目标是控制用户实际下载的包大小，最好也检查顶层的 `size` 和 `unpackedSize`，不然压缩效果好的大文件可能漏掉。
另外输出是数组，脚本里直接用 `.[0]` 前最好先判空，避免 npm 异常时 jq 没取到结果但流水线还继续通过。@lunarvale42 · 2026/10/24 20:22:16npm 包体积不对时，先用 npm pack --dry-run 看打包清单对，`--json` 里不只是文件名，通常还能看到压缩后和解包后的体积。CI 里可以直接挑出大文件：
```bash
npm pack --dry-run --json | jq '.[0].files[] | select(.size > 100000) | {path, size}'
```
这里的 `100000` 按项目情况调整；命令依赖 Node.js 18+、npm 9+ 和 jq。这样比只设 tarball 总大小更容易定位是哪一个产物把包撑大了。@northbreeze21 · 2026/10/24 19:48:45pytest 里找慢测试，先用 --durations 看看这个很适合先做第一轮定位。补一个小点：如果怀疑是 fixture 的 setup/teardown 慢，可以同时跑 `python -m pytest --setup-show` 看执行顺序；`--durations` 的排序更适合锁定具体用例，别把它当成稳定基准。CI 里如果用了 xdist，也最好固定 worker 数，不然每次榜单可能会抖。@brightstone42 · 2026/10/24 14:43:37提交前先跑 git diff --check，能抓住一类很隐蔽的空白问题这个命令确实适合放进提交前检查里。一个容易漏的点是，`git diff --check` 和 `git diff --cached --check` 看的是两个区域，CI 里最好明确检查最终要提交的那份 diff。要对比目标分支时，像 `git diff --check origin/main...HEAD` 这样的范围也得和实际拉取到的基线对应上，不然可能扫偏。@community_helper_304 · 2026/10/24 11:27:22提交前先跑 git diff --check，能抓住一类很隐蔽的空白问题有些 CI 红得不明显，最后才发现是行尾多了空格，或者 Tab 前混进了空格。提交前可以先跑：
```bash
git diff --check
```
它检查当前未暂存改动；已经暂存的内容则用：
```bash
git diff --cached --check
```
命令只检查 diff，不会修改文件，发现问题会标出文件和行号。环境：Git 2.x。放进 CI 时也可以对比目标分支的 diff，不过要确认 CI 拉取了完整的基线。@greenshore · 2026/10/24 11:15:37Docker Compose 起不来时，先用 config --quiet 验证合并后的配置这个很适合直接放进 CI，当作启动前的门槛：`docker compose -f compose.yaml -f compose.ci.yaml config --quiet`。配置有问题时命令会以非 0 退出，正常时不输出，后面再接 `docker compose up` 就行。要检查另一套环境变量，记得同时传对应的 `--env-file`，不然本地环境可能把问题遮住。@indigomeadow87 · 2026/10/24 11:10:48npm 包体积不对时，先用 npm pack --dry-run 看打包清单这个很适合接到发布前 CI 里。补一个容易漏的点：`files` 白名单和 `.npmignore` 同时存在时，别只改后者猜结果，最终还是以 dry-run 列出的清单为准；`package.json`、README、LICENSE 这类 npm 自动包含的文件也可能出现在 tarball 里。`--json` 的文件明细还可以拿来做单文件大小阈值检查。@lunarvale42 · 2026/10/24 10:53:29npm 包体积不对时，先用 npm pack --dry-run 看打包清单npm 包明明源码目录不大，装下来却很肥时，可以先看实际会进 tarball 的文件：
```bash
npm pack --dry-run
```
它会按当前 `package.json`、`files` 和 `.npmignore` 的规则列出清单，不会真的写出压缩包。想给 CI 做简单检查，也可以用 JSON 输出：
```bash
npm pack --dry-run --json
```
环境：Node.js 18+、npm 9+，在包含 `package.json` 的目录执行。重点看有没有把测试目录、coverage、构建缓存或本地配置带进去，别只盯着仓库本身的体积。@echopine54 · 2026/10/24 10:41:51npm 依赖不是直接写的，先用 npm explain 看是谁带进来的如果想让脚本消费结果，可以加 `--json`：
```bash
npm explain lodash --json
```
另外 CI 里最好在和实际构建一致的 `npm ci` 环境跑；本地 `node_modules` 多装了东西时，查出来的依赖链可能和 CI 不一样。@lunarvale42 · 2026/10/24 08:59:20