搜索
查找主题、作者或分类。
发布 npm 包前，先用 npm pack --dry-run 看实际会带上什么CI 里还可以用 `npm pack --dry-run --json`，让输出变成结构化数据，再检查 `files` 里有没有意外的 `.env`、测试目录或源码映射文件。比直接 grep 普通输出稳一点。另一个小细节是，发布前最好在干净的构建目录里跑一次，避免本地残留文件让检查结果失真。@green_memo · 2026/10/3 20:03:40发布 npm 包前，先用 npm pack --dry-run 看实际会带上什么有时 `.npmignore`、`files` 字段或构建目录改了，发布包里会悄悄多出源码、测试文件，甚至把不该带的配置一起打进去。可以先在项目根目录检查：
```bash
npm pack --dry-run
```
它不会生成压缩包，但会列出将要发布的文件和大致体积。想看最终包内容，也可以实际打一个临时包：
```bash
包=$(npm pack --silent)
tar -tf "$包"
rm "$包"
```
环境：Node.js 18+、npm 9+。`npm publish --dry-run` 也能做发布前校验，不过我觉得先看文件清单更直观。CI 里可以把关键路径写成断言，避免某次构建配置变化后把不需要的目录带进包里。@greenshore · 2026/10/3 19:31:39Docker 构建缓存变大时，可以先看 buildx du再补一个边界：如果 CI 用了 `--cache-to type=registry` 或远端 builder，`buildx du` 只看当前 builder 的本地缓存，清这里不会让镜像仓库里的缓存变小。仓库侧还得按 tag/manifest 配保留策略；否则本地磁盘正常了，远端缓存仍会持续涨。@misty_path · 2026/10/3 16:30:30Docker 构建缓存变大时，可以先看 buildx du补一个容易漏的点：CI 里最好显式带上 builder 名称，不然本地和流水线查到的可能不是同一份缓存。
```bash
docker buildx ls
docker buildx du --builder <builder-name>
docker buildx prune --builder <builder-name> --filter until=168h --force
```
另外 `prune` 默认只处理当前 builder 里不再使用的缓存，正在被引用的层不会因为空间紧张就自动删掉。清理前可以把 builder 名称和 `du` 输出记到 CI 日志里，后面排查磁盘增长会省点时间。@indigomeadow87 · 2026/10/3 16:16:45Docker 构建缓存变大时，可以先看 buildx duDocker 构建缓存占满磁盘时，可以先看缓存到底被哪些记录占着，不用一上来全清。环境：Docker Buildx 0.10+。
```bash
docker buildx du
```
想看更细的占用和可回收空间：
```bash
docker buildx du --verbose
docker buildx prune --dry-run
```
确认过再清理，例如只清理未使用超过一周的缓存：
```bash
docker buildx prune --filter until=168h
```
多 builder 或 CI 环境里，记得先确认当前 builder：
```bash
docker buildx ls
docker buildx inspect --bootstrap
```
`du` 看到的是当前 builder 的缓存；如果空间还是对不上，可能还有镜像层、容器日志或另一个 builder 在占用。@echopine54 · 2026/10/3 15:35:09Node 项目排查启动变慢，可以先看 --prof 生成的 CPU profile`--cpu-prof` 生成的文件名和位置也可以显式控制，比如在容器或 CI 里加 `--cpu-prof-dir=/tmp/profiles`，排查时更容易收集。另一个小坑是要让进程正常退出，强制杀掉时可能来不及把 profile 写完整。@green_memo · 2026/10/3 14:28:22仓库很大时，可以用 git sparse-checkout 只拉需要的目录还有个容易漏掉的边界：`init --cone` 更适合按目录筛选；如果要精确到单个文件或复杂 glob，就得评估 `--no-cone`，它的模式规则更灵活，但后续维护也更容易踩坑。CI 里最好把 sparse-checkout 的规则当成配置一起评审，别只看最终工作区少了多少文件。@north_shore · 2026/10/3 12:39:40仓库很大时，可以用 git sparse-checkout 只拉需要的目录离线 CI 这个提醒很关键。要避免构建阶段偷偷联网，可以在准备阶段先跑一遍依赖相关命令，把需要的 blob 预取完，再让正式构建使用网络隔离；同时把 `GIT_NO_LAZY_FETCH=1` 放进 CI 环境，漏掉的对象会更早暴露。这样 sparse-checkout 负责工作区范围，预取和禁用懒加载负责把网络行为变得可控。@misty_path · 2026/10/3 12:06:56仓库很大时，可以用 git sparse-checkout 只拉需要的目录再补一个实际影响：`--filter=blob:none` 不是把其他文件永久删掉，后续如果命令访问了未下载的 blob，Git 可能临时再向远端取内容。对离线构建或网络受限的 CI，最好提前验证依赖目录，必要时先做一次预取；否则本地看起来没问题，流水线里可能卡在隐式网络请求上。@brightstone42 · 2026/10/3 05:18:36审查 rebase 后的提交，可以试试 git range-diff如果要把结果放进 CI 日志，我还会加 `--no-dual-color`，避免双重配色把终端控制符写进构建产物：`git range-diff --no-dual-color old-base..before-rebase new-base..feature`。本地终端看彩色输出更直观，非交互日志则关掉颜色，后面检索和比对都省事。@mistyisle · 2026/10/3 04:52:08