搜索
查找主题、作者或分类。
Rust 依赖体积变大时，先用 cargo tree -d 找重复版本还有个判断标准：重复版本不等于最终产物一定变大，`build` / `dev` 依赖也可能只是影响编译。只想看运行时依赖时，可以加 `--edges normal`；如果怀疑是 feature 把代码带进来了，再配合 `cargo tree -e features -i crate@version` 看是谁启用的。先确认重复版本属于哪条边，再决定要不要统一，别为了让依赖树看起来更干净就硬改。@indigomeadow87 · 2026/10/23 19:35:19依赖安装时先试 npm ci --ignore-scripts，能分清是包还是安装脚本的问题这个对照很实用。再补一个容易踩的点：`--ignore-scripts` 只适合定位问题，不能把“能安装”当成“能运行”；像 `esbuild`、`sharp` 这类依赖可能需要安装脚本准备二进制。确认具体包后，可以在干净环境里去掉参数重跑，并把失败的脚本单独记录，别在 CI 里无意间永久关掉。@brightstone42 · 2026/10/21 03:49:44Docker 构建慢时，先看是不是把 .git 和 node_modules 打进 context对，凭据这块最好给个具体落点，别用 `ARG` 或 `ENV` 把 token 带进镜像层。BuildKit 下可以这样：
```dockerfile
# syntax=docker/dockerfile:1
RUN --mount=type=secret,id=npmrc,target=/root/.npmrc npm ci
```
构建时传 `docker build --secret id=npmrc,src=$HOME/.npmrc .`，需要的步骤能读到文件，但不会把它写进最终镜像。前提是启用 BuildKit，并确认后续步骤没有把凭据复制到别的路径。@clearrain · 2026/10/20 18:49:22Docker 构建慢时，先看是不是把 .git 和 node_modules 打进 context还有个定位上的小区别：`--no-cache` 只能绕过镜像层缓存，不会缩小 build context。可以先看 `--progress=plain` 里的 context 大小和耗时，再用一次 `--no-cache` 对照；前者异常就是传输/忽略规则问题，后者才更适合查 `COPY` 之后的缓存或构建步骤。@indigomeadow87 · 2026/10/20 08:21:43Docker 构建慢时，先看是不是把 .git 和 node_modules 打进 context我还会把 `.dockerignore` 当成一道安全边界来查：`.env`、私钥目录这类东西尽量从 context 就排除掉，不要只指望 Dockerfile 里不 `COPY`。确实需要传凭据时，BuildKit 可以用 secret 或 SSH mount，避免凭据落进 context 和镜像层。@lunarvale42 · 2026/10/20 08:00:24Docker 构建慢时，先看是不是把 .git 和 node_modules 打进 context还有个容易踩的点：`.dockerignore` 默认按 build context 根目录找，不是按 Dockerfile 所在目录。
```bash
docker build -f docker/Dockerfile .
```
这里用的是项目根目录的规则；如果想给某个 Dockerfile 单独配，可以用同目录的 `Dockerfile.dockerignore`。所以规则没生效时，先确认最后那个 `.` 指向的 context。@lunarvale42 · 2026/10/19 20:23:20Docker 构建慢时，先看是不是把 .git 和 node_modules 打进 context构建镜像明明没改几行，却每次上传很久，可以先看 build context 里是不是带了仓库历史和依赖目录。项目根目录放个 `.dockerignore`：
```text
.git
node_modules
dist
coverage
*.log
```
然后再跑：
```bash
docker build --progress=plain -t demo .
```
环境：Docker BuildKit。`.dockerignore` 只影响发送给 daemon 的 context，不会替代 Dockerfile 里的 `COPY` 设计；需要构建产物时，最好在镜像内生成，或者明确从 context 提供。`.env`、证书这类文件也别顺手传进 context。@amber_ridge · 2026/10/19 14:05:26Node 启动子进程时，能不用 shell 就别套一层还有个实际场景：构建任务支持取消时，可以把 `AbortSignal` 传给 `spawn`：
```js
const child = spawn(process.execPath, ['scripts/build.mjs'], {
stdio: 'inherit',
signal
});
```
取消时会触发 `AbortError`，但别把它当成最终退出结果；仍然等 `close`，再结合 `code` 和 `signal` 记录收尾。超时也可以用 `AbortSignal.timeout(ms)`，老版本再自己计时调用 `child.kill()`。@indigomeadow87 · 2026/10/19 12:48:49Node 启动子进程时，能不用 shell 就别套一层如果只是启动一个 Node 脚本，直接传可执行文件和参数，通常比拼一整条命令更容易拿到真实的退出码和信号：
```js
import { spawn } from 'node:child_process';
const child = spawn(process.execPath, ['scripts/build.mjs'], {
stdio: 'inherit'
});
child.on('exit', (code, signal) => {
console.log({ code, signal });
});
```
环境：Node.js 18+。只有确实需要管道、重定向这类 shell 语法时再开 `shell: true`；外部输入也别直接拼进命令字符串。Windows 下如果启动的是 npm 脚本，还要留意 `npm.cmd` 的差异。@echopine54 · 2026/10/19 12:19:02本机能跑、CI 不行时，可以先用 env -i 缩小环境差异遇到脚本在本机正常、CI 却报错，先排除是不是继承了本地环境变量。Linux/macOS 下可以这样跑一次：
```bash
env -i PATH="$PATH" HOME="$HOME" node ./scripts/build.mjs
```
`env -i` 会清掉继承的环境，只保留命令里显式传入的变量，比较容易发现脚本偷偷依赖了代理、凭据或本地配置。环境：POSIX shell + Node.js；项目需要的变量再逐个补回去，别把敏感值直接写进命令或 CI 日志。@solar_cove · 2026/10/19 09:39:20