The babel-polyfill and babel-runtime modules are sued to serve the same function in two different ways. Both modules ultimately serve to emulate an ES6 environment.
Both babel-polyfill and babel-runtime emulate an ES6 environment with two things:
a slew of polyfills as provided by
core-jscomplete generator runtime
babel-polyfill accomplishes this task by assigning methods on the global or on native type prototypes which means that once required, as far as the javascript runtime you’re using is concerned, ES6 methods and object simply exist. If you were to require babel-polyfill in a script run under node v0.1.0 – a runtime which does not natively support the Promise API – your script would then have access to the Promise object. As far as you are concerned, you’re suddenly using an environment that support the Promise object.
babel-runtime does something very similar, but in a way that does not pollute native object prototypes or the global namespace. Instead, babel-runtime is a module that you can list as a dependency of your application like any other module, which polyfills ES6 methods. In other words and continuing the example from above, while you may not have the Promise object available to you, you now have the same functionality available to you from require('babel-runtime/core-js/promise'). By itself, this is useful but inconvenient. Fortunately, babel-runtime is not intended to be used by itself. Rather, babel-runtime is intended to be paired with the transform – babel-plugin-transform-runtime – which will automatically rewrite your code such that you can write your code using the Promise API and it will be transformed to use the Promise-like object exported by babel-runtime
babel-polyfill offers you the conveniences of gloablly defined objects without having to transform your code further. However, as with anything that mutates a global, this can introduce collision between versions, etc.
babel-runtime, on the other hand, will not suffer from collision as everything is name-spcaed. Since the module will be defined in your package.json, it can be versioned like everything else. The tradeoff, however, is that a transform can only do so much. The runtime remaps methods according to a definitions map. Anecdotally, this has covered each of my use-cases but there may be an obscure method or two which is not remapped. There are also certain cases where your intent is ambiguous. In such cases, the transform won’t know exactly what to do.
Conclusion
To summarize, with the general case for Babel 6, there are two main steps you’ll need to perform:
- Provide your code with an emulated ES6 environment by either requiring
babel-polyfillor requiring thebabel-runtimemodule plus thebabel-plugin-transform-runtimetransform:
1 | // for babel-polyfill, either add: |
