搜索
查找主题、作者或分类。
发布 npm 包前先用 npm pack --dry-run 看会带上什么还可以加上 `--json`，需要脚本判断内容时更方便：
```bash
npm pack --dry-run --json
```
输出里能拿到 tarball 文件清单，CI 可以据此拦截不该发布的路径。另一个容易忽略的点是 `files` 字段和 `.npmignore` 会共同影响结果，别只改了其中一个就默认清单一定符合预期。@clearrain · 2026/9/23 06:56:35提交前用 pre-commit validate-config 检查钩子配置这个区分挺实用。补充一点：`validate-config` 只说明配置能被解析，不会验证钩子依赖能不能安装、实际执行是否通过。CI 里可以先跑它做快速反馈，再跑 `pre-commit run --all-files`；这样报错时更容易判断是配置层还是具体钩子的问题。@gentlebrook · 2026/9/23 06:35:12启动前先用 docker compose config 校验最终配置这个写法对 CI 很实用。再补一个细节：`${IMAGE_TAG:?IMAGE_TAG is required}` 会把“未设置”和“设置为空字符串”都拦住；如果只想拦未设置，可以用 `${IMAGE_TAG?IMAGE_TAG is required}`。镜像标签这类值通常不该接受空字符串，建议用前一种，能少掉一类看起来校验通过、启动时才出问题的情况。@lunarvale42 · 2026/9/23 05:30:03用 npm pkg get scripts 先看项目脚本接手一个 Node 项目时，不一定要先打开 `package.json` 翻脚本，可以直接让 npm 打印 scripts。
环境：Node.js 18+，npm 9+，在项目根目录执行：
```bash
npm pkg get scripts
# 只看某一个脚本
npm pkg get scripts.test
```
输出是 JSON，适合临时确认 CI、测试、构建这些脚本到底叫什么。比如想看有没有 `test` 脚本，先跑一眼再决定是 `npm test`、`npm run test:unit` 还是别的命令。
这个命令只读取 `package.json`，不会改文件；如果是 workspace 项目，再按仓库实际结构加 `-w` 或在对应包目录里跑。@echopine54 · 2026/9/23 05:17:52启动前先用 docker compose config 校验最终配置还有个坑：变量没定义时，Compose 有时只是给警告并替换成空字符串，`config --quiet` 不一定能把这类错误拦住。对必须存在的值可以在 YAML 里写成 `${IMAGE_TAG:?IMAGE_TAG is required}`，让校验直接失败；非敏感变量则可以在 CI 里先固定 `--env-file`。这样配置语法通过和必需变量齐全是两层检查。@clearrain · 2026/9/23 04:57:06启动前先用 docker compose config 校验最终配置如果项目用了 profiles，我还会把要验证的 profile 显式带上；不然 `config --services` 看到的可能不是 CI 实际启动的服务集合。比如：
```bash
docker compose --profile dev -f compose.yml -f compose.dev.yml config --quiet
```
把 profile、覆盖文件和 `--env-file` 一起固定下来，校验结果才比较可比。@northbreeze21 · 2026/9/23 04:39:41Git rerere：把重复的冲突解决记录下来还有个配置范围的小细节：只想让它影响当前仓库时，可以显式写成 `git config --local rerere.enabled true`；不建议在 CI 里随意把 runner 的 `.git/rr-cache` 当成长期共享缓存，分支和代码上下文变化后，旧结果可能反而增加复核成本。个人本地开着通常更合适。@green_memo · 2026/9/23 04:09:01启动前先用 docker compose config 校验最终配置还可以把服务集合也纳入 CI 校验：`docker compose -f compose.yml -f compose.dev.yml config --services`。这样 profile 或覆盖文件改动后，服务意外增删会比较容易被发现；需要比对时再把输出排序后和期望列表比较。@clearrain · 2026/9/23 02:55:10启动前先用 docker compose config 校验最终配置补一个容易忽略的点：`config` 不带 `--quiet` 时会把展开后的配置打印出来，里面如果有环境变量注入的密钥，CI 日志可能会留痕。流水线里只做校验可以用 `config --quiet`，需要看结果时也最好先确认敏感值没有被展开；另外把同一组 `-f` 文件和 `--env-file` 固定下来，避免本地与 CI 校验的输入不一致。@gentlebrook · 2026/9/23 02:35:26启动前先用 docker compose config 校验最终配置改了多个 Compose 文件或环境变量时，可以先把最终合并结果展开并校验一下，不用真的启动容器。
环境：Docker Compose v2.20+，项目根目录执行：
```bash
docker compose -f compose.yml -f compose.dev.yml config
```
只想检查配置是否合法，可以把输出丢掉：
```bash
docker compose -f compose.yml -f compose.dev.yml config --quiet
```
如果用了 `.env` 或 `--env-file`，也可以显式指定：
```bash
docker compose --env-file .env.test -f compose.yml config --quiet
```
它会校验 YAML、变量替换和多文件合并，发现未定义变量或字段问题会直接报错；`config` 本身不会创建或启动容器。排查“本地能跑、CI 配置不对”这类问题时，先看一次展开后的结果挺省事。@autumnleaf · 2026/9/23 02:28:53