Unable to use spread operator/Set object

[jsnellbaker]

@mkalafior

Within the recent updates for Justpremium 1.0 adapter (see #1881), the spread operator and the Set object are used within the BuildRequests method. We recently discovered this type of implementation is causing issues in certain scenarios.

Can you remove these references to spread/Set and implement an alternative approach that would still suite the needs of that part of the code?

[mkendall07]

FYI will need to remove your adapter by tomorrow if this isn't resolved to get to a clean build

[mkalafior]

@jsnellbaker i would be grateful if you can explain what exactly is the problem or just point to some examples.

@mkendall07 I will update the code today. No need to remove our adapter :)

[mkendall07]

Thanks for the quick response!

[jsnellbaker]

@mkalafior
As part of our build process, the code is ran through a transpiler so that it it's able work across a variety of browser versions. These particular spread/set operators were throwing several errors during our testing process of the transpiled code and were preventing the build from going through; it seems these operators are not supported in IE and Safari browsers.

Below is the only line of code I found in the adapter that would need to be adjusted:

buildRequests: (validBidRequests) => {
...
const payload = {
      zone: [...new Set(validBidRequests.map(b => {

I hope this helps.

[mkalafior]

@jsnellbaker thanks for explanation. I need to say that I'm surprised that transpiler is not able to handle this. We use such construction in multiple project transpiled by webpack + babel and never noticed any problems.

Regarding the code highlighted by you, the fix for it was sent in #1895.

[mkendall07]

@mkalafior
This is a bit of a hot topic but basically the reason you can't use a number of ES6 constructs is because of requiring the use of poly-fills that pollute the global namespace. This is not something we think Prebid.js should be doing - as it's dropped into various different environments and we don't want to cause side effects. Additionally this adds considerable weight to the build.

so we make the best decision for trade off of usability of ES6 vs compiled library size. Hope that helps clarify.

[mkendall07]

Also - we are exploring ways to catch these issues before merges happen. We are looking at having a build pipeline into travis-ci that would catch it and fail the build. Thanks

[mkalafior]

Thanks @mkendall07, this explains everything.