fix(build-tools): prevent default ^* deps on subtasks of configured groups

[tylerbutler]

Summary

Named subtasks created by concurrently (e.g. check:exports:cjs:alpha from concurrently "npm:check:exports:*") receive the default after: ["^*"] dependency independently in finalizeDependentTasks, making them depend on all scheduled tasks in upstream dependency packages. This causes unrelated changes (like touching an eslint config) to invalidate downstream api-extractor check:exports:* tasks.

The root cause: finalizeDependentTasks iterates all tasks including concurrently subtasks directly, bypassing the isDefault guard in GroupTask.addDependentTasks that was designed to prevent this.

Code fix (buildGraph.ts, task.ts, groupTask.ts)

• Adds collectNamedSubTasks virtual method to Task (no-op) / GroupTask (yields named subtasks)
• Before finalizing tasks, precomputes two sets: subtasks of explicitly-configured groups and subtasks of default-config groups
• Skips default after processing for subtasks that appear only in explicit groups — they inherit the correct dependencies from their parent via initializeDependentLeafTasks
• Handles the edge case where a cached task is a subtask of multiple groups with different config types

Config workaround (fluidBuild.config.cjs)

Adds explicit ["api"] task definitions for all check:exports:* subtask names so the fix takes effect immediately without waiting for the code change to ship.

[tylerbutler]

This implies we are iterating over group tasks, but it looks like we are iterating over all tasks. More comments would be helpful.

[jason-ha]

If this workaround is kept, the specific api-extractor:commonjs|esnext tasks should be used to avoid cross cjs-esm dependencies.

[jason-ha]

This check:exports:index setting is not correct. That package does not have an "api" task. If I understand correctly, the transitive dependency on "api-extractor:esnext" becomes nothing because there is no "api-extractor:esnext" script entry.
A correction proposed in #26442. (The PR also addresses "check:exports:bundle-release-tags" that is only sometimes configured in packages.)

[jason-ha]

It feels like applying such a default should issue a warning if not an error.
I would love to get to a place where every interdependent task has those configured somewhere. Should be possible for policy checker to find these and make changes. (A fully automated understanding is great. We should get that understanding captured into dependency listings that are then human visible without asking the tooling what the deps are.)

[tylerbutler]

I agree in principle. I just don't think our build should be so complicated that we need such level of automated checks. When I investigated the latest problems, I was surprised at just how many invocations of api extractor we have and how complex some of the individual package builds are now. Seems like there's room for better guidance on adding build tasks. I also underestimated how much adding new tasks would be a thing folks needed to do often.

I wonder if a simple rule might help, like "if your package can't use the default tasks, then you have to define all its tasks directly in the package itself instead of inheriting some and not inheriting others." That is, if you have a fluid build entry in the package.json, it describes that package's build graph entirely. Then it is easier to reason about what a package's build graph looks like. It either looks like the default graph based on the tasks defined, or it has a custom config that is self contained but duplicative.

Ultimately, I think we should be constructing our tasks such that we can swap fluid-build for something else with little fuss. That's one reason I've been pushing for less code in fluid build and more config level task definitions and behavior. It's easier to map such things to systems like Nx.

If we reach a certain point of build complexity, I don't think a task oriented system will scale enough. I think we'll need to look at more formal build-output based systems like bazel.

But the biggest reason I want to get off of fluid build is that if we were on another system, there would ideally be docs that described the expected behavior and how to config to the way we want it, while now that answer is "ask Tyler or read the code if he doesn't know" (likely). :)

[tylerbutler]

I can put the behavior change to error here behind an env var and we can try it out.

[jason-ha]

We should be able to define the right incremental build pieces for whatever tooling. With api-extractor we either need to work to get the tool to do all we want in one command to ease burden on build system or have build system that is more piece agnostic. I don't have opinion on fluid-build versus others.
fluid-build seems sufficiently flexible. It seems like part of the problem is that it is smart enough that it keeps the build going for the most part even when the config is not correct. If it gave up more, then more explicit configs would be needed. Probably agents are up to the task of setting those with sufficient guidance. The debt of CSJ+ESM is still weighing on things and likely seems part of the reason agent didn't get things as good.

Without swapping to something else

• if we could define default deps for a name pattern like for "check:exports:cjs:" and "check:exports:esm:" then this would also have been easy.
• Note that the check:exports entries are mostly automated via policy checking. The checker could make sure there are build deps in place to avoid need for pattern or bunch of defaults in root config. I didn't try for that since it was reasonable to place the dep burden on the concurrency task. I think it worked right for a long while.

Sure, behind env or just try it out to see what is missing, if anything. If the error is clear an agent might be able to fix.

[jason-ha]

The suggestions below are equivalent to current code and I think clearer. I don't know if any version meets the intention noted in groupTask.ts‎.

Suggested change

	const config = this.getTaskDefinition(task.taskName);
	if (config !== undefined && !config.isDefault) {
	task.collectNamedSubTasks(subtasksOfExplicitGroups);
	} else if (config?.isDefault) {
	task.collectNamedSubTasks(subtasksOfDefaultGroups);
	}
	const config = this.getTaskDefinition(task.taskName);
	if (config !== undefined) {
	if (config.isDefault) {
	task.collectNamedSubTasks(subtasksOfDefaultGroups);
	} else {
	task.collectNamedSubTasks(subtasksOfExplicitGroups);
	}
	}

or even

Suggested change

	const config = this.getTaskDefinition(task.taskName);
	if (config !== undefined && !config.isDefault) {
	task.collectNamedSubTasks(subtasksOfExplicitGroups);
	} else if (config?.isDefault) {
	task.collectNamedSubTasks(subtasksOfDefaultGroups);
	}
	const config = this.getTaskDefinition(task.taskName);
	if (config !== undefined) {
	task.collectNamedSubTasks(config.isDefault ? subtasksOfDefaultGroups : subtasksOfExplicitGroups);
	}