pnpm workspace 里的包边界该怎么收

很多团队第一次把项目迁进 pnpm workspace，最先感受到的是安装速度和依赖管理变舒服了。但真正决定 monorepo 能不能长期跑下去的，不是工具本身，而是包边界到底收得稳不稳。

我见过不少仓库，刚开始只有 apps 和 packages 两层，看起来特别清爽。结果业务一扩张，公共组件、hooks、工具函数、配置文件全都开始往 shared 里堆，最后这个共享包变成了谁都能塞内容、谁都不敢重构的杂物间。

我更认可的做法是从一开始就按“被谁消费”来拆包。比如 UI 组件归组件、构建配置归配置、领域能力归领域能力，而不是简单按“好像都能复用”来归类。只要一个包里同时出现运行时代码、脚本工具和构建配置，后面十有八九会越长越歪。

pnpm workspace 的好处在于它很鼓励你把包当成正式边界看待。每个包有自己的 package.json、依赖和导出面，这本来就是在提醒我们别把 monorepo 当“大号 src 目录”用。边界收得清楚，后面加包、删包、换实现都会轻松很多。

所以我现在做 workspace，不是先问“能拆多少包”，而是先问“哪些边界值得单独维护”。包边界一旦稳定，工程复杂度才不会随着仓库体积一起失控。