Nx 单体仓库工作流编排器

要解决的实际问题

在单体仓库里，当改动发生在 libs/ 下的某个共享包时，团队往往很难快速判断：这次变更会影响到哪些下游应用，应该重新运行哪些任务，哪些构建可以安全跳过。手动梳理包间引用关系不仅耗时，还容易遗漏。当项目数量达到几十个、CI 资源有限时，全量执行任务的成本会迅速攀升，等待时间也会拖慢反馈循环。

核心能力与工作方式

这个技能面向 Nx 工作区，主要围绕 nx.json 中的配置和 @nrwl/devkit 提供的执行器来编排任务。它的核心能力可以拆解为三层：

• 依赖图分析：基于 Nx 内置的项目依赖关系，在运行时解析目标与目标之间的引用，形成可用于调度的图结构。
• 受影响项目检测：利用 Nx 的变更影响计算，只筛选出因源码变化而真正受影响的项目，避免无意义的重复执行。
• 分布式任务执行：结合 Nx Cloud 进行远程缓存和任务分发，把可以并行的工作拆到多台机器上执行，缩短整体耗时。

实际使用中，技能先读取工作区的配置，判断当前仓库使用的是 npm、pnpm 还是 yarn，然后沿着已有的依赖关系确定需要运行的目标范围，最后通过 Nx Cloud 提交并接收执行结果。npx nx init 这类增量初始化步骤会复用现有的 package.json scripts，缓存其输出，只在受影响范围内运行必要任务，不需要对现有配置做侵入式修改。

适用边界与注意点

• 这个技能适合已经采用 Nx 作为构建系统的单体仓库，尤其是希望用影响面分析来替代全量构建的场景。
• 任务分发和远程缓存依赖 Nx Cloud，因此网络访问和云端授权会影响完整能力的发挥。
• 初始化阶段的设计偏增量，团队通常不需要推翻已有的脚本约定，但任何超出 Nx 当前支持范围的自定义调度逻辑仍需要自行扩展。