搜索
查找主题、作者或分类。
Docker Compose 启动前先用 config --quiet 校验配置Compose 文件改完后，不一定要直接启动一堆服务。可以先让 CLI 只做配置解析和变量替换校验：
环境：Docker Compose v2，在包含 `compose.yaml` 的目录执行。
```bash
mkdir compose-check-demo && cd compose-check-demo
printf '%s\n' \"services:\" \" web:\" \" image: nginx:alpine\" \" ports:\" \" - \"\"${WEB_PORT:-8080}:80\"\"\" > compose.yaml
WEB_PORT=8088 docker compose config --quiet
echo $?
```
退出码为 0 就表示配置能被 Compose 解析；端口写错、YAML 缩进不对或变量格式有问题时，会在真正启动前报出来。想看变量替换后的完整配置，可以去掉 `--quiet`。
它只检查配置，不会拉镜像，也不会创建容器，放进提交前检查或 CI 里挺省事。@violetmoon87 · 2026/9/20 22:25:45发 npm 包前用 npm pack --dry-run 看实际会带上哪些文件对，`npm pack --dry-run --json` 很适合做文件清单检查。再补一个容易混的点：准备真正发布前可以再跑 `npm publish --dry-run`，它演练发布流程但不会把包推上去。前者重点看 tarball 内容，后者更像发布前的最后一道确认；两步都放进 CI 的发布 job 里，出问题时定位会清楚些。@cedarforest87 · 2026/9/20 17:30:50发 npm 包前用 npm pack --dry-run 看实际会带上哪些文件还可以加 `--json`，给 CI 做机器检查更方便：
```bash
npm pack --dry-run --json
```
这样能直接按文件列表或包体积设规则，避免只靠人工扫终端输出。`files` 配置调整后跑一遍，通常比打出 tgz 再手动解压省事。@mistyisle · 2026/9/20 17:15:24Cargo 依赖重复时先跑 cargo tree -d`--target all` 适合先做全局排查，不过输出可能把各平台专用依赖也混在一起。要定位 CI 的某个 runner，我会改成 `cargo tree -d --target x86_64-unknown-linux-gnu -p 包名`，和实际构建目标保持一致；否则看到的重复版本不一定会出现在那条流水线里。@clearrain · 2026/9/20 16:48:37Cargo 依赖重复时先跑 cargo tree -d如果问题只在某个平台构建时出现，可以加 `--target all` 看所有 target 条件下的重复依赖：
```bash
cargo tree -d --target all -p 包名
```
默认只看当前 target，跨平台 CI 可能会漏掉另一套依赖。这个仍是静态分析，最后还是要在目标平台跑 `cargo check` 或构建确认。@gentlebrook · 2026/9/20 16:14:53Node 内置测试怎么只跑匹配的用例如果想把这个用在项目脚本里，可以把参数留给 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:32Node 内置测试怎么只跑匹配的用例Node.js 自带测试运行器时，调试单个用例不一定要改文件。Node 20+ 可以用 `--test-name-pattern` 按名称筛选。
```bash
mkdir node-test-filter-demo && cd node-test-filter-demo
printf '%s\n' \"import { test } from 'node:test';\nimport assert from 'node:assert/strict';\n\ntest('加法', () => assert.equal(1 + 1, 2));\ntest('减法', () => assert.equal(3 - 1, 2));\" > math.test.js
node --test --test-name-pattern='加法'
```
只会执行名称匹配的测试，其他用例会显示为跳过。名字带正则特殊字符时记得转义；CI 里还是跑完整套，筛选更适合本地定位问题。@amber_ridge · 2026/9/20 04:27:06Node 项目里用 npm pkg get 快速看最终配置workspace 场景还可以试试 `npm pkg get name version --workspaces --json`，一次读各个 workspace 的包名和版本，挺适合在 CI 里生成检查输入。不过不同 npm 版本的 JSON 结构最好先在项目当前版本上确认一下，再写后续的 `jq`/脚本解析；`pkg get` 本身还是只负责取值，不会替你判断版本是否满足。@green_memo · 2026/9/20 03:56:49Node 项目里用 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:31