Add useBuiltIns and useESModules options to transform-runtime

[Jessidhia]

useBuiltIns uses versions of the helpers that do not import even
internal polyfills from core-js.

useESModules uses versions of the helpers that do not go through
transform-es2015-modules-commonjs. This allows for smaller builds in
module systems like webpack, as it doesn't need to preserve commonjs
semantics.

This includes changes to the babel-runtime build-dist script, which
will build the versions of the runtime helpers to be used by
combinations of useBuiltIns and useESModules.

This is untested other than by looking at the output and seeing if it makes sense >_<

{ polyfill: false, useBuiltIns: true, useESModules: true } will be perfect for webpack/rollup
users that want to deduplicate helpers without accidentally bundling an extra
core-js when babel-polyfill is already in use, or when, say, targeting electron.

[mention-bot]

@Kovensky, thanks for your PR! By analyzing the history of the files in this pull request, we identified @gaearon, @hzoo and @zertosh to be potential reviewers.

[babel-bot]

Hey @Kovensky! It looks like one or more of your builds have failed. I've copied the relevant info below to save you some time.

• Node v4 - linux

[codecov]

Codecov Report

Merging #5442 into 7.0 will decrease coverage by 0.03%.
The diff coverage is 10%.

@@            Coverage Diff             @@
##              7.0    #5442      +/-   ##
==========================================
- Coverage   85.46%   85.42%   -0.04%     
==========================================
  Files         203      203              
  Lines        9533     9537       +4     
  Branches     2703     2706       +3     
==========================================
  Hits         8147     8147              
- Misses        899      900       +1     
- Partials      487      490       +3

Impacted Files	Coverage Δ
...ckages/babel-plugin-transform-runtime/src/index.js	70.76% <10%> (-4.65%)	❌

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 12eb25c...8dc2176. Read the comment docs.

[codecov]

Codecov Report

Merging #5442 into 7.0 will increase coverage by 0.37%.
The diff coverage is 70%.

@@            Coverage Diff             @@
##              7.0    #5442      +/-   ##
==========================================
+ Coverage   85.41%   85.79%   +0.37%     
==========================================
  Files         203      203              
  Lines        9525     9842     +317     
  Branches     2703     2832     +129     
==========================================
+ Hits         8136     8444     +308     
- Misses        902      909       +7     
- Partials      487      489       +2

Impacted Files	Coverage Δ
...ckages/babel-plugin-transform-runtime/src/index.js	80% <70%> (+4.59%)	✅
...kages/babel-core/src/transformation/file/logger.js	40.54% <0%> (-6.13%)	❌
...bel-plugin-transform-es2015-classes/src/vanilla.js	90.59% <0%> (+0.42%)	✅
packages/babel-traverse/src/path/context.js	87.06% <0%> (+0.86%)	✅
.../transformation/file/options/build-config-chain.js	96.1% <0%> (+2.22%)	✅
.../src/transformation/file/options/option-manager.js	86.7% <0%> (+3.22%)	✅
packages/babel-traverse/src/path/replacement.js	77.39% <0%> (+3.94%)	✅
...ckages/babel-core/src/transformation/file/index.js	90.37% <0%> (+5.62%)	✅

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 01b250a...752788f. Read the comment docs.

[hzoo]

Maybe we should actually add the generated files to git so we can actually compare what's happening.. Don't know how we can write tests

[hzoo]

Yeah it would be nice if we could diff previous code or diff the options somehow

[xtuc]

Could we add it as a snapshot in the tests?

[Jessidhia]

I tried committing the files to git, but it would end up creating a huge commit adding 300+ files, and at least 4 of them would need to be updated every single time a helper got changed 😢

I added fixtures for the transform-runtime output, but no idea how babel-runtime could be tested. Any exec test that would pass with transform-runtime would also pass without using transform-runtime at all, and it's not possible to exec-test the useESModules output.

[loganfsmyth]

Why false?

[loganfsmyth]

We should really kill all these aliases in 7.x. If you're up for it, maybe a PR another this one? Let's keep this separate so if we want to backport it is easier.

[loganfsmyth]

This looks awesome to me. The only case that comes to mind is that it's unfortunate people using useBuiltins still have to depend on core-js even though they aren't using it.

Let's land this as-is, but it might be good for us to think about if we want to explore making a separate module for "only helpers" and one for "helpers with polyfill" or something.

In the long run I'd love to have the helpers currently living in babel-helpers instead live inside their respective plugins, which would allow us to repurpose babel-helpers. It's a clear name for something like that.

[hzoo]

preset-env's useBuiltIns option outputs core-js which isn't very intuitive so it would be nice for polyfill to just have the modules. Would the transform easier too cc @zloirock

[Jessidhia]

Yeah, I took the useBuiltIns name from preset-env.

@loganfsmyth the point of useBuiltIns is specifically to not depend on core-js and just use whatever is in the environment, but I wouldn't be surprised if some helpers only work with either native or core-js's implementation.

EDIT: oh, you mean literally the npm dependency, rather than the runtime dependency.