Skip to content

Support optional npm dependencies #1459

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 13 commits into
base: master
Choose a base branch
from

Conversation

dterrybd
Copy link
Contributor

@dterrybd dterrybd commented Jul 2, 2025

This adds support for optional npm dependencies as well as for filtering out optional dependencies using --detect.npm.dependency.types.excluded=OPTIONAL.

This works for all lockfiles and all npm detectors.

return !excludingBecauseDev && !excludingBecausePeer;
boolean excludingBecauseOptional = (npmDependencyTypeFilter.shouldExclude(NpmDependencyType.OPTIONAL, combinedPackageJson.getOptionalDependencies())
&& combinedPackageJson.getOptionalDependencies().containsKey(elementEntry.getKey()));
return !excludingBecauseDev && !excludingBecausePeer && !excludingBecauseOptional;
Copy link
Contributor

Choose a reason for hiding this comment

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

I see that we're following a pre-existing pattern, but wondering if we need to handle cases where a dependency is optional but also belongs other type(s). What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is certainly an interesting discussion. I'm leaning towards leaving this as is given it is a pre-existing pattern as you say and that it would impact other npm detectors as well.

I think the most common combination of types would be a dependency being both a peer and a dev dependency and I don't believe we have heard complaints about us too aggressively filtering those. I think it's less common to mix optional dependencies with other types so hopefully we are safe with this specific edit.

@dterrybd dterrybd requested a review from cpottsbd July 3, 2025 17:09
@@ -26,6 +26,8 @@

* A new property, [detect.stateless.policy.check.fail.on.severities](properties/basic-properties.html#ariaid-title34) has been added, which will trigger [detect_product_short] to fail the scan and notify the user if a policy violation matches the configured value. This property overrides the default "Blocker" and "Critical" severity settings that cause [detect_product_short] scans to exit. This property applies to both [Rapid](runningdetect/rapidscan.md) and [Stateless](runningdetect/statelessscan.md) scans. Intelligent persistent scans, (when scan mode is not set to RAPID, STATELESS, or [--detect.blackduck.scan.mode](properties/all-properties.html#ariaid-title5) is explicitly set to INTELLIGENT and scan data is persisted), should continue using the [detect.policy.check.fail.on.severities](properties/basic-properties.html#ariaid-title34), property.

* npm scans now report optional dependencies. The `detect.dependency.types.excluded` property has been extended to exclude them if OPTIONAL is specified in the list of arguments.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested tweakage:

  • Node Package Manager (npm) scans now report optional dependencies. The detect.dependency.types.excluded property has been extended to exclude optional dependencies if OPTIONAL is specified in the list of arguments.

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.

4 participants