Nx ( https://nx.dev ) is a widely adopted monorepo build system for JavaScript/TypeScript (and increasingly polyglot) codebases. Teams standardizing on Nx rely on its project graph to run only the projects affected by a change, which keeps CI fast as the monorepo grows. Harness CI can approximate this today with generic building blocks (changed-file triggers, selective stage execution, JEXL conditional execution) plus a hand-written step that computes the base and head SHAs for nx affected . That works, but every team has to assemble and maintain the wiring themselves, and none of it understands Nx's dependency graph. What we'd like First-class, Nx-aware support in Harness CI so teams do not have to hand-build monorepo orchestration. Ideally some combination of: A native Nx step (or plugin) that resolves the correct base/head SHAs across push, PR, and merge events and exposes them as output variables, without depending on GitHub-specific context. Affected-graph-aware execution, so Harness can run only the pipeline stages/steps for the Nx projects impacted by a change, driven by nx affected / the Nx project graph. Nx coverage in Build Intelligence and Test Intelligence, so caching and test selection understand Nx targets the way they do for the currently supported ecosystems. Any meaningful step toward the above would help. A native step for the affected SHAs (item 1) is the most immediate unlock; graph-aware execution (item 2) is the larger prize. Why this matters Nx is being adopted or mandated across engineering orgs; teams migrating from GitHub Actions expect a comparable native experience in Harness CI. Assembling changed-file triggers, selective execution, and a custom SHA-resolver script per pipeline is boilerplate that each team rebuilds and maintains. Without graph awareness, "run only what changed" is path-based, not dependency-based, so it either over-builds (safe but slow) or risks missing transitively affected projects. Example A team runs nx affected --target=build,test in Harness CI. Today they add a Run step that computes NX_BASE/NX_HEAD from git and trigger payload values, wire a changed-file trigger, and enable selective stage execution. A native Nx step would compute the SHAs reliably out of the box, and graph-aware execution would run only the stages for the impacted Nx projects automatically. Today's workaround (and why it is not enough) Changed-file triggers + selective stage execution + JEXL conditions handle path-based "run only what changed," but do not understand the Nx project graph, so they cannot follow transitive dependencies. A custom Run step can compute NX_BASE/NX_HEAD for nx affected , but it is boilerplate each team must build and maintain, and the built-in trigger variables are not always populated, so it needs git fallbacks to be reliable.
