fix(npm): prevent workspace hoisting and ignore npm ls errors during BOM generation

[Rykee]

Problem

When npmExecuteScripts generates a CycloneDX BOM for npm workspace projects on Node 24 / npm v11+, it fails with ELSPROBLEMS exit code 254.

Two issues combine to cause this:

1. Extraneous packages (workspace + npm v11+): cyclonedx-npm is installed via npm install --prefix ./tmp, but npm hoists its native dependencies (@emnapi/core, @napi-rs/wasm-runtime, etc.) into the workspace root node_modules. On npm v11+ (Node 24), npm ls exits non-zero on ELSPROBLEMS. Non-workspace projects are unaffected since hoisting doesn't occur outside a workspace context.

2. Invalid packages (workspace + npm overrides): Packages overridden via npm overrides for security fixes are reported as invalid by npm ls because the installed version doesn't exactly match what the dependent package declared. This is a structural consequence of npm overrides and cannot be avoided without removing the security fix.

Both cause cyclonedx-npm to fail fatally since it treats any npm ls non-zero exit as fatal.

Fix

• Add --no-workspaces to the install command to prevent hoisting. No-op for non-workspace projects.
• Add --ignore-npm-errors to the run command to tolerate npm ls warnings in workspace setups with overrides.

Testing

Reproduced the failure locally using the exact SAP Docker image (node:24.16.0, npm 11.13.0) and verified both flags together fix it — exit code 0 and BOM generated successfully. Unit tests updated and passing.

Question

@cyclonedx/cyclonedx-npm is pinned to 2.1.0 while the latest is 6.0.0. We tested 6.0.0 with just --ignore-npm-errors (no --no-workspaces needed) and it also works. Is there a reason for staying on 2.1.0? If upgrading is welcome, the fix could be simplified to just the version bump + --ignore-npm-errors. Happy to submit a follow-up or update this PR.

[cla-assistant]

All committers have signed the CLA.

[anilkeshav27]

i can also include one more use case where --ignore-npm-errors make sense when using yarn.lock, since yarn is used for installing dependencies and cyclonedx is using npm there are descrepancies how they both resolve depdencies e.g

yarn.lock
lodash@4.17.23, lodash@4.18.1, lodash@^4.17.10, lodash@^4.17.15, lodash@^4.17.2, lodash@^4.17.20, lodash@^4.17.21, lodash@^4.17.23, lodash@^4.18.1:

and this works fine since yarn resolves this to highest version and uses lodash@4.18.1 and also brings this in node_modules, but npm ls will complain as it sees a fixed version lodash@4.17.23 and then complains it is not installed

npm error code ELSPROBLEMS
  npm error invalid: lodash@4.18.1

since sbom is generated after the dependency installation we can ignore these ELSPROBLEMS and any dependencies problems are be caught earlier during dependency installation