feat(core): add support for tags with (print-)affected(:*) and run-many

[fguitton]

⚠️ Edit: The behaviour of this pull request has changed to address feedbacks. See #10085 (comment) for more information

Current Behavior

When running the (print-)affected(:*) command you get all affected projects for a target.
With the run-many command filtering is only possible with --projects.
Both accept a --all, it being warned for in affected.

Expected Behavior

We would expect to be able to select projects by tags.

This PR

This could be seen as a first step only acting to select projects in the same way --projects does it for run-many. Tags are not applied in compound but rather as OR statement in comma separated fashion.

That is in the example below the command would select projects that either contain the tag sdk or the tag app, not necessarily projects containing both tags.

nx affected --tags=sdk,app --target=test

Related Issue(s)

This relates to very long standing #1621, #2675 or #8292 and a Nx v14 compatible treatment while being different from #8364 which attempts to support globs but does not address run-many.

Closes #1621
Closes #2675

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 3410cfc. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this branch

---

✅ Successfully ran 11 targets

• nx affected --target=e2e --base=3653e5944da44dd9df50488f33ff818c2832d161 --head=3410cfc0430b138e5e6b151d419e1dc9b8a3bce0 --exclude=e2e-storybook,e2e-storybook-angular,e2e-react-native,e2e-detox --parallel=1
• nx affected --target=test --base=3653e5944da44dd9df50488f33ff818c2832d161 --head=3410cfc0430b138e5e6b151d419e1dc9b8a3bce0 --parallel=1
• nx affected --target=build --base=3653e5944da44dd9df50488f33ff818c2832d161 --head=3410cfc0430b138e5e6b151d419e1dc9b8a3bce0 --parallel=3
• nx depcheck --no-dte
• nx affected --target=lint --base=3653e5944da44dd9df50488f33ff818c2832d161 --head=3410cfc0430b138e5e6b151d419e1dc9b8a3bce0 --parallel=3
• nx lint --no-dte
• nx check-lock-files --no-dte
• nx check-commit --no-dte
• nx-cloud record -- nx format:check --base=3653e5944da44dd9df50488f33ff818c2832d161 --head=3410cfc0430b138e5e6b151d419e1dc9b8a3bce0
• nx check-imports --no-dte
• nx documentation --no-dte

---

Sent with 💌 from NxCloud.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
nx-dev	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 6, 2023 6:30pm

[fguitton]

Hello @vsavkin !
I know you had interest in looking at this over the past few years.
It is the second PR opened for this feature but it addressed things slightly differently.
I am happy to bring any changes required, any feedback/direction is most welcome
We have a lot of need for this in our company.

Thank you for your help and valuable time 🙏🏼 !

[gioragutt]

Any update on this? I would love to use it 😁 Also, I thought it might be worth adding this to print-affected as well

[fguitton]

I thought it might be worth adding this to print-affected as well

Hello ! The print-affected command should already work out of the box with the changes proposed at it is considered a special branch of the affected command and the project filtering gets done upstream of that.

nx/packages/nx/src/command-line/affected.ts

Line 37 in 7f5137d

const projects = projectsToRun(nxArgs, projectGraph);

nx/packages/nx/src/command-line/affected.ts

Lines 79 to 113 in 7f5137d

	case 'print-affected':
	if (nxArgs.target) {
	const projectsWithTarget = allProjectsWithTarget(projects, nxArgs);
	await printAffected(
	projectsWithTarget,
	projects,
	projectGraph,
	env,
	nxArgs,
	overrides
	);
	} else {
	await printAffected(
	[],
	projects,
	projectGraph,
	env,
	nxArgs,
	overrides
	);
	}
	break;
	case 'affected': {
	const projectsWithTarget = allProjectsWithTarget(projects, nxArgs);
	await runCommand(
	projectsWithTarget,
	projectGraph,
	env,
	nxArgs,
	overrides,
	null
	);
	break;
	}

I can imagine there is latent question with regard to the use/semantic of --exclude which only applies to project names. I do not necessarily have a set opinion on this. In effect a tag filtering can very much replace the use of --exclude.

[yharaskrik]

Would love to see this merged into Nx and my PR closed.

[epechuzal]

This would be a big QoL feature for us, would love to see this in the next release! Any indications when that might be?

[FrozenPandaz]

future: I think we should consider caching the tags which match a pattern.

Because projects usually share the same tag, there's no point in matching the pattern with the same tag over and over.

[AgentEnder]

Yeah, I'll look at this in the future

[fguitton]

Thank you @AgentEnder ! Extending to the whole Nx team of course ! Thrilled to see this merged 🎉

[gioragutt]

Congrats @fguitton, you've put a lot of work on this and it shows! Thank you for all your effort, I'm sure it'll bring immense value to a lot of people 🙏🏻🙏🏻🙏🏻

[github-actions]

This pull request has already been merged/closed. If you experience issues related to these changes, please open a new issue referencing this pull request.