Passing the root workspace name as a package to --filter does not work as expected

[dstaley]

Verify canary release

• I verified that the issue exists in the latest Turborepo canary release.

Link to code that reproduces this issue

https://github.com/dstaley/turborepo-root-filter

Which canary version will you have in your reproduction?

2.3.4-canary.2

Enviroment information

turbo 2.3.4-canary.2

CLI:
   Version: 2.3.4-canary.2
   Path to executable: /Users/dstaley/Desktop/turborepo-root-filter/node_modules/.pnpm/[email protected]/node_modules/turbo-darwin-arm64/bin/turbo
   Daemon status: Running
   Package manager: pnpm9

Platform:
   Architecture: aarch64
   Operating system: macos
   WSL: false
   Available memory (MB): 4167
   Available CPU cores: 12

Environment:
   CI: None
   Terminal (TERM): xterm-256color
   Terminal program (TERM_PROGRAM): vscode
   Terminal program version (TERM_PROGRAM_VERSION): 1.95.3
   Shell (SHELL): /bin/zsh
   stdin: false

Expected behavior

turbo-ignore correctly detects when the dependencies of a task defined for the root workspace have changed compared against the main branch, and reports that the //#test:integration task will be run.

Actual behavior

The following error occurs:

x No package found with name 'turborepo-root-filter' in workspace

To Reproduce

1. turbo-ignore --task test:integration --fallback main

Additional context

I believe passing the root workspace package name as // sort of works, but I'm not able to get it to correctly detect when a dependency has changed.

To reproduce that,

1. Make a new branch off of main
2. Make an edit to packages/package-b/src/build.js and commit it.
3. Run npx turbo run "test:integration" --filter="//...[main]" --dry

Expected result:
Turbo reports that the //#test:integration, @repo/package-a#build, and @repo/package-b#build tasks will be run.

[chris-olszewski]

--filter works exclusively on the package graph and has no knowledge of task definitions so //...[main] is: "any package that is the root package or a dependency that has changed since main".

Only @repo/package-b changed since main and since in the package graph, it isn't a dependency of the root package, nothing gets included in the filter.

[dstaley]

Ah that makes sense! Is there a way to declare a package graph dependency without that dependency being added to the package manager? In this situation I want a way to know if I need to run a root-level task when one of the dependencies of that task has changed.

[gruckion]

This can be closed.