Skip phantom entry targets in subgraph when enablePhantomTargetOptimization is enabled

[christiango]

Summary

Extends the existing phantom target optimization to also filter out phantom entry targets during subgraph construction. Previously, enablePhantomTargetOptimization only skipped phantom targets during ^/^^ dependency expansion in expandDepSpecs. This left a gap: when running a task that only some packages define or that explicitly opts out via shouldRun, every package still got added as a subgraph entry point, pulling in their same-package dependencies unnecessarily.

Problem

When running a task like test:commandScript that only a single package defines, lage creates entry targets for all packages in scope. Each phantom entry target's same-package dependency on bundle pulls that expensive bundle task into the subgraph. In a ~200 package monorepo, this inflated the target graph from ~91 targets to ~366 — including multiple 6GB+ bundle tasks that had no work to do.

The same problem applies to non-npmScript targets (e.g. worker type) that define a shouldRun callback returning false — they still got added as entry points, dragging in their dependency trees.

Fix

In WorkspaceTargetGraphBuilder.build(), when enablePhantomTargetOptimization is true, skip adding a package to subGraphEntries if:

1. The target's shouldRun resolved to false (covers worker, noop, and any target type with a shouldRun callback), or
2. The target is an npmScript type and the package doesn't define the task in its package.json scripts (existing phantom target check, now also applied at entry selection)

To support this, shouldRun resolution is moved earlier in build() — before entry filtering instead of after subgraph construction. To minimize overhead:

• Only entry-candidate targets (scope × tasks) are resolved, not all targets
• Targets without a shouldRun callback are set synchronously to true with no promise overhead
• Async callbacks are batched through pLimit(8)

All downstream consumers already handle shouldRun: undefined correctly via ?? true or === false checks, so non-entry targets that don't get resolved are unaffected.

Risk

• Gated behind enablePhantomTargetOptimization (defaults to false), so no behavior change for existing consumers.
• expandDepSpecs and isPhantomTarget are completely untouched — dependency expansion logic is unchanged.
• Only affects entry target selection in WorkspaceTargetGraphBuilder.build().

Testing

• Two new unit tests: one verifying worker targets are excluded when shouldRun returns false, one verifying worker targets without shouldRun are still included.
• Validated in a large monorepo: target count for a single-package task dropped from 366 → 91, eliminating all phantom bundle targets.

[christiango]

I need to test something, going to move to draft

[christiango]

This is too aggressive. We need to make sure it's an npm script when we do this

[christiango]

I'm going to simplify this

[ecraig12345]

For worker runners, this has the side effect of resolving and loading the script module, which could be expensive (though I guess it would be cached after the first load). So I wonder if it's better to just ignore non-npmScript targets for the phantom target check here, similar to the other check in expandDepSpecs?

[christiango]

So for our case we actually need it to filter out workers as well. I couldn't find any evidence of this triggering the worker script module, the intent is only to look at the worker config's should run (confusing that both places have a should run). I believe the worker still isn't loaded until the runner phase

[christiango]

My tests show this as well, if I comment out the target config should run here, the test fails and the task is in the build graph

builder.addTargetConfig("test:special", {
  type: "worker",
  dependsOn: ["bundle"],
  //shouldRun: async (target) => Promise.resolve(target.packageName === "tool-app"),
});

[christiango]

As a further sanity check I did the following, I made the worker script in the repo throw on the first line and I added a console log statement before the this.hasRoottarget check on line 255. Here was the output, showing the worker is not loaded with this change:

This is when we finished processing the targets
Error: This is when the worker was loaded

[ecraig12345]

This is where it loads the script in shouldRun:

lage/packages/runners/src/WorkerRunner.ts

Lines 68 to 72 in d386157

	public async shouldRun(target: Target): Promise<boolean> {
	const scriptModule = await this.getScriptModule(target);
	if (typeof scriptModule.shouldRun === "function") {
	return (await scriptModule.shouldRun(target)) && (target.shouldRun ?? true);

[christiango]

This is not the one I am checking , confusingly there’s also one in the config as well that gets read before the script. The test that skips when should run is false is implementing it at the config level, not the runner level

[christiango]

In the test it’s defined in parallel to depends on in the config