• Create PR with unit tests

Description

When --exclude-peers runs without selectedProjectsGraph, sbom.handler() does a Promise.all()
over every lockfile importer and calls realpath() for each importer path with no concurrency
limit. On large workspaces (or unusually large importer lists), this can saturate filesystem I/O /
libuv threadpool and make pnpm sbom --exclude-peers slow or intermittently fail under resource
pressure.

Code

deps/compliance/commands/src/sbom/sbom.ts[R226-246]

+      const lockfileRoot = await realpath(lockfileDir)
+      await Promise.all(
+        Object.keys(lockfile.importers).map(async (importerId) => {
+          // A crafted lockfile could carry an importer key that escapes the
+          // project, via `..` segments or a symlinked directory. Canonicalize
+          // with realpath and skip anything resolving outside the project root,
+          // so a manifest is never read from outside the tree.
+          let importerDir: string
+          try {
+            importerDir = await realpath(path.resolve(lockfileDir, importerId))
+          } catch {
+            return
+          }
+          const rel = path.relative(lockfileRoot, importerDir)
+          if (rel !== '' && (rel.startsWith('..') || path.isAbsolute(rel))) return
+          const importerManifest = await safeReadProjectManifestOnly(importerDir)
+          if (importerManifest) {
+            byImporter[importerId] = peerNamesFromManifest(importerManifest)
+          }
+        })
+      )

Evidence

The SBOM handler launches Promise.all(Object.keys(lockfile.importers).map(async ...)) and performs
await realpath(...) for each importer before calling safeReadProjectManifestOnly(), so
realpath() is not throttled. The manifest reader’s internal limiter only covers the subsequent
manifest read step, not the realpath() calls.

deps/compliance/commands/src/sbom/sbom.ts[226-246]
workspace/project-manifest-reader/src/index.ts[22-35]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`pnpm sbom --exclude-peers` (when no project graph is selected) scans every `lockfile.importers` entry and runs `realpath()` for each importer concurrently via `Promise.all()`. This is unbounded concurrency for filesystem operations and can degrade performance or reliability on large workspaces.
## Issue Context
`safeReadProjectManifestOnly()` already rate-limits manifest reads internally, but the preceding `realpath()` calls are outside that limiter, so the overall scan can still fan out heavily.
## Fix Focus Areas
- deps/compliance/commands/src/sbom/sbom.ts[226-246]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

When --exclude-peers runs without selectedProjectsGraph, importer paths are validated using only
lexical path checks (path.resolve + startsWith), which do not prevent a symlinked importer
directory under lockfileDir from resolving to a location outside the intended project tree and
being read by safeReadProjectManifestOnly(). This can cause unintended local manifest reads (and
peer-pruning decisions) outside the workspace boundary in symlink-based layouts.

Code

deps/compliance/commands/src/sbom/sbom.ts[R225-233]

+      const lockfileRoot = path.resolve(lockfileDir)
+      await Promise.all(
+        Object.keys(lockfile.importers).map(async (importerId) => {
+          // A crafted lockfile could carry an importer key with `..` segments;
+          // never read a manifest outside the project root.
+          const importerDir = path.resolve(lockfileDir, importerId)
+          if (importerDir !== lockfileRoot && !importerDir.startsWith(lockfileRoot + path.sep)) return
+          const importerManifest = await safeReadProjectManifestOnly(importerDir)
+          if (importerManifest) {

Evidence

The new code computes and checks importerDir using path.resolve/startsWith and then reads a
manifest from that directory; safeReadProjectManifestOnly wraps readProjectManifestOnly, which
attempts to open package.json/package.json5/package.yaml in the provided directory and does
not apply any containment or realpath-based enforcement, so a symlinked path can still escape the
intended root.

deps/compliance/commands/src/sbom/sbom.ts[225-234]
workspace/project-manifest-reader/src/index.ts[24-34]
workspace/project-manifest-reader/src/index.ts[64-104]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`--exclude-peers` (no `selectedProjectsGraph`) resolves `importerDir` with `path.resolve()` and checks it is under `lockfileRoot` via a string prefix check. This prevents `..` traversal but does **not** prevent a symlink within `lockfileDir` (e.g. `packages` -> `/some/other/place`) from escaping the intended boundary.
### Issue Context
This code path then calls `safeReadProjectManifestOnly(importerDir)`, which reads `package.json`/`package.json5`/`package.yaml` from the provided directory and does not enforce any root containment itself.
### Fix Focus Areas
- deps/compliance/commands/src/sbom/sbom.ts[225-233]
### Suggested fix
- Canonicalize both the root and importer directories via `fs.promises.realpath()` (or equivalent) before performing the containment check.
- Perform the boundary test using `path.relative(realRoot, realImporter)` (reject if it starts with `'..'` or is absolute), or an equivalent robust check.
- Optionally: if `realpath()` fails for an importer, skip it (consistent with `safeReadProjectManifestOnly` returning null for missing manifests).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

When --exclude-peers runs without selectedProjectsGraph, importer IDs from the lockfile are
joined into filesystem paths (path.join(lockfileDir, importerId)) and read, allowing a crafted
lockfile importer key like .. to trigger manifest reads outside lockfileDir.

Code

deps/compliance/commands/src/sbom/sbom.ts[R225-230]

+      await Promise.all(
+        Object.keys(lockfile.importers).map(async (importerId) => {
+          const importerManifest = await safeReadProjectManifestOnly(path.join(lockfileDir, importerId))
+          if (importerManifest) {
+            byImporter[importerId] = peerNamesFromManifest(importerManifest)
+          }

Evidence

The new code reads manifests by joining lockfileDir and raw importerId strings from the
lockfile. getLockfileImporterId() can produce ..-containing importer IDs via path.relative(),
and the manifest reader reads package.json under whatever directory it’s given, making escaping
reads possible.

deps/compliance/commands/src/sbom/sbom.ts[225-231]
lockfile/fs/src/getLockfileImporterId.ts[6-8]
workspace/project-manifest-reader/src/index.ts[24-35]
workspace/project-manifest-reader/src/index.ts[64-67]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`sbom.ts` reads importer manifests from `path.join(lockfileDir, importerId)` where `importerId` comes from `Object.keys(lockfile.importers)`. If a lockfile contains importer keys with `..` segments (or otherwise escaping paths), this can cause reads of `package.json` outside the intended `lockfileDir` boundary.
### Issue Context
`getLockfileImporterId()` uses `path.relative()` and does not prevent `..` segments, and `safeReadProjectManifestOnly()` reads `package.json` in the provided directory without any containment checks. Adding `--exclude-peers` introduced a new path that reads manifests for every importer in the lockfile.
### Fix Focus Areas
- deps/compliance/commands/src/sbom/sbom.ts[219-233]
- lockfile/fs/src/getLockfileImporterId.ts[6-8]
### Suggested fix
- Before calling `safeReadProjectManifestOnly()`, resolve the candidate directory (e.g. `const dir = path.resolve(lockfileDir, importerId)`) and skip if it is not within `path.resolve(lockfileDir)` (prefix check using `path.relative()` or `startsWith(lockfileRoot + path.sep)`), while still allowing `importerId === '.'`.
- Optionally, also skip absolute `importerId` values.
- Add a test that uses a lockfile with an escaping importer key to ensure SBOM doesn’t read outside `lockfileDir`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

With --exclude-peers and --filter (selectedProjectsGraph present), buildSharedContext()
records peer names only for the selected importers, but collectSbomComponents() also walks extra
workspace importers reachable via link: dependencies. Peer dependencies declared in those
additional workspace packages will still be included in the SBOM, partially defeating
--exclude-peers.

Code

deps/compliance/commands/src/sbom/sbom.ts[R339-342]

+    if (opts.selectedProjectsGraph) {
+      for (const [projectDir, { package: project }] of Object.entries(opts.selectedProjectsGraph)) {
+        byImporter.set(getLockfileImporterId(lockfileDir, projectDir), peerNamesFromManifest(project.manifest))
+      }

Evidence

Peer-name collection is limited to selectedProjectsGraph, but SBOM traversal can include
additional importer IDs from resolveWorkspaceDeps.additionalImporterIds, and peer filtering is
keyed by importer ID; missing entries mean peers won’t be filtered for those walked importers.

deps/compliance/commands/src/sbom/sbom.ts[336-343]
deps/compliance/commands/src/sbom/sbom.ts[455-468]
deps/compliance/sbom/src/collectComponents.ts[63-75]
deps/compliance/sbom/src/collectComponents.ts[249-301]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
When `opts.excludePeers` is enabled and `opts.selectedProjectsGraph` is set, `excludePeerNamesByImporter` is populated only for the selected projects. However, SBOM generation may also walk additional importer IDs (workspace packages) discovered via `resolveWorkspaceDeps()` (i.e. `link:` dependencies). Those additional importers will not have their peer dependencies excluded.
## Issue Context
This shows up in workspaces when generating an SBOM for a filtered subset that depends on other workspace packages; those extra workspace packages are still included in the SBOM graph, but their own `peerDependencies` are not filtered.
## Fix Focus Areas
- deps/compliance/commands/src/sbom/sbom.ts[327-385]
- deps/compliance/commands/src/sbom/sbom.ts[455-489]
### Suggested approach
- When `opts.excludePeers` is true and workspace graphs are available, populate `excludePeerNamesByImporter` from *all* known workspace manifests (e.g. `allProjectsGraph` as well as `selectedProjectsGraph`), not only the selected set.
- You already build `workspaceManifestsByImporterId` from both graphs; reuse it to compute peer name sets without extra filesystem reads.
- Alternatively (or additionally), in `generateSbomForProject()`, after `resolvedWorkspaceDeps` is computed, ensure every `additionalImporterId` has a peer-name entry (from `ctx.workspaceManifestsByImporterId`) before calling `collectSbomComponents()`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

collectSbomComponents() filters peer dependencies from an importer's root step after
lockfileWalkerGroupImporterSteps() has already added those depPaths to a shared cross-importer
"walked" set. If an excluded peer is the first importer to mention a depPath that another importer
includes as a real dependency, the later importer will skip it and the SBOM can omit that real
dependency entirely.

Code

deps/compliance/sbom/src/collectComponents.ts[R66-80]

+    importerWalkers.map(async ({ importerId, step }) => {
+      // Dropping a peer's direct entry here (rather than from the walker) prunes
+      // its exclusive transitive subtree for free: packages reachable only
+      // through the peer are never walked, while packages shared with a real
+      // dependency are still reached via that path.
+      const peerNames = opts.excludePeerNamesByImporter?.get(importerId)
+      const rootStep = (peerNames?.size)
+        ? {
+          ...step,
+          dependencies: step.dependencies.filter((dep) => {
+            const { name } = nameVerFromPkgSnapshot(dep.depPath, dep.pkgSnapshot)
+            return !name || !peerNames.has(name)
+          }),
+        }
+        : step

Evidence

The SBOM code filters peers after the importer steps are created, but the lockfile walker’s step()
adds each direct depPath to a shared walked Set across all importers. Therefore, when a peer dep
is filtered out, its depPath may already be in walked, preventing other importers from ever
emitting/walking it even when it is a non-peer dependency for them.

deps/compliance/sbom/src/collectComponents.ts[39-90]
lockfile/walker/src/index.ts[17-45]
lockfile/walker/src/index.ts[91-122]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`collectSbomComponents()` prunes peer deps by filtering `step.dependencies` *after* `lockfileWalkerGroupImporterSteps()` has already constructed steps using a shared `walked` set across importers. Because `step()` marks direct depPaths as walked up-front, a pruned peer depPath may be suppressed for later importers even if it is a real dependency there, causing missing components/relationships in the SBOM.
### Issue Context
- `lockfileWalkerGroupImporterSteps()` shares a single `walked` Set across all importer steps and calls `step()` immediately for each importer, which adds each direct depPath to `walked`.
- The new peer pruning in SBOM happens later by filtering `step.dependencies`.
### Fix Focus Areas
- deps/compliance/sbom/src/collectComponents.ts[39-91]
- lockfile/walker/src/index.ts[17-45]
- lockfile/walker/src/index.ts[91-122]
### Implementation direction
Choose one approach that ensures excluded peers do **not** get marked as walked globally before a non-peer path can include them:
1. **Per-importer walker state (SBOM-local):** when `excludePeerNamesByImporter` is present, build walker steps per importer with an isolated `walked` set (e.g., invoke the walker per importer rather than using the grouped walker that shares `walked`). Deduplicate components via `componentsMap` as today.
2. **Filter before walking:** compute the root entry depPaths to walk per importer (from the importer snapshot’s dependency refs) and exclude peers there (so the walker never sees/marks those depPaths).
3. **Walker enhancement:** extend `lockfileWalkerGroupImporterSteps()` to accept a per-importer “skip direct depPaths” set and ensure skipped depPaths are not added to `walked`.
Add a regression test with at least 2 importers where importer A lists package X as a peer (thus excluded) and importer B lists X as a normal dependency; verify X remains in SBOM when `--exclude-peers` is enabled.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

peerNamesFromManifest() treats devDependencies as “regular”, so a dep listed in both
peerDependencies and devDependencies won’t be excluded even in --prod mode (where dev deps are
not included), causing --exclude-peers to keep common consumer-provided peers.

Code

deps/compliance/commands/src/sbom/sbom.ts[R278-288]

+function peerNamesFromManifest (manifest: ProjectManifest): Set<string> {
+  // A name declared as both a peer and a regular dependency is a real dependency
+  // the package pulls in itself, so keep it.
+  const regular = new Set([
+    ...Object.keys(manifest.dependencies ?? {}),
+    ...Object.keys(manifest.devDependencies ?? {}),
+    ...Object.keys(manifest.optionalDependencies ?? {}),
+  ])
+  return new Set(
+    Object.keys(manifest.peerDependencies ?? {}).filter((name) => !regular.has(name))
+  )

Evidence

The peer-exclusion set is computed by subtracting any peer name also present in dependencies,
devDependencies, or optionalDependencies, which means peers duplicated into devDeps are not
excluded. The repo contains fixtures where the same package is listed as both a peer and a dev
dependency, demonstrating this is a real and common pattern that will break --exclude-peers
especially under --prod.

deps/compliance/commands/src/sbom/sbom.ts[278-288]
pnpm/test/fixtures/workspace-with-circular-peers/modules/module5/package.json[4-22]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`peerNamesFromManifest()` currently considers `devDependencies` and `optionalDependencies` as “regular” unconditionally. In `--prod` (or `--no-optional`) runs, this prevents excluding peers that are duplicated into those non-included fields (a common pattern is `peerDependencies` + `devDependencies` for local testing).
### Issue Context
`--exclude-peers` is meant to omit consumer-provided peer deps from SBOM output. However, peers duplicated into `devDependencies` should only be treated as “regular” when dev deps are actually included in the SBOM run.
### Fix Focus Areas
- deps/compliance/commands/src/sbom/sbom.ts[175-178]
- deps/compliance/commands/src/sbom/sbom.ts[210-233]
- deps/compliance/commands/src/sbom/sbom.ts[278-289]
### Suggested fix
- Change `peerNamesFromManifest(manifest)` to accept the computed `include` flags.
- Build the `regular` set from only the dependency fields that are included (e.g., always `dependencies` if included; `devDependencies` only if `include.devDependencies` is true; `optionalDependencies` only if `include.optionalDependencies` is true).
- Update all call sites to pass `include` so `--prod` correctly excludes peer+dev duplicates, while default runs that include dev deps keep them as real dev deps.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

With --exclude-peers enabled and selectedProjectsGraph unset, buildSharedContext() scans every
lockfile importer via realpath() + safeReadProjectManifestOnly(), even when allProjectsGraph
is available and the command may later only walk a subset (notably in --split mode). This adds
avoidable filesystem I/O and latency to pnpm sbom --exclude-peers on large workspaces.

Code

deps/compliance/commands/src/sbom/sbom.ts[R327-383]

+  const lockfileDir = opts.lockfileDir ?? opts.dir
+
+  // peerDependencies are identified from the manifest, not the lockfile: with
+  // auto-install-peers they resolve into the importer's `dependencies` with no
+  // distinguishing marker. Map every walked importer to its peer names so the
+  // collector can drop them.
+  // Keyed by a Map, not a plain object: importer ids come from the lockfile
+  // (attacker-controlled in an untrusted clone), and a key like `__proto__`
+  // would corrupt a plain object's prototype.
+  let excludePeerNamesByImporter: Map<string, Set<string>> | undefined
+  if (opts.excludePeers) {
+    const byImporter = new Map<string, Set<string>>()
+    if (opts.selectedProjectsGraph) {
+      for (const [projectDir, { package: project }] of Object.entries(opts.selectedProjectsGraph)) {
+        byImporter.set(getLockfileImporterId(lockfileDir, projectDir), peerNamesFromManifest(project.manifest))
+      }
+    } else {
+      // No project graph was selected, so collectSbomComponents walks every
+      // importer in the lockfile. Resolve each importer's own manifest so peers
+      // in workspace packages are dropped too, not only those in the directory
+      // pnpm ran in. safeReadProjectManifestOnly returns null (rather than
+      // throwing) for an importer whose manifest is gone (e.g. a stale lockfile),
+      // and skips the installability check that would otherwise abort the SBOM.
+      const lockfileRoot = await realpath(lockfileDir)
+      // Bound the fan-out: a large workspace can have many importers, and
+      // reading every manifest at once would spike open file descriptors.
+      const limitManifestReads = pLimit(16)
+      await Promise.all(
+        Object.keys(lockfile.importers).map((importerId) => limitManifestReads(async () => {
+          // A crafted lockfile could carry an importer key that escapes the
+          // project, via `..` segments or a symlinked directory. Canonicalize
+          // with realpath and skip anything resolving outside the project root,
+          // so a manifest is never read from outside the tree.
+          let importerDir: string
+          try {
+            importerDir = await realpath(path.resolve(lockfileDir, importerId))
+          } catch {
+            return
+          }
+          const rel = path.relative(lockfileRoot, importerDir)
+          if (rel !== '' && (rel.startsWith('..') || path.isAbsolute(rel))) return
+          // safeReadProjectManifestOnly tolerates a missing manifest but still
+          // throws on a malformed one (parse error). In an untrusted clone a
+          // single junk package.json must not abort the whole SBOM, so skip it
+          // (fail-open: an unparseable importer's peers just aren't filtered).
+          let importerManifest: ProjectManifest | null
+          try {
+            importerManifest = await safeReadProjectManifestOnly(importerDir)
+          } catch {
+            return
+          }
+          if (importerManifest) {
+            byImporter.set(importerId, peerNamesFromManifest(importerManifest))
+          }
+        }))
+      )
+    }

Evidence

handler() builds shared context before deciding split/non-split, so the new per-importer manifest
scan runs even when the command will later emit per-project SBOMs. The scan is triggered solely by
the absence of selectedProjectsGraph, even though allProjectsGraph is available and already used
to populate workspace manifests, making the additional filesystem work avoidable in common workspace
runs.

deps/compliance/commands/src/sbom/sbom.ts[187-197]
deps/compliance/commands/src/sbom/sbom.ts[327-383]
deps/compliance/commands/src/sbom/sbom.ts[396-402]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`buildSharedContext()` currently computes `excludePeerNamesByImporter` by reading manifests from disk for every `lockfile.importers` entry whenever `opts.selectedProjectsGraph` is not set. In workspaces, pnpm often already provides `opts.allProjectsGraph` (and the command already uses it to populate `workspaceManifestsByImporterId`), so the extra per-importer `realpath()` + manifest read is redundant and can be expensive. This cost is paid even when `handler()` later goes into `--split` and generates per-project SBOMs.

### Issue Context
- The expensive path is gated by `opts.excludePeers` and `!opts.selectedProjectsGraph`.
- `handler()` calls `buildSharedContext()` before deciding `shouldSplit`, so this scan happens even for split output.

### Fix Focus Areas
- Prefer deriving peer names from `opts.selectedProjectsGraph ?? opts.allProjectsGraph` when available (using the already-loaded `entry.package.manifest`).
- If you still need to handle stale lockfile importers not present in the graph, consider scanning *only* missing importerIds after seeding from the graph.
- Optionally defer any filesystem scanning until you know the set of importers that will actually be walked (especially in split mode).

- deps/compliance/commands/src/sbom/sbom.ts[187-197]
- deps/compliance/commands/src/sbom/sbom.ts[327-383]
- deps/compliance/commands/src/sbom/sbom.ts[396-402]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

When excludePeerNamesByImporter is set, collectSbomComponents() calls
lockfileWalkerGroupImporterSteps() once per importer, which removes the cross-importer
deduplication done by the walker’s shared walked set. On large workspaces with many importers and
shared subgraphs, pnpm sbom --exclude-peers can do substantially more traversal work than
necessary.

Code

deps/compliance/sbom/src/collectComponents.ts[R69-74]

+  // When excluding peers, walk each importer with its own `walked` set so one
+  // importer's peer can't suppress another's real dependency.
+  const importerWalkers = opts.excludePeerNamesByImporter
+    ? allImporterIds.flatMap((importerId) =>
+      lockfileWalkerGroupImporterSteps(opts.lockfile, [importerId], { include: opts.include }))
+    : lockfileWalkerGroupImporterSteps(opts.lockfile, allImporterIds, { include: opts.include })

Evidence

The new code invokes the walker once per importer when peers are excluded. The walker implementation
creates a single shared walked set per invocation and uses it to skip already-walked depPaths;
removing that shared set across importers is what increases traversal work.

deps/compliance/sbom/src/collectComponents.ts[69-75]
lockfile/walker/src/index.ts[17-44]
lockfile/walker/src/index.ts[91-123]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
With `--exclude-peers`, SBOM collection switches from a single `lockfileWalkerGroupImporterSteps(lockfile, allImporterIds, ...)` call to N separate calls (one per importer). Because `lockfileWalkerGroupImporterSteps()` dedupes traversal using a per-invocation `walked` set, this change can multiply work across importers.
## Issue Context
This only affects the `--exclude-peers` path, but that path is explicitly targeting published-library SBOM generation in workspaces, which can be large.
## Fix Focus Areas
- deps/compliance/sbom/src/collectComponents.ts[69-75]
- lockfile/walker/src/index.ts[17-45]
### Suggested approach
- Keep correctness (peers shouldn’t suppress other importers), but avoid repeated traversal by separating:
1) relationship edge creation per importer (after peer filtering), from
2) component discovery/traversal (which can still use a shared-walked traversal from the union of entry nodes).
- Concretely: compute each importer’s filtered direct depPaths, push relationships for those edges, then run a single walker over the union of filtered entry nodes to populate `componentsMap`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

When --exclude-peers runs without selectedProjectsGraph, sbom.handler() reads every importer
manifest via safeReadProjectManifestOnly() but does not catch parse/permission errors, so one
malformed/unreadable workspace manifest aborts SBOM generation even though the SBOM could otherwise
be produced from the lockfile.

Code

deps/compliance/commands/src/sbom/sbom.ts[R245-248]</cod...

• ➕ Minimal changes to lockfile walking/collection code
• ➕ Could reuse existing collected component graph
• ➖ Hard to safely prune exclusive transitive subtrees; you must also fix relationships/dependsOn
• ➖ Higher risk of leaving dangling dependency edges or orphan components

• ➕ Would allow peer identification without reading manifests
• ➕ Could enable richer handling beyond omission in the future
• ➖ Requires lockfile schema changes and migration/back-compat considerations
• ➖ Doesn’t help existing lockfiles; still need fallback behavior

• ➕ Keeps full dependency graph while indicating consumer-provided peers
• ➕ Potentially useful for downstream tooling
• ➖ CycloneDX 1.7 lacks a standard scope/relationship for peerDependencies; extensions reduce interoperability
• ➖ Increases complexity and may be considered non-compliant by strict consumers