Support option to set polyfills

Describe the feature you’d like I know you are inclined to not include polyfills directly and prefer to leave it to consumers of this library to define any necessary polyfills. This is fine for consumers who can control which polyfills are set on the page. But this poses a problem for CMPs using your library that have less control over the polyfills a publishers includes on their page.

Currently, the only option seems to be to have our CMP define global polyfills. This is not the preferred approach. Libraries should not set global polyfills affecting code outside of the library.

Option 2 would be for the iabtcf library to include polyfills directly. This would increase the size of the iabtcf library and may not be desired by everyone.

Option 3 (my feature request) is to expose a way for consumers to provide polyfills to the iabtcf library. For example, the consumer code to pass in polyfills might look like

import {Polyfills} from '@iabtcf/core';
import Map from 'es6-map/implement';

Polyfills.Map = Map;

and the iabtcf code would use Polyfills.Map if it exists else default to the globally available Map.

From my testing, the polyfills required for IE 10+ compatibility include

• Promise
• Map
• Set
• Symbol
• Array.includes - only used a few times in the core. Perhaps this could be replaced with indexOf to avoid compatibility issues with IE.

[nealrosen04]

I have not been able to get @babel/runtime to work. It seemed to work to inject polyfills into my own source code, but didn’t seem to update anything in this library, possibly because this library code is in my node_modules instead of my src directory. Some online documentation suggested this should still be able to work, but I wasn’t able to figure it out before having to put it aside for some other priorities.

[pycnvr]

@chrispaterson Yes, I did some experiments with plugin-transform-runtime. My understanding is that there are two approaches. If the tcf libs are built with it, then tcf libs should specify @babel/runtime as a peer dependency. The client code then also add @babel/runtime as a dependency, and there is no need for babel to parse tcf again during client build. The downside is that client must also use plugin-transform-runtime instead of another polyfill such as the ones in preset-env. However, if tcf libs aren’t built with plugin-transform-runtime to begin with, then the approach above is still needed so babel can fix up codes.