What version of Turborepo are you using?

1.10.14

What package manager are you using / does the bug impact?

pnpm

What operating system are you using?

Mac

Describe the Bug

Related to #2162

TL;DR

Running a workspace-filtered turbo-ignore, after any lockfile change, results in that workspace being marked as 'affected', even when the lockfile change doesn't impact the workspace.

Full description

We have a monorepo that deploys multiple apps to Vercel, and have package updates managed by Renovate. With this setup, we frequently see package updates happening that should only affect one of the apps. For example, lets say that one app, "app_2", has is-even installed, and no other workspace in the repo does.

When is-even has its version updated by Renovate, preview deployments of every single one of our apps will be deployed to Vercel. When that PR is merged into the main branch, the same happens for production deployments. Here is an example of what the Vercel deployment logs for a different app say, about the turbo-ignore step for these changes:

≫   Using Turborepo to determine if this project is affected by the commit...
≫   Inferred "app_1" as workspace from "package.json"
≫   Using "build" as the task from the arguments
≫   Previous deployment ("a70f8196fc252817dc04dccd53cb5e25d5471834") for "app_1" on branch "renovate/is-even-4.x" is unreachable.
≫   Falling back to ref HEAD^
≫   Analyzing results of `npx turbo run "build" --filter=app_1...[HEAD^] --dry=json`
≫   This commit affects "app_1"

The rest of these builds happen fairly quickly, as every step in the pipeline is a cache hit, but ~1 minute is still taken for each one, mostly taken up by the Deploying outputs step. This slows down our build queue by quite a lot.

Expected Behavior

My understanding is that turbo-ignore's behaviour should match the same logic that turbo uses to determine if there is a cache hit or not. Based on #2162, and my observations above, I believe that lockfile updates should only trigger builds—via turbo-ignore—if the workspace in question is affected by the changed dependencies. In the example above, only "app_2" should have a deployment triggered, in preview or production.

To Reproduce

1. Clone the minimal starter
2. Install dependencies with pnpm
3. Update the lockfile in a way that shouldn't affect one of the apps (e.g. adding a devDependency to the root package.json)
4. Run cd apps/web && npx turbo-ignore
5. See that turbo-ignore now results in This commit affects "web" ✓ Proceeding with deployment

Reproduction Repo

No response