Walkthrough

This PR fixes topological ordering for --filtered recursive commands when selected projects connect only through unselected intermediaries. It adds sortFilteredProjects (TypeScript) and equivalent Rust helpers, propagates prod-pruned graph data through config/filter APIs, wires new inputs into run, exec, rebuild, pack, and publish, and mirrors the fix in the Pacquet CLI's recursive selection and sorting logic.

Changes

Workspace ordering fix

Estimated code review effort: 4 (Complex) | ~60 minutes

Sequence Diagram(s)

sequenceDiagram
  participant CLI as pnpm run --filter
  participant Filter as filterProjectsBySelectorObjects
  participant Context as ConfigContext
  participant Recursive as runRecursive
  participant Sorter as sortFilteredProjects

  CLI->>Filter: apply --filter / --filter-prod selectors
  Filter-->>Context: selectedProjectsGraph, allProjectsGraph, prodAllProjectsGraph, prodOnlySelectedProjectDirs
  Context-->>Recursive: opts with graph fields
  Recursive->>Sorter: sortFilteredProjects(opts)
  Sorter->>Sorter: tunnel through unselected/prod-pruned graph
  Sorter-->>Recursive: ordered chunks respecting transitive deps
  Recursive-->>CLI: execute chunks in dependency order

Assessment against linked issues

Possibly related PRs

• pnpm/pnpm#12093: Both PRs modify pacquet's recursive run implementation's chunking/resume logic in the same file.
• pnpm/pnpm#12299: Both PRs edit recursivePublish.ts's chunk computation and PublishRecursiveOpts, with overlapping implementation.
• pnpm/pnpm#12712: Both PRs modify pacquet's recursive.rs and related run/exec/pack paths for filter-driven project selection.

Suggested labels: product: pnpm@11, product: pacquet

Suggested reviewers: zkochan, KSXGitHub

• X
• Mastodon
• Reddit
• LinkedIn

• Fix recursive command sorting to respect transitive deps through unselected workspace projects.
• Preserve --filter-prod dev-dep pruning when resolving order, including mixed filter selections.
• Add unit/integration tests for filtered topo ordering and prod-graph metadata plumbing.

graph TD
A["pnpm CLI main"] --> B["projects-filter"] --> C["ConfigContext graphs"] --> D["recursive runners"] --> F["sortFilteredProjects"] --> G["graphSequencer"]
B --> H["prodAllProjectsGraph"] --> C
D --> E{"Pick graph per project"} --> F

Loading

The following are alternative approaches to this PR:

1. Expand selection subgraph to include intermediary nodes for sorting only

• ➕ Reuses existing sortProjects/sequenceGraph without special tunneling logic
• ➕ Cycle detection and ordering naturally reflect the full path structure
• ➖ Intermediates can increase node count and reduce concurrency if treated as schedulable work
• ➖ Harder to preserve prod-only pruning semantics per root without careful graph partitioning

2. Precompute condensed selected-to-selected edges (transitive closure) once

• ➕ Makes sorting a simple run over a smaller condensed graph
• ➕ Could be reused across multiple commands in the same invocation
• ➖ Computing closure can be more expensive on large workspaces than on-demand DFS
• ➖ Still must respect per-root graph choice (full vs prod-pruned) in mixed selections

Recommendation: The PR’s approach (per-selected-project DFS that tunnels through unselected nodes, while sourcing the root’s direct edges from the selected graph) is the best fit: it fixes transitive ordering, preserves concurrency for independent projects, and keeps prod-only pruning intact (including mixed --filter/--filter-prod selections) without needing to expand the runnable set or compute a full transitive closure.

Enhancement (3) +13 / -4

Config.tsAdd prod graph metadata to ConfigContext +9/-0

Add prod graph metadata to ConfigContext

• Adds prodAllProjectsGraph and prodOnlySelectedProjectDirs to ConfigContext with documentation. This allows command handlers to distinguish regular vs prod-only filtered selections when sorting.

pnpm11/config/reader/src/Config.ts

index.tsInclude prod graph metadata when constructing ConfigContext +2/-2

Include prod graph metadata when constructing ConfigContext

• Threads prodAllProjectsGraph and prodOnlySelectedProjectDirs from the computed pnpmConfig into the returned context object. Ensures downstream commands can access the additional graph data.

pnpm11/config/reader/src/index.ts

filterProjectsFromDir.tsReturn prod graph metadata from filterProjectsBySelectorObjectsFromDir +2/-2

Return prod graph metadata from filterProjectsBySelectorObjectsFromDir

• Extends the directory-based filtering helper to return prodAllProjectsGraph and prodOnlySelectedProjectDirs. This surfaces prod-only selection details to the CLI entrypoint.

pnpm11/workspace/projects-filter/src/filterProjectsFromDir.ts

Bug fix (9) +147 / -28

rebuild.tsPlumb full/prod graph context into rebuild command opts +3/-0

Plumb full/prod graph context into rebuild command opts

• Extends RebuildCommandOpts to include allProjectsGraph, prodAllProjectsGraph, and prodOnlySelectedProjectDirs. Enables recursive rebuild sorting to resolve transitive dependencies correctly under filtering.

pnpm11/building/commands/src/build/rebuild.ts

recursive.tsUse sortFilteredProjects for recursive rebuild chunking +3/-3

Use sortFilteredProjects for recursive rebuild chunking

• Replaces sortProjects(selectedProjectsGraph) with sortFilteredProjects(opts). Passes through optional full/prod graph context so ordering can tunnel through unselected intermediates while preserving prod-only pruning.

pnpm11/building/commands/src/build/recursive.ts

exec.tsUse sortFilteredProjects for recursive exec ordering +3/-3

Use sortFilteredProjects for recursive exec ordering

• Switches recursive exec ordering from sortProjects(selectedProjectsGraph) to sortFilteredProjects(opts). Expands ExecOpts to accept full/prod graph metadata required for correct filtered ordering.

pnpm11/exec/commands/src/exec.ts

runRecursive.tsUse sortFilteredProjects for recursive run ordering +3/-3

Use sortFilteredProjects for recursive run ordering

• Updates recursive run chunking to use sortFilteredProjects(opts) so filtered selections preserve transitive dependency order. Accepts full/prod graph metadata via options for mixed filter behavior.

pnpm11/exec/commands/src/runRecursive.ts

main.tsExpose prod graph metadata in CLI context +2/-0

Expose prod graph metadata in CLI context

• Stores prodAllProjectsGraph and prodOnlySelectedProjectDirs from filter results into the runtime context. This makes the metadata available to recursive command handlers.

pnpm11/pnpm/src/main.ts

pack.tsUse sortFilteredProjects for recursive pack ordering +10/-2

Use sortFilteredProjects for recursive pack ordering

• Replaces sortProjects with sortFilteredProjects when packing recursively. Passes selected graph plus optional full/prod graphs and prod-only selection dirs for correct ordering.

pnpm11/releasing/commands/src/publish/pack.ts

recursivePublish.tsUse sortFilteredProjects for recursive publish ordering +5/-2

Use sortFilteredProjects for recursive publish ordering

• Switches recursive publish chunk computation to sortFilteredProjects(opts). Extends options type to accept full/prod graph metadata to preserve correct ordering under filtered selections.

pnpm11/releasing/commands/src/publish/recursivePublish.ts

index.tsCompute and return prod graph + prod-only selection dirs +22/-2

Compute and return prod graph + prod-only selection dirs

• Builds a prod-pruned full graph (ignoreDevDeps) for prod-only selectors and returns it as prodAllProjectsGraph. Computes prodOnlySelectedProjectDirs as projects selected only via prod-only filters (not also regular filters), enabling per-project graph choice during sorting.

pnpm11/workspace/projects-filter/src/index.ts

index.tsResolve transitive deps for filtered sorts (full/prod graphs) +96/-13

Resolve transitive deps for filtered sorts (full/prod graphs)

• Enhances sequenceGraph/sortProjects to optionally resolve dependencies through a separate fullProjectsGraph, tunneling through unselected nodes to preserve transitive ordering among selected projects. Adds sortFilteredProjects which chooses per-project traversal graph (full vs prod-pruned) based on prodOnlySelectedProjectDirs, while respecting any edges pruned from the selected graph.

pnpm11/workspace/projects-sorter/src/index.ts

Tests (3) +407 / -1

runRecursive.tsAdd integration tests for filtered transitive ordering +218/-0

Add integration tests for filtered transitive ordering

• Adds recursive-run tests covering: (1) transitive deps via unselected intermediates, (2) prod-only filter ordering via prod graph, and (3) mixed regular/prod-only selection behavior. Uses workspace:* deps to ensure local linking under default settings.

pnpm11/exec/commands/test/runRecursive.ts

index.tsTest prod graph metadata for mixed filters +42/-1

Test prod graph metadata for mixed filters

• Adds a unit test verifying that mixed regular and prod-only selectors return prodAllProjectsGraph and prodOnlySelectedProjectDirs. Confirms selectedProjectsGraph merges correctly and that prod edges are preserved in the prod graph.

pnpm11/workspace/projects-filter/test/index.ts

index.tsAdd unit tests for transitive edge resolution and mixed prod behavior +147/-0

Add unit tests for transitive edge resolution and mixed prod behavior

• Introduces a Jest test suite covering transitive ordering through unselected nodes, preserved concurrency for independent projects, non-reintroduction of pruned edges, mixed regular/prod-only graph selection, and cycle detection through unselected projects.

pnpm11/workspace/projects-sorter/test/index.ts

Documentation (1) +11 / -0

sort-filtered-transitive-deps.mdAdd changeset for filtered topo-order fix +11/-0

Add changeset for filtered topo-order fix

• Introduces a patch changeset for multiple packages, documenting corrected ordering for filtered recursive commands. Notes correct behavior for both regular and prod-only filters, including mixed selections.

.changeset/sort-filtered-transitive-deps.md

Other (3) +26 / -3

pnpm-lock.yamlAdd Jest globals to workspace.projects-sorter dev deps +3/-0

Add Jest globals to workspace.projects-sorter dev deps

• Updates the lockfile to include @jest/globals for the projects-sorter package. Supports newly added Jest-based unit tests.

pnpm-lock.yaml

package.jsonEnable Jest tests in projects-sorter package +5/-3

Enable Jest tests in projects-sorter package

• Expands lint to include test sources, updates test script to run Jest, and adds a dedicated .test command with Node VM module flags. Adds @jest/globals as a devDependency.

pnpm11/workspace/projects-sorter/package.json

tsconfig.jsonAdd test tsconfig for projects-sorter Jest suite +18/-0

Add test tsconfig for projects-sorter Jest suite

• Adds a dedicated tsconfig for compiling/running sorter tests with an explicit outDir and isolatedModules. Includes repo typings and references the package tsconfig.

pnpm11/workspace/projects-sorter/test/tsconfig.json

Description

The new workspace.projects-sorter .test script sets NODE_OPTIONS using POSIX $NODE_OPTIONS
expansion, which is not expanded by Windows cmd.exe, so Node can receive a literal $NODE_OPTIONS
token and fail before running Jest. This can break the repo’s Windows test jobs when this package’s
tests run.

Code

pnpm11/workspace/projects-sorter/package.json[31]

+    ".test": "cross-env NODE_OPTIONS=\"$NODE_OPTIONS --experimental-vm-modules --disable-warning=ExperimentalWarning --disable-warning=DEP0169\" jest"

Evidence

The .test script embeds $NODE_OPTIONS in the value passed to cross-env, which relies on POSIX
shell expansion and is not expanded by Windows cmd.exe. The repo runs a dedicated Windows test
matrix (windows-latest) and executes the test script in CI, so this script can fail on Windows and
break CI.

pnpm11/workspace/projects-sorter/package.json[26-33]
.github/workflows/ci.yml[115-190]
.github/workflows/test.yml[171-196]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`pnpm11/workspace/projects-sorter/package.json` defines a `.test` script that attempts to append to `NODE_OPTIONS` via POSIX `$NODE_OPTIONS` expansion. On Windows (where pnpm runs scripts through `cmd.exe` by default), `$NODE_OPTIONS` is not expanded, so the environment variable value can start with the literal string `$NODE_OPTIONS`, causing Node to error (invalid NODE_OPTIONS) and Jest to never start.
### Issue Context
The repository executes test shards on `windows-latest`, so this can break CI for PRs that touch this package.
### Fix
Avoid shell-dependent variable expansion in package scripts. For example:
- Set `NODE_OPTIONS` directly without referencing the prior value:
- `cross-env NODE_OPTIONS="--experimental-vm-modules --disable-warning=ExperimentalWarning --disable-warning=DEP0169" jest`
(If preserving existing `NODE_OPTIONS` is required, use a platform-neutral wrapper that concatenates `process.env.NODE_OPTIONS` in Node before invoking Jest.)
### Fix Focus Areas
- pnpm11/workspace/projects-sorter/package.json[26-33]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

sequenceGraph() topologically sequences only Object.keys(projectsGraph) (the selected/filtered
graph) and not the complete workspace graph before filtering. This violates the requirement to
compute order from the full graph first, which can lead to ordering semantics diverging from a true
full-graph topological order under --filter.

Code

pnpm11/workspace/projects-sorter/src/index.ts[R19-27]

+  const sortedProjectDirs = Object.keys(projectsGraph) as ProjectRootDir[]
+  const sorted = new Set(sortedProjectDirs)
+  const graph = new Map<ProjectRootDir, ProjectRootDir[]>(
+    sortedProjectDirs.map((projectDir) => [
+      projectDir,
+      sortedDependencies(fullProjectsGraph, projectDir, sorted),
+    ])
)
-  return graphSequencer(graph, keys)
+  return graphSequencer(graph, sortedProjectDirs)

Evidence

PR Compliance ID 2 requires computing the execution order from the complete workspace graph before
applying --filter. The updated sequenceGraph() derives the node set from projectsGraph
(selected graph) and calls graphSequencer() only on those nodes, even when a fullProjectsGraph
is available, so it is not ordering the full workspace graph first and then filtering.

Compute execution order using the full workspace graph before applying --filter selection
pnpm11/workspace/projects-sorter/src/index.ts[19-27]
pnpm11/workspace/projects-sorter/src/index.ts[30-35]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The compliance requirement expects recursive execution order to be derived by topologically ordering the complete workspace dependency graph first, and only then filtering to selected projects. The current implementation instead builds a new graph over only the selected projects (`Object.keys(projectsGraph)`) and sequences that.
## Issue Context
This impacts the contract for `--filter`ed recursive commands: the relative order should come from the full workspace topological order, with filtering applied afterward.
## Fix Focus Areas
- pnpm11/workspace/projects-sorter/src/index.ts[15-35]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

sortedDependencies() seeds traversal from fullProjectsGraph[projectDir].dependencies, so when
callers pass allProjectsGraph it can reintroduce devDependency-based ordering even if
selectedProjectsGraph was constructed with ignoreDevDeps (e.g. --filter-prod). This can
unexpectedly serialize or reorder recursive command execution based on dev-only relationships,
diverging from the dependency semantics used to build the selected graph.

Code

pnpm11/workspace/projects-sorter/src/index.ts[R48-60]

+  const dependencies = new Set<ProjectRootDir>()
+  const visited = new Set<ProjectRootDir>()
+  const stack = [...(fullProjectsGraph[projectDir]?.dependencies ?? [])]
+  while (stack.length > 0) {
+    const dependencyDir = stack.pop()!
+    if (dependencyDir === projectDir || visited.has(dependencyDir)) continue
+    visited.add(dependencyDir)
+    if (sorted.has(dependencyDir)) {
+      dependencies.add(dependencyDir)
+    } else {
+      const transitiveDeps = fullProjectsGraph[dependencyDir]?.dependencies
+      if (transitiveDeps) stack.push(...transitiveDeps)
+    }

Evidence

Workspace filtering builds a prod-only graph (ignoreDevDeps: true) for prod selectors but still
returns allProjectsGraph from a graph built without ignoreDevDeps, and recursive runners pass
that allProjectsGraph to sortProjects(). The sorter then reads dependencies from the full graph,
which (by construction) includes devDependencies unless ignoreDevDeps is set, so dev-only edges
can affect ordering.

pnpm11/workspace/projects-sorter/src/index.ts[15-35]
pnpm11/workspace/projects-sorter/src/index.ts[43-60]
pnpm11/workspace/projects-filter/src/index.ts[107-147]
pnpm11/workspace/projects-graph/src/index.ts[37-43]
pnpm11/exec/commands/src/runRecursive.ts[58-61]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`sortedDependencies()` currently uses `fullProjectsGraph[projectDir]?.dependencies` as the starting point for dependency discovery. If `fullProjectsGraph` includes devDependencies, those edges can influence ordering even when `projectsGraph` (the selected graph) was built with prod-only semantics (via `ignoreDevDeps: true`).
## Issue Context
In workspace filtering, `selectedProjectsGraph` for `followProdDepsOnly` selectors is built from a graph created with `ignoreDevDeps: true`, but `allProjectsGraph` is still returned from a graph created without `ignoreDevDeps`. Recursive runners now pass `allProjectsGraph` into `sortProjects()`, which makes the sorter use the full (dev-including) graph for ordering.
## Fix Focus Areas
- pnpm11/workspace/projects-sorter/src/index.ts[15-62]
- pnpm11/workspace/projects-filter/src/index.ts[107-145]
- pnpm11/workspace/projects-graph/src/index.ts[37-43]
## Suggested fix approach
1. Ensure the sorter does not “override” the dependency semantics of `projectsGraph` when both graphs are provided.
- Option A (minimal behavioral preservation): seed traversal from `projectsGraph[projectDir].dependencies` (not `fullProjectsGraph`) and only use `fullProjectsGraph` when expanding *through* unselected nodes.
2. Additionally (to fully respect `--filter-prod` semantics), ensure the `fullProjectsGraph` passed for prod-only filtering also excludes devDependencies.
- This may require plumbing/returning a prod-only full graph from the filtering layer (or recomputing it when `filter-prod` is in effect) and using it when calling `sortProjects()`.
3. Add/extend tests covering `--filter-prod` where devDependency-only paths would incorrectly affect ordering.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

pack.handler() passes opts.allProjectsGraph through to sortFilteredProjects(), but because
it’s optional, recursive pack invocations that only provide selectedProjectsGraph silently fall
back to subgraph-only sorting and won’t respect transitive dependencies through unselected workspace
projects. This also means the repo’s recursive-pack tests currently don’t exercise/validate the new
transitive-ordering behavior.

Code

pnpm11/releasing/commands/src/publish/pack.ts[R159-164]

+    const chunks = sortFilteredProjects({
+      selectedProjectsGraph,
+      allProjectsGraph: opts.allProjectsGraph,
+      prodAllProjectsGraph: opts.prodAllProjectsGraph,
+      prodOnlySelectedProjectDirs: opts.prodOnlySelectedProjectDirs,
+    })

Evidence

The recursive pack handler forwards an optional allProjectsGraph into sortFilteredProjects,
which itself falls back to the selected subgraph when the full graph is absent; the repo’s recursive
pack tests demonstrate a real call site that supplies only selectedProjectsGraph even though the
filter helper returns allProjectsGraph, so the new transitive-ordering behavior isn’t
applied/validated in that flow.

pnpm11/releasing/commands/src/publish/pack.ts[159-164]
pnpm11/workspace/projects-sorter/src/index.ts[36-46]
pnpm11/releasing/commands/test/publish/pack.ts[796-808]
pnpm11/workspace/projects-filter/src/filterProjectsFromDir.ts[7-37]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Recursive `pack` ordering only respects transitive dependencies through unselected workspace projects when `allProjectsGraph` (and, for `--filter-prod`, `prodAllProjectsGraph` + `prodOnlySelectedProjectDirs`) is provided to `sortFilteredProjects`. Today these fields are optional, and at least some in-repo recursive-pack call sites omit them, so the new behavior is not applied/covered.
### Issue Context
- `sortFilteredProjects()` explicitly falls back to `selectedProjectsGraph` when `allProjectsGraph` is absent, which prevents tunneling through unselected nodes.
- The recursive pack handler forwards `opts.allProjectsGraph` but does not ensure it is present.
- Existing recursive pack tests call `pack.handler()` with only `selectedProjectsGraph` even though `filterProjectsBySelectorObjectsFromDir()` returns `allProjectsGraph`.
### Fix Focus Areas
- pnpm11/releasing/commands/src/publish/pack.ts[159-164]
- pnpm11/releasing/commands/test/publish/pack.ts[796-808]
- pnpm11/workspace/projects-sorter/src/index.ts[36-47]
- pnpm11/workspace/projects-filter/src/filterProjectsFromDir.ts[7-37]
### Suggested fix
1. Update in-repo recursive-pack callers (tests at minimum) to pass `allProjectsGraph` (and prod metadata when relevant) from `filterProjectsBySelectorObjectsFromDir()` into `pack.handler()`.
2. Consider tightening the API contract to prevent silent fallback:
- make `allProjectsGraph` required for recursive pack when `selectedProjectsGraph` is provided, or
- add a runtime assertion/warning in `pack.handler()` when `opts.recursive` is true and `opts.allProjectsGraph` is missing (since the transitive-ordering fix cannot apply).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

pacquet’s select_recursive_projects() clones ProjectGraphNodes into
RecursiveSelection.selected, duplicating each selected node’s dependencies: Vec while also
retaining the full graph(s) for transitive-edge tunneling, which can significantly increase
CPU/allocs and peak memory for large filtered selections.

Code

pacquet/crates/cli/src/cli_args/recursive.rs[R371-387]

+    if let Some(prod_all) = &prod_all {
+        let regular: HashSet<&PathBuf> = regular_selected.iter().collect();
+        for dir in &prod_selected {
+            if let Some(node) = prod_all.get(dir) {
+                selected.insert(dir.clone(), node.clone());
+                if !regular.contains(dir) {
+                    prod_only_selected.insert(dir.clone());
+                }
+            }
+        }
}
+    // Regular-selected projects keep their full (dev-inclusive) edges,
+    // overwriting the prod node for any project selected both ways.
+    for dir in &regular_selected {
+        if let Some(node) = all.get(dir) {
+            selected.insert(dir.clone(), node.clone());
+        }

Evidence

The selected graph is built by node.clone() inserts; ProjectGraphNode’s Clone necessarily
clones its dependencies: Vec, duplicating those vectors. The sorter’s sorted_dependencies()
consults the full graph only when a dependency is not in the selected set (sorted), meaning the
full graph can omit selected nodes and still support tunneling.

pacquet/crates/cli/src/cli_args/recursive.rs[360-390]
pacquet/crates/workspace-projects-graph/src/graph.rs[10-17]
pacquet/crates/cli/src/cli_args/recursive.rs[139-170]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`select_recursive_projects()` currently materializes `RecursiveSelection.selected` by doing `node.clone()` from `all` / `prod_all`. Since `ProjectGraphNode` contains a `Vec<PathBuf>` of dependencies, this duplicates dependency lists for every selected project while the full graph(s) are still kept around for sorting.
### Issue Context
The sorter’s tunneling logic only consults the full graph for nodes **outside** the sorted/selected set, so the full graphs do not need to retain selected nodes for correctness; they only need the unselected nodes to traverse through.
### Fix Focus Areas
- pacquet/crates/cli/src/cli_args/recursive.rs[360-390]
- pacquet/crates/cli/src/cli_args/recursive.rs[150-170]
- pacquet/crates/workspace-projects-graph/src/graph.rs[10-17]
### Suggested fix
- While building `selected`, **move** nodes out of `all` / `prod_all` (e.g., via `swap_remove`/`shift_remove` on `IndexMap`) instead of cloning them.
- Keep the remaining (unselected-only) `all` / `prod_all` graphs in `RecursiveSelection` for tunneling.
- Preserve insertion order semantics (prod-selected first, then regular-selected overwrites) when moving nodes.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

sortFilteredProjects() constructs new Set(opts.prodOnlySelectedProjectDirs) even though
prodOnlySelectedProjectDirs is optional; if any caller provides prodAllProjectsGraph but omits
prodOnlySelectedProjectDirs, the sorter throws a TypeError before recursive execution starts.
In-repo call sites added/updated in this PR appear to pass both consistently, but this is a brittle
public API contract and can break out-of-tree or future internal callers.

Code

pnpm11/workspace/projects-sorter/src/index.ts[R59-70]

+  const fullProjectsGraph = opts.allProjectsGraph ?? opts.selectedProjectsGraph
+  const prodAllProjectsGraph = opts.prodAllProjectsGraph
+  if (!prodAllProjectsGraph) {
+    return sortProjects(opts.selectedProjectsGraph, fullProjectsGraph)
+  }
+  const prodOnlySelectedProjectDirs = new Set(opts.prodOnlySelectedProjectDirs)
+  return sequenceGraphByProject(
+    opts.selectedProjectsGraph,
+    (projectDir) => prodOnlySelectedProjectDirs.has(projectDir)
+      ? prodAllProjectsGraph
+      : fullProjectsGraph
+  ).chunks

Evidence

The function’s options type declares prodOnlySelectedProjectDirs as optional, but the
implementation uses it as an iterable without nullish handling, which will throw when undefined.

pnpm11/workspace/projects-sorter/src/index.ts[53-70]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`sortFilteredProjects()` calls `new Set(opts.prodOnlySelectedProjectDirs)` but `prodOnlySelectedProjectDirs` is optional. In JavaScript, `new Set(undefined)` throws because `undefined` is not iterable.
### Issue Context
This code runs in the recursive command scheduling path. While current in-repo integrations likely pass `prodOnlySelectedProjectDirs` whenever `prodAllProjectsGraph` is present, the function is exported and can be called with incomplete options (or regress in future call sites), causing a hard crash.
### Fix Focus Areas
- pnpm11/workspace/projects-sorter/src/index.ts[53-70]
### Suggested fix
- Change the Set construction to default to an empty array:
- `const prodOnlySelectedProjectDirs = new Set(opts.prodOnlySelectedProjectDirs ?? [])`
- (Optional, stronger contract) Enforce pairing at the type level via a discriminated union so `prodAllProjectsGraph` requires `prodOnlySelectedProjectDirs`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

filterProjectsBySelectorObjects() always builds regularSelectedProjectDirs (a Set of
regular-selected project dirs) even when no --filter-prod selectors are present, but that Set is
only needed to compute prodOnlySelectedProjectDirs for mixed selections. This adds avoidable O(k)
time and memory on regular-only --filter runs in large workspaces.

Code

pnpm11/workspace/projects-filter/src/index.ts[R146-150]

+    const regularSelectedProjectDirs = new Set(Object.keys(filteredGraph?.selectedProjectsGraph ?? {}) as ProjectRootDir[])
+    const prodOnlySelectedProjectDirs = prodFilteredGraph == null
+      ? undefined
+      : (Object.keys(prodFilteredGraph.selectedProjectsGraph) as ProjectRootDir[])
+        .filter((projectDir) => !regularSelectedProjectDirs.has(projectDir))

Evidence

The Set is created before checking whether a prod-filtered graph exists, but
prodOnlySelectedProjectDirs becomes undefined when prodFilteredGraph == null, making the Set
unused for regular-only filtering.

pnpm11/workspace/projects-filter/src/index.ts[146-150]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`filterProjectsBySelectorObjects()` constructs `regularSelectedProjectDirs` unconditionally, but it is only used when `prodFilteredGraph` exists (i.e., when `--filter-prod` selectors are present). For regular-only filtering, the Set allocation and key scan are dead work.
### Issue Context
This code runs in the filtering step used by many commands. For large selections/workspaces, the extra `Object.keys(...)+new Set(...)` can add measurable overhead even though it doesn’t change behavior.
### Fix Focus Areas
- pnpm11/workspace/projects-filter/src/index.ts[146-150]
### Suggested fix
Move creation of `regularSelectedProjectDirs` into the `prodFilteredGraph != null` branch (or compute it lazily only when `prodProjectSelectors.length > 0`). For example:
- Keep `prodOnlySelectedProjectDirs` undefined when `prodFilteredGraph` is null.
- Only then compute `regularSelectedProjectDirs` and filter prod-selected dirs against it.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools