feat: enhance package.json finder

[reey]

implements #1284

For assets loaded from a subdirectory of node_modules, it will pick the first package.json that actually has name and version attributes.
Added a testcase for this, which verifies this functionality for the luxon and libphonenumber-js packages.
The package.json for libphonenumber-js/max misses a version number while for luxon the name is missing.

The snapshot has quite a lot of changes:

• For some reason the purl entries are no longer url encoded.
• The @apollo/client/* entries have been merged into a single @apollo/client entry
• The @babel/runtime was added as dependency

[jkowalleck]

Thanks for the implementation, @reey .

I really like the solution, but it needs to be safe and waterproof.
The thing with the "enhancement" you plan on introducing is: it opens up for a whole world of false-positives and edge cases.
Let's take the time and make sure it meets the needed edge cases. :-)

For additional tests, we need to have a

• yarn2 setup with the edge case s in unplugged mode
• yarn2 setup with the edge cases in non-unplugged (cached) mode
• yarn2/pnp setup with the edge case s in unplugged mode
• yarn2/pnp setup with the edge cases in non-unplugged (cached) mode
• all edge cases with pnpm ... dont knwon what exists, there
• all edge cases with "external" linked-in paths ... have fun figguring out what edge cases might exists there ...

[reey]

@jkowalleck Thanks for the feedback.
I've done some testing with yarn, but it should not be any different as the (folder) structure still has a node_modules directory:
/home/<user>/.yarn/berry/cache/libphonenumber-js-npm-1.11.3-8309751739-10c0.zip/node_modules/libphonenumber-js/build/legacy.

The overall idea was if there would be no node_modules for some package manager, to not change the behavior from how it currently works.
In case changes are required for a specific package manager, this could still be done.

Regarding the URL encoded purls it seems that the behavior is different for windows vs linux? is this intended?

[jkowalleck]

@reey, your implementation looks solid, your test beds are great!
a thing that might be missing:
add a lock file to the yarn test bed, and add a yarn set version ... before the yarn install happens for the test beds.

[jkowalleck]

all looks good,
i will fix the yarn situation in another branch (#1265)
first, and will merge your feature afterward.

[jkowalleck]

why?

[reey]

Had some issues there on my windows machine..
Reverted that

[reey]

FYI, this was the issue on windows:

npm run build

> @cyclonedx/[email protected] build
> run-p --aggregate-output -l build:*   

[build:node] 
[build:node] > @cyclonedx/[email protected] prebuild:node
[build:node] > node -r fs -e 'fs.rmSync("dist",{recursive:true,force:true})'
[build:node] 
[build:node] 
[build:node] > @cyclonedx/[email protected] build:node
[build:node] > tsc -b ./tsconfig.json
[build:node]
[build:node] node_modules/@types/node/globals.d.ts(72,13): error TS2403: Subsequent variable declarations must have the same type.  Variable 'AbortSignal' must be of type '{ new (): AbortSignal; prototype: AbortSignal; abort(reason?: any): AbortSignal; timeout(milliseconds: number): AbortSignal; }', but here has type '{ new (): AbortSignal; prototype: AbortSignal; }'.
ERROR: "build:node" exited with 1.

[jkowalleck]

ah, thanks, might add a windows CI/CT to have this coverred:
#1292

[jkowalleck]

Thanks for the contribution,
it was released via https://github.com/CycloneDX/cyclonedx-webpack-plugin/releases/tag/v3.12.0