pnpm filter 递归命令在 monorepo 里的实践

当仓库开始拆成多个应用和共享包之后，很多命令如果还按单仓库思路跑，就会越来越笨重。一次改了前端页面，却要把整个 monorepo 的所有包都 lint、test、build 一遍，这种开销很快就会把研发节奏拖慢。

我觉得 pnpm 最实用的一点，就是它提供了比较顺手的 filter 机制。你可以只对某个应用、某个包，甚至某个包及其依赖链执行命令，而不需要人为维护一堆脚本别名。对于本地开发和 CI，这个收益都很明显。

真正有价值的不是命令写法本身，而是它帮你建立了一个更贴近影响范围的执行习惯。改动只影响后台服务，就没必要连组件库的构建也一起跑；只改了共享包，就应该把依赖它的应用顺带拉上验证，而不是拍脑袋猜有没有影响。

我一般会把常用命令沉淀成几个固定用法，比如针对单包测试、依赖链构建、某个应用的局部 lint。这样团队成员不用每次都重新研究命令组合，也更容易把命令逻辑放进 CI 流程里。

pnpm filter 的意义，不是语法更花，而是它让 monorepo 的执行范围终于有了“按影响面运行”的能力。仓库越大，这种能力越值钱。

工具链问题真正影响的是团队节奏，而不只是命令能不能跑

像「pnpm filter 递归命令在 monorepo 里的实践」这样的工程化主题，很容易在早期被当成“开发者自己适应一下就好”。但只要它进入 monorepo、CI、镜像构建或多环境协作场景，问题就不再是单机体验，而是整个团队的交付节奏。一个看起来只是配置细节的决定，后面往往会变成缓存命中率、构建稳定性、版本兼容和排查效率的差异。

我会优先确认的工程约束

• 先验证这套工具在本地、CI 和生产镜像里是否拥有一致行为，别让“我电脑上能跑”变成默认前提。
• 把锁文件、缓存目录、类型入口和构建产物边界写清楚，避免升级一次就把下游一起拖进不确定状态。
• 如果某个新工具的收益主要停留在启动更快，而迁移和排错成本已经明显抬升，就说明采用边界需要收窄。