Handling shifts in alias support

[bretg]

Type of issue

Enhancement

Description

Recently #12215 attempted to pull an alias out into a standalone adapter. In a few months, Magnite is going to release a significant upgrade to the 'rubicon' adapter that some publishers will want to test in a transitionary way.

I propose that PBJS should have documented conventions for supporting both of these types of changes.

A first step would be define how does the system work right now if the same biddercode could be interpreted in different ways. i.e. what happens when:

• as both a base adapter biddercode and a "hardcoded" alias in another adapter?
• as "hardcoded" aliases for two separate base adapters?
• as both a "softcoded" alias (i.e. pbjs.aliasBidder) and a different base adapter biddercode?
• as both a "softcoded" alias and a "hardcoded" alias?
• as separate-but-conflicting softcoded aliases?

Not sure we've ever explicitly defined what should happen in these scenarios, but we probably should.

Minimally, the goal here is to define what bidders should do to make changes as easy as possible for publishers. If the ideal requires breaking changes, then we should put it on the list for 10.0.

Below are some thoughts on transitioning between base adapter biddercodes and aliases.

Aliased biddercode converted to a standalone base adapter

This uses the scenario in #12215 as an example. That is was withdrawn as a PR doesn't change the likelihood that a future bidder will probably want to make a similar change.

Time 1

1. The publisher's adunits refer to dichange as a bidder
2. The publisher has built their PBJS package with digitalmatterBidAdapter.js where dichange is an alias. Life is good.
3. Note that if digitalmatterBidAdapter.js stops listing dichange as an alias, the publisher would be forced to change their build, causing a breaking change.

Time 2

1. The publisher's adunits still refer to dichange as a bidder
2. The publisher has built their PBJS package with both dichangeBidAdapter.js AND digitalmatterBidAdapter.js where dichange is an alias. Prebid.js picks one of them (preferably dichange). digitalmatterBidAdapter might be wasted bytes in the package, but otherwise, life is ok. Yes, the request is now being processed by a different adapter, but that's fine because clealry the publisher started including the new adapter explicitly in their build. They must know what's going on.

Time 3

The publisher's adunits still refer to dichange as a bidder
The publisher has built their PBJS package with just dichangeBidAdapter.js. Life is good.

Formerly standalone biddercode converted to an alias in a new base adapter

This is a thing that Magnite is going to do this next year.

Time 1

1. The publisher's adunits refer to rubicon as a bidder.
2. The publisher has built their PBJS package with just rubiconBidAdapter.js. Life is good.

Time 2

1. The publisher's adunits still refer to rubicon as a bidder.
2. The publisher has built their PBJS package with BOTH rubiconBidAdapter.js and magniteBidAdapter.js which also aliases rubicon. PBJS chooses the base adapter. Life is ok - the Magnite adapter isn't being utilized at this point.

Time 3

1. The publisher's adunits still refer to rubicon as a bidder.
2. The publisher has built their PBJS package with BOTH rubiconBidAdapter.js and magniteBidAdapter.js which also aliases rubicon.
   3. The publisher is ready to try the new Magnite-based rubicon, so they call pbjs.aliasBidder('magnite', 'rubicon', override=TRUE)
3. PBJS sees this explicit signal and invokes 'magnite' for adunits that refer to rubicon.
4. Life is good.

Time 4

1. The publisher's adunits still refer to rubicon as a bidder.
2. The publisher has built their PBJS package with only magniteBidAdapter.js which aliases rubicon.
3. PBJS only sees rubicon as an alias of magnite, so life is good.

tldr
3.3 is the outstanding development requirement

[dgirardi]

"Hardcoded" aliases overwrite the previous alias if it has the same name
"Softcoded" aliases - have no effect besides a warning if the alias already exist

So all of these:

as both a base adapter biddercode and a "hardcoded" alias in another adapter?
as "hardcoded" aliases for two separate base adapters?
as both a "softcoded" alias (i.e. pbjs.aliasBidder) and a different base adapter biddercode?
as both a "softcoded" alias and a "hardcoded" alias?

would have the alias point to the adapter that loaded last (either as the "actual" bidder or as a "hardcoded" alias). and this:

as separate-but-conflicting softcoded aliases?

would point to what specified by the first aliasBidder call.

[patmmccann]

Conclusion:

pbjs.aliasBidder('magnite', 'rubicon', override=TRUE) is called, the override succeeds
pbjs.aliasBidder('magnite', 'rubicon') is called a warning is generated
if an adapter declares itself to be an alias of something that already exists, also generate a warning