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

Babel-polyfill file-size, using in webpack #163

Closed
NXTaar opened this Issue Nov 22, 2015 · 21 comments

Comments

Projects
None yet
@NXTaar
Copy link

NXTaar commented Nov 22, 2015

Hello, i need some help with the Webpack configuation. I'm using Babel 6, and i think i'm doing something wrong...

In my project, in most of cases, i need async/await and Promise functionality, so here is my Webpack config for Babel

Loaders part

loaders: [
            {
                // ES6 & 7 to ES5 transpiller (polyfills)
                loader: "babel-loader",

                // Skip any files outside of your project's `src` directory
                exclude: [
                    path.resolve(__dirname, "node_modules"),
                ],

                // Only run `.js` and `.jsx` files through Babel
                test: /\.jsx?$/,

                // Options to configure babel with
                query: {
                    presets: ['es2015', 'stage-0']
                }
            },
            //... bla bla bla

Entry point part

entry:
    {
        common: "babel-polyfill",
        App: './app'
    },

With such config i'm getting the needed functionality, and it works fine.
BUT!
if we look to the compiled files we will see this:

C:\Projects\Work\FPB\2.0>webpack
Hash: 9877443dac97580f5531
Version: webpack 1.12.8
Time: 1270ms
    Asset       Size  Chunks             Chunk Names
   App.js    10.9 kB       0  [emitted]  App
   1.1.js  867 bytes       1  [emitted]
common.js     450 kB       2  [emitted]  common
    + 194 hidden modules

So, as i understood, my common.js (i'm using CommonsChunkPlugin) is containig the babel-polyfill file and it weights 450kb!! Is it normal for such file size?
So i was digging deeper, and run webpack as webpack --display-modules, and i saw this:
https://gist.github.com/NXTaar/06df116dd2210cdcc060

We have here, that my bundle was including a lot of fuctions, which i, actially, don't need at all (for example some es6.math.log10.js and etc.) and, as i understood, all this modules is required by babel-polyfill.

Is it a way to compile only those, which i'm using in my project right now (f.e. async, await, Promise, or some more, if i decide to use additional ES6 features).

I tried to use Babel 5, because it was compilling only needed thing, but i can't config it proper for async/await. It gave me an error, when it tries to work in browser.

Any help, or an advice, would be appreciated.

And if your sugjestion will be use Babel 5 please tell me why i should do that (i need to understand all stuff, for preventing more questions in the future 😊 ), give me proper webpack config (loader, entry points, plugins, etc.), and all ``npm install` statements needed, for i can get my async/await and Promises to work, because i couldn't do it myself

@zloirock

This comment has been minimized.

Copy link
Member

zloirock commented Nov 22, 2015

weights 450kb

You definitely doing something wrong. Normal size after compression ~50-60kb.

If you need only part of polyfills - use commonjs core-js api.

@Couto

This comment has been minimized.

Copy link
Member

Couto commented Jan 15, 2016

@NXTaar is silent, so I guess that I can close this. Open otherwise.

@Couto Couto closed this Jan 15, 2016

@jt-wang

This comment has been minimized.

Copy link

jt-wang commented May 30, 2016

@NXTaar @zloirock Hi, I bumped into exactly the same problem with @NXTaar and haven't found a solution yet. How can I use "only part of polyfills" without breaking the original js that I wrote? Is there a way to write like "babel-polyfill" but it can intelligently detect which part should be inserted?

@NXTaar By the way, how did you solve it please?

@NXTaar

This comment has been minimized.

Copy link

NXTaar commented May 30, 2016

@jt-wang Actually the big size of the files was caused by source map option. If this option is off, the file size will become more reasonable. At this moment, Babel had several updates, so the problem was actually fixed.

@jt-wang

This comment has been minimized.

Copy link

jt-wang commented May 30, 2016

@NXTaar Thanks but even if I comment out the line devtool: 'source-map, the generated bundle.js is still around 600 kB large. By the way, the source map won't be inserted in unless use inline source-map.

@ghost

This comment has been minimized.

Copy link

ghost commented Aug 2, 2016

I have exactly the same problem. Have you found solution?

I'm using
"babel": "^6.5.2",
"babel-core": "^6.11.4"

@jt-wang

This comment has been minimized.

Copy link

jt-wang commented Aug 2, 2016

No, I haven't. The size problem still exists and I haven't see any progress.

On Tue, Aug 2, 2016 at 2:10 AM, Prisniak Andrey notifications@github.com
wrote:

I have exactly the same problem. Have you found solution?

I'm using
"babel": "^6.5.2",
"babel-core": "^6.11.4"


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#163 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHao87JItOgYaWxBWD4CswhxzMv5ym6Rks5qbt9JgaJpZM4GnG-P
.

@tracker1

This comment has been minimized.

Copy link

tracker1 commented Aug 15, 2016

Two bits, first, if you want to have common bits, you need to setup the CommonChunksPlugin, second is that you should be using webpack -p for production build, this will uglify your output file(s), which should be quite a bit smaller... all of that said, I was actually thinking that the 70K I was seeing was pretty big, nowhere near 600k... and the 70K gzipped is under 30k. That is with just babel-polyfill ... note: if you don't want to use bits that require polyfill, you can probably get away with the es2015-minimal preset as well.

@ghost

This comment has been minimized.

Copy link

ghost commented Aug 15, 2016

tracker1 can you provide some example with babel polyfill.
Thanks

@cullylarson

This comment has been minimized.

Copy link

cullylarson commented Oct 17, 2016

I'm having a similar problem. Without babel-polyfill, my compiled code is 11k. With babel-polyfill, it's 104k (both uncompressed sizes). Using webpack as well. The only difference between those two builds is whether babel-polyfill is in the entry list.

@openjck

This comment has been minimized.

Copy link

openjck commented Oct 18, 2016

I'm not sure if there's a way to select specific polyfills using babel-polyfill and webpack, but we were able achieve the same effect using core-js-webpack-plugin.

See mozilla/distribution-viewer#130 as an example.

@renarsvilnis

This comment has been minimized.

Copy link

renarsvilnis commented Dec 27, 2016

Note: related directly to babel-loader, but might be helpful for anyone founding this issue while looking for ways to reduce polyfill size

@openjck I was researching ways to reduce the polyfill size in the bundle and came across a babel preset that takes in targeted browsers and transpiles only that code and import only those polyfills from babel-polyfill that all the browsers need for having support.

In my tests I found out that targeting current browsers only saved me 1 kb (un-gziped) at best as those browsers needs to polyfill almost all entire ES6+ features.
tl;dl For websites with normal support for current popular browsers there are no gains of this optimization. Recommend you to rather look into polyfill services such as polyfill.io for the time being.

@m98

This comment has been minimized.

Copy link

m98 commented Feb 17, 2017

I also have the same problem, but I use browserify! Any solution for the file size problem?

@klcantrell

This comment has been minimized.

Copy link

klcantrell commented Jan 2, 2018

@NXTaar @cullylarson I wanted to see how you guys solved this problem. I'm having exactly the problem described where including babel-polyfill like so entry: ['babel-polyfill', './src/js/index.js'] results in a huge file and simply removing it takes it back down. I've seen others with the same issue on stack overflow but haven't come across answers. I've heard source-maps is one cause for huge files but I don't have that enabled. Please advise, thanks!

@cullylarson

This comment has been minimized.

Copy link

cullylarson commented Jan 2, 2018

@klcantrell I just ended up including polyfills for specific things rather than all of babel-polyfill. I did find something that looks promising; planning to try it on my next project: https://github.com/babel/babel/tree/master/packages/babel-preset-env

@klcantrell

This comment has been minimized.

Copy link

klcantrell commented Jan 2, 2018

@cullylarson Thanks, I'll try that as well. I know the earlier comments in this thread reference core-js, I'm going to look into that for loading specifics. I've also heard that setting babel-polyfill as another entry point and using the CommonsChunkPlugin could solve this problem, I'm going to look into that.

@tracker1

This comment has been minimized.

Copy link

tracker1 commented Jan 16, 2018

@klcantrell at this point, you should probable use babel-preset-env setup with the browsers you want to support, you may even find the effort to separate old/IE support from green/current browser versions, and deliver one or the other in your server.

Right now, I'm working on internal apps and only really need to support the latest chrome & firefox, so no need for most of the polyfills any longer. I use env + stage-0 configured for node (8.x) server-side or chrome latest client-side config.

@klcantrell

This comment has been minimized.

Copy link

klcantrell commented Jan 17, 2018

Thank you @tracker1, that helps a ton. There seems to be so many babel packages out there that it's hard to know which one is most appropriate. I'll look into what the env preset and others can do without the polyfill.

Have you used async/await on any projects? If I understand your advice correctly, the env preset used in combination with the appropriate stage- preset is the way to go. In other words, no need to provide a regenerator-runtime using something like babel's transform-runtime plugin or the polyfill.

Thanks for your tips!

@tracker1

This comment has been minimized.

Copy link

tracker1 commented Jan 17, 2018

@klcantrell it's worth noting, if you are supporting older browsers, it will include the necessary polyfills. I've been using async/await since early on.

env preset has a configuration that tells it what environments you want to support... and it uses kangax data to include any transforms/fills those browsers need. env includes everything that's stage 4 (part of the spec)... stage 0 includes, 1, which includes 2, and 2 to 3... It's recommended to only include those pieces you want as the behavior can change, but I run with scissors.

As to the regenerator etc... all green browsers now support async, mobile coverage is spotty though. Node 8 has great coverage for most newer features.

@klcantrell

This comment has been minimized.

Copy link

klcantrell commented Jan 22, 2018

Thank you @tracker1 ! I'm so glad you decided to throw in your advice, helped me out a ton.

@mdrideout

This comment has been minimized.

Copy link

mdrideout commented Jan 18, 2019

For a comparison, my parsed size @babel (according to webpack bundle analyzer) was 81.3kb with the following browser compatibility settings in .browserslistrc

> 0.5% in US
last 2 versions
Firefox ESR
not ie < 10
not dead

When I changed it to the following, the parsed size drops to 71.84kb. The more browsers you support the more polyfills.

> 5% in US
Firefox ESR
not ie < 10
not dead

Run npx browserslist to see what you're supporting.

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