[FEATURE] library mode

[jkowalleck]

Is your feature request related to a problem? Please describe.

if i build a SBOM for a library, i do not want to have non-bundled component listed as if they were concrete.
These dependencies are extraneous/"external" and the version of them is not clear - it is resolved on install-time .
Also, transitive dependencies of those are not clear until install-time.

This should be reflected in the SBOM.

Describe the solution you'd like

Spec: CycloneDX/specification#321

add a n option to have

• only the bundled dependencies and the direct dependencies as components in the SBOM result.
• non-bundled' components must have no version.
• non-bundled's components must have a version range - specification#321
• non-bundled are marked as "external" - specification#321

option could be called (list of ideas)

• --library-mode
• --mark-extraneous/--mark-externals
• --bundled-only
• add your idea in the comments

new option MUST imply --omit dev

new option MUST be disabled bu default
new option MUST be marked as experimental in help page
new option might set `--mc-type=library'

Describe alternatives you've considered

• we could make it, so that the existing option `--mc-type=library' causes this behaviour by default, but that would be a breaking change

Additional context

for libraries, non-bundled components are "external" - this is discussed in specification#321

package.json knows the concept of

• dependencies
• bundleDependencies - definitely shipped
• peerDependencies - definitely external
  • they can be optional, in addition. example:

    "peerDependenciesMeta": {
      "webpack-cli": {
        "optional": true
      }
    }
    

• devDependencies - no intention to be shipped.
  might shadow all of the above on build-time

Contribution

• I am willing to provide an implementation
• I will wait until somebody else implements it

[jkowalleck]

this ticket is currently only an idea.
please add comments, to discuss the idea.

[jkowalleck]

this feature should implicitely fix #1155

[MalickBurger]

I think this could be a great new feature and I may be able to help out in the future implementing it. I think --bundled-only is a good option.

[jkowalleck]

I think this could be a great new feature and I may be able to help out in the future implementing it. I think --bundled-only is a good option.

thats cool.
Anyway, this feature depends on an enhancement of the CycloneDX core spec, so it is not ready, yet.

FYI:
the respective feature depends on CycloneDX core enhancement CycloneDX/specification#321 - which was accepted by the CycloneDX community (any downstream user) by silent consensus on CycloneDX/specification#586. NEvertheless, it helps to show your support by reviewing the PR, commenting and giving thumps-up on the respective PR and ticket.
THe CycloneDX core enhancement request got promoted to be reviewed by Ecma Technical Comity 54. The core enhancement needs to pass the Ecma TC-54, who will get together in some days.
The core enhancement might then be part of CycloneDX 1.7 - which is planned for June 2025, and might be implemented in the https://github.com/CycloneDX/cyclonedx-javascript-library, then.
And after that, it can be used to implement this very feature.
All of this is in accordance with

• https://cyclonedx.org/participate/contribute/
• https://cyclonedx.org/participate/working-groups/
• https://cyclonedx.org/participate/standardization-process/
• https://cyclonedx.org/participate/tc54/