New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add useBuiltIns and useESModules options to transform-runtime #5442

Merged
merged 4 commits into from Mar 15, 2017

Conversation

Projects
None yet
6 participants
@Kovensky
Member

Kovensky commented Mar 10, 2017

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.

Add useBuiltIns and useESModules options to transform-runtime
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.
@mention-bot

This comment has been minimized.

mention-bot commented Mar 10, 2017

@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

This comment has been minimized.

Collaborator

babel-bot commented Mar 10, 2017

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.

@codecov

This comment has been minimized.

codecov bot commented Mar 10, 2017

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

This comment has been minimized.

codecov bot commented Mar 10, 2017

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

This comment has been minimized.

Member

hzoo commented Mar 10, 2017

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

This comment has been minimized.

Member

hzoo commented Mar 10, 2017

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

@xtuc

This comment has been minimized.

Member

xtuc commented Mar 10, 2017

Could we add it as a snapshot in the tests?

@Kovensky

This comment has been minimized.

Member

Kovensky commented Mar 11, 2017

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.

function buildRuntimeRewritePlugin(relativePath, helperName) {
return {
pre: function (file) {
var original = file.get("helperGenerator");
file.set("helperGenerator", function(name) {
// make sure that helpers won't insert circular references to themselves
if (name === helperName) return;
if (name === helperName) return false;

This comment has been minimized.

@loganfsmyth

loganfsmyth Mar 15, 2017

Member

Why false?

? `export { default } from \"./${helperName}.js\";`
: "module.exports = require(\"./" + helperName + ".js\");";
writeFile(`${dirname}_${helperAlias}.js`, content);
if (helperAlias !== helperName) writeFile(`${dirname}${helperAlias}.js`, content);

This comment has been minimized.

@loganfsmyth

loganfsmyth Mar 15, 2017

Member

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 comment has been minimized.

Member

loganfsmyth commented Mar 15, 2017

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

This comment has been minimized.

Member

hzoo commented Mar 15, 2017

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

@Kovensky

This comment has been minimized.

Member

Kovensky commented Mar 15, 2017

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.

@Kovensky Kovensky merged commit 2c0907a into 7.0 Mar 15, 2017

4 of 5 checks passed

codecov/patch 70% of diff hit (target 85.41%)
Details
ci/circleci Your tests passed on CircleCI!
Details
codecov/project 85.79% (+0.37%) compared to 01b250a
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@Kovensky Kovensky deleted the babel-runtime-with-builtins branch Mar 15, 2017

@hzoo hzoo referenced this pull request Apr 7, 2017

Closed

Standalone babel helpers #5601

@gaearon gaearon referenced this pull request May 27, 2017

Closed

Babel 7 Umbrella #2391

0 of 3 tasks complete

@Timer Timer referenced this pull request Sep 25, 2018

Merged

Turn on Babel `helpers` #5093

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment