touched projects concept as an alternative to affected

[dmitry-stepanenko]

When working on a specific feature in a large monorepo, it's often necessary to run test or lint commands only on the projects you've modified. Nx provides the nx affected -t <target> command for this purpose,. Although it does the job, in large repositories it can include hundreds of projects which is too much for a local machine.

From my experience, the highest likelihood of encountering issues comes from the projects I've directly modified rather than their dependencies. So it would be nice to be able to run only those projects without dependencies.

I created a small utility for personal use: https://gist.github.com/dmitry-stepanenko/af297def0340f091a05cd6be21a0532f . However, I believe this functionality should be natively supported in the Nx CLI in a first place.

There are a few ways this could be implemented in the CLI:

1. A separate command:
   • nx touched – Works similarly to nx affected but only includes directly modified projects.
2. A flag for nx affected:
   • nx affected --touched – Ignores dependencies and only runs commands on modified projects.
3. A more flexible depth-based approach:
   • nx affected --depth=<number> – Allows users to define how deep the dependency tree should be considered.
     • --depth=1 would include only touched projects.
     • Higher values would include dependent projects up to the specified depth.
     • This is similar to the "proximity" concept in the dep-graph.

[jogelin]

To expand on this discussion, I believe the entire affected feature should also be customizable.

For each customer I work with, I always need to modify Nx's behavior on CI by creating custom scripts to tweak the affected result or even patch Nx directly. I detailed some of these approaches in my article: Deep Dive into Nx Affected.

Nx already offers some customization options, such as the .nxignore file and the nx.json property projectsAffectedByDependencyUpdates. However, rather than relying solely on configurations or options, I would suggest introducing customizable hooks within the affected lifecycle—similar to how we define hooks for Nx plugins today.

This would provide a more flexible and extensible way to tailor the affected behavior to different use cases, reducing the need for workarounds and manual patching.