PBjs Core - Build Related : alias dependencies tree

[GeneGenie]

Type of change

• [x] Build related changes

Description of change

I was trying to build a feature to match bidderCodes and aliases to bidAdapter names to pre-validate common format, and build an alias-adapter dependency tree, so the final result after all transformations would be a map with aliaseNames and bidderCodes as keys, and real adapter file name.

First try

i was trying to import ESM bid adapters modules to node code, but didn't succeed with various ideas. Eventually I admitted the need of compilation step, for it to be either nodejs app with tones of window mocks, or reuse existing bundling process with webpack and run in FE env using karma.

Solution

i think that funcs speak for themselfs but:

1. grab all bidAdapters from dir
2. compose import statements as code + compose runtime vars loggers code
3. write "fake" test file
4. run fake test file through karma and webpack
5. scrape produced logs

(forked node process needs to be muted to be able to handle logs)

Running

node discoverPrebidAdapters.js

Final thoughts

So the code is still somewhat dirty, i have some improvents for it, but i'd like to clarify is this a right way to move or i missed some tools?

Thank you

PS Future plans:

1. Import adapter manager to scan registered bidders, instead of wildcard imports
2. match and parse md file docs from prebid.io repo
3. automate doc validation/generation
4. check for truth about required params, using proxy objects ?

PPS: does anyone know how to pass data from browser env to node env through karma in more elegant way? =)

[GeneGenie]

Some history: i already had such process, but built with AST tree processing, to resolve bidderCode value, tracking up all valriables etc. But it was hard to maintain without good expertise in code processing (skill issues). And adapters introduce new ways to define code and aliases, so static code analysis is not helpfull anymore. EG: https://github.com/prebid/Prebid.js/blob/master/modules/admixerBidAdapter.js#L21 https://github.com/prebid/Prebid.js/blob/master/modules/kargoBidAdapter.js#L9 (and others)

So I think such tool may provide more reliable data about the lib dependencies runtime. Handy

Or maybe we could enforce eslint rule to use only static values for aliases and codes, to "increase clarity" but not an expert here neither

[bretg]

@GeneGenie - are you aware that the docs repo has a mapping of adapter code to aliases? This was recently surfaced in the bidder CSV file https://docs.prebid.org/dev-docs/bidder-data.csv -- not sure if it's helpful for your purposes, but it's certainly related.

[dgirardi]

I am hesitant about this - what is it going to be used for?

match and parse md file docs from prebid.io repo automate doc validation/generation

for these it would make more sense to extract aliases into something that is easy to parse statically and acts as the sole source of truth. For example, we could have a aliases.json somewhere, and have both the JS and the docs build pick it up to generate adapter aliases / documentation aliases.

[patmmccann]

Hi @genegenie

Could you answer questions on the utility of this code above? It isn't obvious how it improves over the resource @bretg mentions

[patmmccann]

Declining as stale