-
Notifications
You must be signed in to change notification settings - Fork 79
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
base: master
Are you sure you want to change the base?
Conversation
return !excludingBecauseDev && !excludingBecausePeer; | ||
boolean excludingBecauseOptional = (npmDependencyTypeFilter.shouldExclude(NpmDependencyType.OPTIONAL, combinedPackageJson.getOptionalDependencies()) | ||
&& combinedPackageJson.getOptionalDependencies().containsKey(elementEntry.getKey())); | ||
return !excludingBecauseDev && !excludingBecausePeer && !excludingBecauseOptional; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
@@ -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. |
There was a problem hiding this comment.
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.
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.