Skip to content
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

Using @babel/runtime-corejs2 and @babel/runtime-corejs3 leads to larger bundle sizes #9853

Open
GeorgeTaveras1231 opened this Issue Apr 12, 2019 · 4 comments

Comments

Projects
None yet
3 participants
@GeorgeTaveras1231
Copy link

commented Apr 12, 2019

Bug Report

Current Behavior
When configuring @babel/plugin-transform-runtime to use corejs2 or corejs3, bundle sizes increase x7 (corejs2) and x11 (corejs3)

Input Code

const obj = {
  a: 1,
  b: 2,
};

const { b, ...rest } = obj;
const newObj = {...rest, a: b };

Expected behavior/code
I expect that the bundle sizes stay relatively close, when switching from @babel/runtime to @babel/runtime-corejs2 or @babel/runtime-corejs3

Babel Configuration (.babelrc, package.json, cli command)

Configs to use @babel/runtime

module.exports = {
  presets: [
    ["@babel/preset-env", {
      modules: false,
      useBuiltIns: 'usage',
      corejs: 3
    }]
  ],
  plugins: [
    "@babel/plugin-transform-runtime"
  ]
}

Configs to use @babel/runtime-corejs2

module.exports = {
  presets: [
    ["@babel/preset-env", {
      modules: false,
      useBuiltIns: 'usage',
      corejs: 2
    }]
  ],
  plugins: [
    ["@babel/plugin-transform-runtime", {
      corejs: 2
    }]
  ]
}

Configs to use @babel/runtime-corejs3

module.exports = {
  presets: [
    ["@babel/preset-env", {
      modules: false,
      useBuiltIns: 'usage',
      corejs: 3
    }]
  ],
  plugins: [
    ["@babel/plugin-transform-runtime", {
      corejs: 3
    }]
  ]
}

Environment

  • Babel version(s): 7.4.3 (all babel packages)
  • Node/npm version: Node v10
  • OS: OSX 10.13.6
  • Monorepo: no
  • How you are using Babel: CLI, Webpack loader

Possible Solution

N/A

Additional context/Screenshots
Add any other context about the problem here. If applicable, add screenshots to help explain.

Repro repo: https://github.com/GeorgeTaveras1231/corejs-size-regression-repro

Snapshot:

Screen Shot 2019-04-12 at 11 41 52 AM

@babel-bot

This comment has been minimized.

Copy link
Collaborator

commented Apr 12, 2019

Hey @GeorgeTaveras1231! We really appreciate you taking the time to report an issue. The collaborators
on this project attempt to help as many people as possible, but we're a limited number of volunteers,
so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack
community
that typically always has someone willing to help. You can sign-up here
for an invite.

@zloirock

This comment has been minimized.

Copy link
Member

commented Apr 12, 2019

At least, you should not use together useBuiltIns option of preset-env and corejs option of transform-runtime.

However, it's not the main reason for increasing the size of the bundle. objectWithoutProperties helper for the "rest" operator internally use Object.getOwnPropertySymbols method, so runtime should load full Symbol polyfill for that. In those helpers also used some other methods which should be polyfilled. So it's expected.

@GeorgeTaveras1231

This comment has been minimized.

Copy link
Author

commented Apr 12, 2019

@zloirock I understand that objectWithoutProperties leads to loading of the full Symbol polyfill, but does that only happen in @babel/runtime-corejs2&@babel/runtime-corejs3. If so, then that may justify the bundle size increase; otherwise, it's still not clear to me what is causing it.

@zloirock

This comment has been minimized.

Copy link
Member

commented Apr 12, 2019

In your example, without @babel/runtime-corejs2 / @babel/runtime-corejs3 it just will not work in old engines because for injection required polyfills by useBuiltIns you should transpile helpers in @babel/runtime.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.