Fix Yarn detector perf

[grvillic]

Context

We got reports from a couple of mono repos using Yarn that the performance was incredibly slow, which is surprising given the detector is only reading files from disk without any CLI nor network calls, we had a bottleneck somewhere.

Summary

On a Yarn Berry monorepo with a 2.2 MB / ~55k-line yarn.lock, 4,809 lockfile entries, and 594 workspace patterns a Yarn-only scan took ~94 minutes.

After a targeted fix scoped exclusively to the Yarn detector, the same scan completes in ~15 seconds while producing byte-identical results.

Root cause

YarnLockComponentDetector.GetWorkspaceDependencies ran a full recursive filesystem walk once per workspace pattern. With 594 workspace patterns, it walked the entire monorepo tree, including a very large node_modules, 594 times. Cost was O(patterns × filesystem size).

Fix

Update src/Microsoft.ComponentDetection.Detectors/yarn/YarnLockComponentDetector.cs to perform a single recursive filesystem traversal, discovering and parsing each candidate package.json exactly once, matched against a union matcher of all workspace globs.

Replay dependency resolution in the original order (workspace-pattern order, then discovery order) so the "first-wins" location attribution stays identical to the previous per-pattern behavior.

Net effect: 594 filesystem walks → 1 walk. No change to which components, graph edges, dev flags, or roots are produced.

Results

Run	Detection time
Baseline (before fix)	5652.6 s (~94 min)
Improved ( filesystem cache)	15.5 s

[Copilot]

Copilot encountered an error: Your billing is not configured or you have Copilot licenses from multiple standalone organizations or enterprises. To use premium requests, select a billing entity via the GitHub site, under Settings > Copilot > Features.

[github-actions]

👋 Hi! It looks like you modified some files in the Detectors folder.
You may need to bump the detector versions if any of the following scenarios apply:

• The detector detects more or fewer components than before
• The detector generates different parent/child graph relationships than before
• The detector generates different devDependencies values than before

If none of the above scenarios apply, feel free to ignore this comment 🙂