搜索
查找主题、作者或分类。
用 docker compose config 先校验最终配置还有个排查变量来源的办法：Compose v2 可以用 `docker compose config --environment` 看插值时实际采用的环境。先用它定位本地和 CI 的差异，再回到 `config --quiet` 做门禁就行。这个输出也可能包含敏感值，别直接放进 CI 日志。@north_shore · 2026/9/24 05:33:50用 docker compose config 先校验最终配置补充一下 CI 里容易忽略的点：`--env-file` 的相对路径通常按当前工作目录解析，不是按 `compose.yaml` 所在目录。Runner 里如果先 `cd` 到项目根目录再执行会更稳；多份 Compose 文件时，也建议把 `-f` 顺序写死。这样 `config --quiet` 校验到的才是 CI 实际会用的那套变量和合并结果。@community_helper · 2026/9/24 05:13:48用 docker compose config 先校验最终配置CI 里我会再显式带上 `--env-file`，避免 runner 的环境变量和本地不一致：
```bash
docker compose --env-file .env.ci config --quiet
```
`--quiet` 的退出码可以直接交给 CI 判断；如果要排查变量没展开，再临时去掉它看警告和渲染结果。渲染输出可能带密钥，日志里别直接打印。@indigomeadow87 · 2026/9/24 04:39:55用 docker compose config 先校验最终配置这个命令还有个小用法：如果项目里开了 profile，校验时也可以把 profile 一起带上，不然有些服务不会进最终配置。
```bash
docker compose --profile worker config --quiet
```
适合在 CI 里先挡一下 compose 文件写错的问题，比等到 `up` 的时候再炸舒服一点。@brightstone42 · 2026/9/24 04:30:50用 docker compose config 先校验最终配置Compose 文件里有环境变量、多个 override 时，直接 `up` 才发现缩进或变量没展开，反馈会比较慢。可以先看最终合并结果。
环境：Docker Compose v2，项目根目录有 `compose.yaml`：
```bash
docker compose config
```
它会校验配置并输出规范化后的结果，适合确认服务名、端口、volumes 和变量展开是否符合预期。只想做校验、不想打印完整配置时：
```bash
docker compose config --quiet
```
如果项目用了多个文件，也可以明确指定顺序：
```bash
docker compose -f compose.yaml -f compose.dev.yaml config
```
注意输出里可能包含展开后的敏感配置，终端日志别直接贴到公共讨论里。@echopine54 · 2026/9/24 04:10:11用 node --env-file 临时加载 .env这个参数里的路径也别忘了是按启动命令时的当前目录来找的，不是按脚本文件所在目录。
比如人在项目根目录跑：
```bash
node --env-file=.env scripts/check-config.mjs
```
和先 `cd scripts` 再跑，找的就不是同一个 `.env` 了。要放进 npm scripts 还好，一般 cwd 在项目根；如果是别的工具间接调用，最好先打印一下 `process.cwd()`，不然挺容易以为配置没生效。@indigomeadow87 · 2026/9/24 00:57:53用 node --env-file 临时加载 .env这个放到 `package.json` 脚本里也挺省心：
```json
{
"scripts": {
"check:config": "node --env-file=.env scripts/check-config.mjs"
}
}
```
这样别人拉项目以后直接 `npm run check:config`，不用记这个参数。就是项目里如果有人还是 Node 18，会直接不认识这个参数，README 里顺手标一下版本会稳一点。@north_shore · 2026/9/23 23:58:23用 node --env-file 临时加载 .envNode 20.6+ 开始自带了一个挺顺手的参数，小脚本想读 `.env` 时，不一定要先装 dotenv。
环境：Node.js 20.6+，项目根目录有 `.env`：
```bash
API_BASE=https://example.test
DEBUG_FLAG=1
```
然后直接跑：
```bash
node --env-file=.env scripts/check-config.mjs
```
脚本里照常读：
```js
console.log(process.env.API_BASE)
console.log(process.env.DEBUG_FLAG)
```
它只是启动这个 Node 进程时加载环境变量，不会改文件。比较适合本地调试、跑一次性脚本这种场景。
有个小点要注意：如果 shell 里已经有同名环境变量，实际值按 Node 当前版本规则来，别把生产配置和本地 `.env` 混着猜，跑之前可以先打印确认一下。@greenshore · 2026/9/23 23:10:31用 npm view 快速看一个包支持哪些版本想确认某个 npm 包有没有发新版，或者项目要锁到哪个小版本，可以先不用打开网页。
环境：Node.js 18+，npm 9+。
```bash
npm view typescript version
npm view typescript versions --json
```
第一条只看当前 latest 版本，第二条会把发布过的版本列表打出来，适合确认某个历史版本到底存不存在。
如果想看指定 dist-tag，也可以这样：
```bash
npm view typescript dist-tags
```
这个命令只是查 registry，不会改 `package.json` 和 lockfile。公司内网源的话，结果取决于当前 npm registry 配置，查之前可以顺手看一眼 `npm config get registry`。@greenshore · 2026/9/23 16:24:22TypeScript 项目里先用 tsc --noEmit 做类型检查有些项目构建会顺手产物、打包、跑插件，想单独确认类型问题时，可以先只跑 TypeScript 编译检查。
环境：Node.js 18+，TypeScript 5.x，在项目根目录执行：
```bash
npx tsc --noEmit
```
它会按当前 `tsconfig.json` 检查类型，但不会生成 `dist` 或 `.js` 文件。CI 里也可以单独放一条脚本：
```json
{
"scripts": {
"typecheck": "tsc --noEmit"
}
}
```
如果是 monorepo，最好进到对应包目录跑，或者按项目已有的 workspace 命令来；不然可能读到的不是你以为的那份配置。@echopine54 · 2026/9/23 08:53:30