feat(CSENG-175): Add support for --allow-incomplete-sbom

[snyk-abedonik]

Pull Request Submission Checklist

• Follows CONTRIBUTING guidelines
• Commit messages
  are release-note ready, emphasizing
  what was changed, not how.
• Includes detailed description of changes
• Contains risk assessment (Low | Medium | High)
• Highlights breaking API changes (if applicable)
• Links to automated tests covering new functionality
• Includes manual testing instructions (if necessary)
• Updates relevant GitBook documentation (PR link: ___)
• Includes product update to be announced in the next stable release notes

What does this PR do?

Where should the reviewer start?

How should this be manually tested?

What's the product update that needs to be communicated to CLI users?

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[github-actions]

	Fails
🚫	"feat(CSENG-175): Add support for --allow-incomplete-sbom" is not using a valid commit message format. For commit guidelines, see: CONTRIBUTING.

	Warnings
⚠️	Since the CLI is unifying on a standard and improved tooling, we're starting to migrate old-style imports and exports to ES6 ones. A file you've modified is using either module.exports or require(). If you can, please update them to ES6 import syntax and export syntax. Files found: src/lib/plugins/get-multi-plugin-result.ts
⚠️	You've modified files in src/ directory, but haven't updated anything in test folder. Is there something that could be tested?

Generated by 🚫 dangerJS against 58a89f9

[snyk-pr-review-bot]

PR Reviewer Guide 🔍

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Logic Error 🟠 [major] The early return implemented to support incomplete SBOMs triggers whenever allResults is empty, regardless of whether any actual failures occurred. If the CLI is run in a directory where no manifest files are detected (meaning both allResults and failedResults are empty), this change will cause the CLI to return a successful "empty" result instead of falling through to the existing error handling logic (line 196) which informs the user that no potential projects were found. This changes the default behavior for non-project directories from an error to a success when the flag is enabled. Consider adding a check for failedResults.length > 0. if (shouldPrintEffectiveDepGraphWithErrors(options)) { return { plugin: { name: 'custom-auto-detect' }, UX Issue 🟠 [major] The introduction of suppressWarnings silences all console output (on stderr) regarding dependency resolution failures when the --allow-incomplete-sbom flag is used. While the intention is to rely on annotations within the generated SBOM, silencing console.warn entirely deprives interactive users of immediate feedback about why their results are incomplete. Users may be confused by an "empty" success without seeing the underlying resolution errors that usually appear in the terminal. const suppressWarnings = shouldPrintEffectiveDepGraphWithErrors(options); const isNotJsonOrQueiet = !options.json && !options.quiet && !suppressWarnings;

📚 Repository Context Analyzed This review considered 4 relevant code sections from 2 files (average relevance: 1.08) src/lib/snyk-test/run-test.ts (3 segments, lines 103-929) src/lib/plugins/get-multi-plugin-result.ts (lines 1-291)