Skip to content

fix(yarn-berry): identify workspace member as root in dependency tree#486

Open
Strum355 wants to merge 3 commits intoguacsec:mainfrom
Strum355:TC-4182
Open

fix(yarn-berry): identify workspace member as root in dependency tree#486
Strum355 wants to merge 3 commits intoguacsec:mainfrom
Strum355:TC-4182

Conversation

@Strum355
Copy link
Copy Markdown
Member

Summary

  • Fixes yarn-berry workspace member dependency analysis (TC-4182, part of TC-4161)
  • The #isRoot method in Yarn_berry_processor only matched @workspace:. (the workspace root), causing member packages like member-a@workspace:packages/member-a to never be identified as the root of the dependency tree
  • Changed #isRoot to match by manifest name prefix (this._manifest.name@workspace:) so workspace members are correctly identified

Test plan

  • Added workspace member test fixtures under test/providers/tst_manifests/yarn-berry/workspace_member/
  • Added parameterized stack and component analysis tests for yarn-berry workspace members
  • All 47 tests pass, no regressions
  • ESLint clean

🤖 Generated with Claude Code

Strum355 and others added 3 commits April 22, 2026 13:29
The `#isRoot` method in `Yarn_berry_processor` only matched the workspace
root package (`@workspace:.`), causing workspace member analysis to fail
to find the member's dependency subtree. Changed to match by manifest name
prefix so members like `member-a@workspace:packages/member-a` are correctly
identified as the root when analyzing from a workspace member's manifest.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
… output

yarn info --recursive without --all only returns the workspace root,
omitting workspace member dependencies entirely. Adding --all includes
packages from all workspace members in the output.

Test fixtures regenerated from actual yarn info output, including real
virtual locators and follow-redirects resolving to 1.16.0.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@Strum355 Strum355 requested a review from ruromero April 22, 2026 16:16
let providedDataForComponent = provider.provideComponent(manifestPath);

compareSboms(providedDataForComponent.content, expectedSbom);
}).timeout(process.env.GITHUB_ACTIONS ? 15000 : 10000);
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not always use the bigger timeout and stop adding (even remove) dependencies to GH actions env vars?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants