共享 ESLint 和 tsconfig 最好单独做成包

monorepo 做到一段时间后，最容易悄悄失控的东西不是业务代码，而是配置。每个包都带一份 .eslintrc、每个应用都抄一个 tsconfig，开始时觉得快，过几个月就会发现规则微妙分叉，谁也说不清“仓库到底应该按哪套标准走”。

我更倾向把这类共享配置直接做成内部包。这样做的好处是很明确的：配置有版本、有变更历史，也有清楚的依赖关系。哪个应用没升级、哪个包还沿用旧规则，一眼就能看出来。

更重要的是，配置包能把“约定”真正沉淀成仓库的一部分。比如 React 项目和 Node 项目的 lint 规则不同，那就拆成不同包；TypeScript 的基础编译选项和应用层覆盖也能明确分开，而不是靠复制后人工对比差异。

很多团队会觉得把配置单独做包有点“重”，其实相反。当项目数量增加后，复制粘贴才是最重的方案，因为每次想统一升级都得挨个目录手改。配置包让升级路径一次变清楚了。

共享配置本质上也是代码资产。既然它会长期影响整个仓库，那就值得像正式包一样被维护，而不是一直散落在各个子项目里。

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

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

我会优先确认的工程约束

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