fix(yarn-berry): prune workspace devDependencies from prod graph

[andreipopa-who]

Yarn Berry merges a workspace package's dependencies and devDependencies into a single dependencies block in yarn.lock, dropping the dev marker. When a workspace package is consumed as a production dependency, the yarn-lock-v2 builder walked that whole block and inherited the parent's prod scope, promoting the consumed package's dev-only tooling (webpack, babel, ...) into the production graph as false positives.

Give the builder the consumed member's own package.json dependency groups via the new optional YarnLockV2WorkspaceArgs.workspacePackages map. When a child resolves to a @workspace: node and includeDevDeps is false, drop the dev-only entries (names in devDependencies but not in dependencies/optional/peer; prod wins on overlap).

Backward-compatible: with no workspacePackages provided, behavior is unchanged.

• Tests written and linted
• Documentation written / README.md updated https://snyk.io/docs/snyk-for-node/
• Follows CONTRIBUTING agreement
• Commit history is tidy https://git-scm.com/book/en/v2/Git-Branching-Rebasing
• Reviewed by Snyk team

What this does

Fixes false positives in Yarn Berry (v2/3/4) workspaces, where a consumed workspace package's dev-only build tooling (webpack, babel, ...) was reported as production dependencies of the consumer. Root cause: yarn.lock flattens a workspace member's dependencies + devDependencies into a single dependencies block with no dev marker, and getYarnLockV2ChildNode walked the whole block while inheriting the parent's prod scope (no includeDevDeps gate). The npm and pnpm parsers are unaffected because those lockfiles keep dev deps separate — so the fix belongs in the yarn-berry builder.

• types.ts: add optional workspacePackages to YarnLockV2WorkspaceArgs (+ WorkspacePackageManifest).
• yarn-lock-v2/utils.ts: new pruneWorkspaceDevDependencies helper; getYarnLockV2ChildNode prunes dev-only deps when the child is a @workspace: node and includeDevDeps is false — in both the resolution and the normal branch.
• yarn-lock-v2/build-depgraph-simple.ts: thread includeDevDeps + workspacePackages through dfsVisit.

Notes for the reviewer

• Detection uses the preserved resolution field (...@workspace:) on NormalisedPkgs, so no extract change is needed. Pruning drops names in the member's devDependencies that are not also in dependencies/optionalDependencies/peerDependencies (prod wins on overlap).
• Run locally: npm run test:jest. New regression tests live in test/jest/dep-graph-builders/yarn-lock-v2.test.ts (fixture test/jest/dep-graph-builders/fixtures/yarn-lock-v2/real/workspace-dev-deps/) and assert the leak without the map, the fix with it, and that includeDevDeps: true is unaffected. Full suite: 358/358.
• Consumer: snyk-nodejs-plugin#48 populates workspacePackages from each member's package.json. This PR is backward-compatible, so it can land and release ahead of the plugin bump.
• Edge cases covered: npm:-aliased workspace keys (@demo/shared-lib@npm:*) key off the package name; nested workspace→workspace hops prune at each boundary during DFS recursion.
• Large diff: the fixture yarn.lock is a real generated Yarn 4 lockfile (~3.3k lines); the source change is ~70 lines.

More information

• Consumer PR: fix(yarn-workspaces): pass member manifests to prune dev-dep leak snyk-nodejs-plugin#48
• SC-XXXX

Screenshots

Parsing apps/my-app (whose only prod dep is the workspace package @demo/shared-lib, which itself has only devDependencies) against the root yarn.lock, includeDevDeps: false:

	prod deps in my-app graph	dev tooling present
before	242	webpack, webpack-cli, @babel/core, @babel/preset-env, babel-loader
after	1 (@demo/shared-lib)	none

before                              after
my-app                              my-app
└─ @demo/shared-lib  (prod)         └─ @demo/shared-lib   (prod, leaf)
   ├─ webpack         ✗ dev
   ├─ @babel/core     ✗ dev
   ├─ babel-loader    ✗ dev
   └─ … 238 more      ✗ dev

[CLAassistant]

All committers have signed the CLA.

[JamesPatrickGill]

Correct me if wrong but here we key by name but if a customer uses an alias like

"some-package": "npm:@alias/other-name@1"

Then if we pass in the alias to getYarnLockV2ChildNode as we pass in whatever the parents know the pkg as. Then we will be returning undefined for something we have an answer too.

Should we be respecting the alias here or am I overthinking it?

[andreipopa-who]

Good catch ! 🦾

This commit should solve the problem 👍
8d05f54

[JamesPatrickGill]

Same as above comment