Ordinarily, developers have to identify and manage the polyfills they need. This is where Polyfill.io comes in. Polyfill.io uses user-agent sniffing to return only the polyfills that the requesting browser needs. Polyfill.io is built and maintained by a community of developers led by Origami.
All documentation for Polyfill.io is available at Polyfill.io.
Polyfilling things twice will give unpredictable results and is likely to lead to bugs in the browsers that use those polyfills. To avoid conflicts, where possible, you should only use polyfills from a single source.
If you want to use a polyfill that isn’t provided by Polyfill.io, you should not use the default set from Polyfill.io as this can lead to conflicts. These conflicts are especially common for ES6 features while Polyfill.io brings in polyfills for these new language features.
Currently, babel implicitly loads core-js polyfills for symbol even when you ask it not to. To avoid this, use this microlibrary.
Origami Build Tools and the Build Service both include some polyfills from core-js which conflict with the Polyfill.io’s default set. Until we remove these conflicting polyfills from Origami’s tools (when Polyfill.io can provide the same coverage for ES6 as offered in core-js) this will continue to be a problem.
Right now, the conflict exists with
Set polyfills. If you are using these features, there are two possible solutions:
In OBT you can exclude all the Babel polyfills by setting a the
babelRuntime flag eg
obt build --babelRuntime=false
You can exclude all core-js polyfills from the Build Service using
?polyfills=none. See the Build Service documentation for more information.