Hi there,
I'm looking to add the above feature through a fork/pull-request and would like some guidance
I intend to add the ability for hub-detect to generate some bdio information from the output of the 'yarn list' command. To make this whole process easier, I thought I'd open a dialogue early to get your advice/recommendations/guidance.
Expected behavior
Take an argument (e.g. --detect.yarn.prod.only=true) and return/send bdio files to Black Duck
Actual behavior
Currently the tool only seems to support yarn.lock parsing, which is a bit over-zealous for external distribution projects
Having edited some of the code myself, I think I have a reasonable idea of the best way to achieve this, but would like some feedback from recent/regular contributors here. (CC: @ekerwin, @bamandel, @JakeMathews, etc)
Which data structure should be used to grab the CLI output?
I was trying to build a DependencyGraph, as is done in YarnPackager.groovy. There it is done through NameVersionNode objects. Is this the preferred way to build a parent-child data structure internally to hub-detect? Some detail here would be appreciated... This is best done through NVNBuilder? Is there a specific order in which linking should take place (parents added to root, then children to parent, or children to parent then parent to root? Does it matter?)? I assume grandchildren can be associated quite easily to existed parent-child relationships?
I also tried to use Dependency objects add them directly to a MutableDependencyGraph, but it seems this class is impossible to unit-test as it stands.
This would be my preferred method (making a simultaneous pull-request on integration-bdio for testability) but would this leave the resulting DependencyGraph without any essential information (e.g. linking data)?
Thanks for taking my bombardment of questions 😄 I'm just trying to open a dialogue because I would like to take a route you would prefer/expect (and I've gotten a bit lost in the data structures used for bdio 😏)
-- Jake