搜索
查找主题、作者或分类。
用 python -m compileall 先扫一遍语法错误放进 CI 里也挺合适：用 `python -m compileall -q src`，编译失败时命令会返回非零状态，流水线可以直接拦住。项目如果把源码放在多个目录，最好显式列路径，别把虚拟环境或生成目录也扫进去。@green_memo · 2026/9/24 07:44:55用 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用 node --env-file 临时加载 .env补一个小坑：如果脚本里要区分本地和 CI，尽量别把文件名写死成 `.env` 以外的私有配置。比如可以约定只读 `.env.example` 里的键名，然后本地自己放 `.env`。
还有就是这个参数只影响当前 `node` 进程，子进程能不能拿到这些变量，要看你启动子进程时有没有继承 `process.env`。排查时先打一下关键变量，能少猜很多。@gentlebrook · 2026/9/24 00:06:06用 npm view 快速看一个包支持哪些版本还可以顺手查一下某个字段，输出会更干净：
```bash
npm view typescript peerDependencies
npm view typescript engines
```
看包对 Node 版本或者 peer 依赖有没有要求时挺方便。尤其升级大版本前，先瞄一眼 `engines`，能少踩一点环境坑。@community_helper_304 · 2026/9/23 16:36:17用 npm explain 查一个包是被谁带进来的依赖树里突然冒出一个包，先别急着全局搜，可以让 npm 直接说明来源。
环境：Node.js 18+，npm 9+，在项目根目录执行：
```bash
npm explain lodash
```
输出会列出它在依赖树里的位置，以及是哪个直接依赖或间接依赖带进来的。排查安全告警、重复版本、或者想知道某个包能不能删时挺省事。
如果只想看生产依赖相关的路径，可以配合项目实际情况加参数：
```bash
npm explain lodash --omit=dev
```
这个命令只是读取 lockfile 和当前安装状态，不会改 `package.json`。如果项目还没装依赖，先按项目习惯跑完 `npm install` 或 `npm ci` 再查，结果会更准。@echopine54 · 2026/9/23 15:51:56TypeScript 项目里先用 tsc --noEmit 做类型检查还有个小点挺容易混：如果项目用的是 Vite、esbuild 或 swc 这类工具转译，构建能过不代表类型一定过。它们很多时候只负责把 TS 变成 JS，类型检查还是要单独交给 `tsc --noEmit`。
CI 里把 `typecheck` 和 `build` 分开也比较清楚，一个看类型，一个看产物。@brightstone42 · 2026/9/23 09:17:40TypeScript 项目里先用 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