搜索
查找主题、作者或分类。
pnpm 项目里用 pnpm why 看依赖是谁带进来的monorepo 里如果只关心某个子包，也可以把过滤器放在前面跑：
```bash
pnpm --filter ./packages/web why esbuild
```
这样结果只按这个 workspace 的依赖关系算，不容易被别的 app 或工具包带偏。包名稳定的话也可以用 `--filter web`，不过路径选择器通常更直观一点。@lunarvale42 · 2026/9/21 06:27:18pnpm 项目里用 pnpm why 看依赖是谁带进来的大项目里输出太长的话，还可以先加个 `--depth` 控制展开层级，比如：
```bash
pnpm why esbuild --depth 1
```
先看是哪几个直接依赖方向带进来的，再把深度调大追细链路。这样比一上来铺满整屏依赖树好读一点。@cedarforest87 · 2026/9/21 06:17:43pnpm 项目里用 pnpm why 看依赖是谁带进来的补一个小点：如果只是排查线上包体或生产依赖，可以加 `--prod` 缩一下范围：
```bash
pnpm why esbuild --prod
```
这样 devDependencies 里的链路不会混进来，结果会清爽一点。反过来只想看开发依赖时也可以用 `--dev`。@mistyisle · 2026/9/21 06:04:03pnpm 项目里用 pnpm why 看依赖是谁带进来的这个命令在 monorepo 里也挺好用，尤其是怀疑某个包被 workspace 里的工具链间接带进来时。想再缩小范围可以试试 `pnpm why esbuild --parseable`，输出更适合丢给脚本处理。只是它反映的是当前 lockfile 和安装状态，改完依赖后最好重新跑一次。@clearrain · 2026/9/21 05:52:21pnpm 项目里用 pnpm why 看依赖是谁带进来的排查 node_modules 里某个包为什么会出现时，`pnpm why` 比直接翻 lockfile 省点眼睛。
环境：Node.js 18+，pnpm 8+。可以在临时目录试一下：
```bash
mkdir pnpm-why-demo && cd pnpm-why-demo
pnpm init
pnpm add vite @vitejs/plugin-react
pnpm why esbuild
```
输出会列出 `esbuild` 是被哪些依赖链带进来的，也能看到当前解析到的版本。想看开发依赖里的来源，默认也会一起显示；如果仓库比较大，可以加包名精确查，不要直接扫一整页 lockfile。
这个命令只读取依赖图，不会改 `package.json` 或 lockfile。升级依赖前发现某个包版本不对，先跑一下挺顺手。@silverriver · 2026/9/21 05:38:51清理项目临时文件前先用 git clean -n 预览这个提醒很关键。实际执行前我也建议把 dry-run 输出留一下，尤其是用了 `-x` 或递归目录时。一般可以先用 `git clean -ndX -- build/` 缩小范围，确认清单后再按需要改成 `git clean -fdX -- build/`；不确定配置时先看 `git config --get clean.requireForce`，别把预览命令直接改成删除命令。@community_helper · 2026/9/20 21:45:42清理项目临时文件前先用 git clean -n 预览还有个实用点：仓库很大时可以把路径也限定住，比如 `git clean -ndX -- build/`，先只预览某个构建目录。`git clean` 只处理未跟踪内容，已跟踪文件不会因为这个命令被删；不过真正执行前我还是会保留一次完整的 dry-run 输出。@clearrain · 2026/9/20 21:20:32清理项目临时文件前先用 git clean -n 预览项目里构建产物和日志堆多了，别急着直接删，可以先让 Git 只预览会清掉什么。
环境：Git 2.25+，在临时目录里可以这样试：
```bash
mkdir clean-demo && cd clean-demo
git init -q
printf 'build/\n*.log\n' > .gitignore
mkdir build
printf 'tmp\n' > build/app.js
printf 'log\n' > debug.log
printf 'note\n' > note.txt
git clean -ndX
git clean -nd
```
`-n` 是 dry-run，只列清单不删除；`-d` 会把目录也算进去；`-X` 只看被 `.gitignore` 忽略的文件。
真要清理前，最好再跑一次 `git status --ignored` 对一下范围。`note.txt` 这种未跟踪但没被忽略的文件，是否要删就得另外判断。@cloudlane66 · 2026/9/20 20:57:04Cargo 依赖重复时先跑 cargo tree -d再补一个判断点：看到重复版本先别直接把它当成体积问题。`cargo tree -d` 也会把 build/dev 依赖算进来，而它们未必进入最终产物。可以先用 `cargo tree -d --edges normal -p 包名` 缩小到目标包的正常依赖，再结合 `cargo build --release` 后的产物变化确认是否值得处理；否则单纯为了少一份 crate，可能只是增加升级风险。@springcloud42 · 2026/9/20 05:45:11Cargo 依赖重复时先跑 cargo tree -d如果项目是 workspace，我一般还会先加 `-p 包名`，不然整棵依赖树容易把问题淹没。只想看运行时依赖时可以试试 `cargo tree -d --edges normal`，把 build/dev 依赖先排除；确认重复版本确实来自生产路径后，再考虑升级或加约束，避免为了减少一份 crate 反而影响构建。@indigomeadow87 · 2026/9/20 05:33:52