Support Babel-compiled code
See original GitHub issueBabel-compiled code depends on a big drop-in polyfill bundle.
It would be nice if people could just use polyfill.io instead. But currently polyfill.io does not satisfy all the requirements.
afaict, this is what we would need to do:
I’m basing this on info from Babel’s caveats page and a comment from a Babel committer.
NB. We’d also need to add all the ES6 collection classes (separate issue here) for more complete ES6 support, but these aren’t actually required by Babel’s internal mechanics in the way that Array.from() and Symbol are.
more info
The existing babel polyfil bundle comprises:
- the whole of core-js/shim
- the runtime for Facebook’s regenerator
- (n.b currently they are using their own fork of this, but they are planning to switch to the original)
Technically the regenerator runtime is not a polyfill. It doesn’t actually make generators work (generators are unpolyfillable due to syntax). It just supports Babel’s compilation output for source code that included generators. I don’t think we should worry too much about this. I think the ideal situation would be: “You don’t need Babel’s polyfill bundle if you’re using polyfill.io, but you do still need to drop in Facebook’s regenerator runtime if you’re using generators.”
Issue Analytics
- State:
- Created 8 years ago
- Comments:6 (3 by maintainers)

Top Related StackOverflow Question
Closing this issue since the features requested are now implemented. If you find an application which uses babel and doesn’t work using our polyfills please create a new issue covering the specific case.
We should take one of our applications which use babel and replace core-js polyfill with polyfill-service and see if it works.