core-js@3, babel and a look into the future

[zloirock]

core-js@3, babel and a look into the future

[rpokrovskij]

I'm almost crying from happiness :) Great article, we need it.

Year ago I wrote the article about the components creation and "polyfill" management topic for biggest Russian developers community- https://habr.com/ru/post/416235/ - I din't get any replies, so I was depressed both by the complexity of the problem and because of "there is nobody who try to reflect on it".

Now at least I know who have a complete vision and will return to this text many times. Thank you again.

P.S. Check https://github.com/SebastianS90/webpack-polyfill-injector , author has a lot of experience in dynamic loading of polyfills (on demand).
Also what is important: dynamic polyfill loading could be only asynchronous, what put us into a race situation with other javascript code (that could be in need of polyfills).

[otakustay]

If I want all features from core-js and let @babel/preset-env to pick required modules via useBuiltIns: 'entry', is it enough to use just import 'core-js'? I don't know the differences between import the core-js/index and to manage modules of core-js myself

[zloirock]

@otakustay it's an interesting issue. import 'core-js' is enough. But import 'core-js/index' from your example will not be optimized by preset-env since it works only with the list of normalized entry points from core-js-compat/entries, I didn't think that someone uses entry points in this form. Seems need to add normalization logic to preset-env for users who will try to use entry points in this form.

If you don't understand the difference, just use the main entry point. If you will want to optimize polyfills size in the future, just read core-js docs and add required for you entries.

[rpokrovskij]

What about element polyfills?

            'Element.prototype.matches',
            'Element.prototype.closest',
            'Element.prototype.classList'

Any plans to support?

[zloirock]

@rpokrovskij in this article you can find a note about support of web standards like this.

[rpokrovskij]

@zloirock this your note was in form of open question... so if you are still need to disccuss it, my opinion is : "it depends on your priorities" :) async dynamic loading and runtime browser detection in webpack runtime is much more complex task which I would personally avoid (since there is early mentioned https://github.com/SebastianS90/webpack-polyfill-injector - in ideal world cooperation should be possible). Then building web standart polyfils set is a good choice (but I guess boring).

[3cp]

Previously @babel/polyfill provided an umd build @babel/polyfill/browser.js. Can we have an umd build for core-js v3 too, so we can use it directly in <script> tag?

[zloirock]

Sure, it's a separate core-js-bundle package.

[tbassetto]

I am setting up a new project using the latest babel and webpack, but while your article is very informative I must admit that I still have a question 😄

@babel/polyfill is deprecated, it's written on GitHub but it's not mentioned on the official documentation though so it took me a while to figure it out.

I am using babel.config.js with @babel/preset-env configured with { useBuiltIns: 'usage', corejs: 3 }.

It's a bit unclear to me from reading https://github.com/zloirock/core-js/blob/master/docs/2019-03-19-core-js-3-babel-and-a-look-into-the-future.md#usebuiltins-entry-with-corejs-3 is I have something else to do or if I need to add:

import "core-js/stable";
import "regenerator-runtime/runtime";

to my entrypoint (and of course add core-js and regenerator-runtime to package.json).

Thanks :)

[zloirock]

@babel/polyfill is deprecated, it's written on GitHub but it's not mentioned on the official documentation though so it took me a while to figure it out.

Updating of this documentation still in progress.

It's a bit unclear to me from reading ... is I have something else to do or if I need to add ... to my entrypoint

With useBuiltIns: 'usage' it's not required, required only adding those dependencies to package.json. If it's unclear from this article - feel free to add a PR.

[nvdlug]

Hi Zloirock,

Thanks for this great library. I have a question about IE11 support.

Currently import core-js like so:

  import ("regenerator-runtime/runtime");
  import ("core-js");

Then I set corejs to 2 in babelrc. This works fine for IE11. However, when I put it to 3 it doesn't work anymore, although I don't get any errors in the console.

Is core-js@3 supposed to support IE11?

[zloirock]

Is core-js@3 supposed to support IE11?

Sure, IE11 is supported. Even IE8- should be supported.

Currently import core-js like so ...

regenerator-runtime should be imported after core-js since internally uses some modern built-ins.

However, when I put it to 3 it doesn't work anymore

I can't say anything without more info or a reproducible example. Please, create a separate issue.

[nvdlug]

Thanks for the reply, I adjusted the order of the imports and I see an error now:

Unable to get property 'iterator' of undefined or null reference.

It does work in chrome and firefox though. Should I make a new issue about this?

[zloirock]

@nvdlug yes. And, please, with a reproducible example or at least a stack trace.

[rtymchyk]

We've seen our time to interactive metric tank in our app, across multiple pages, after migrating. Note we are using useBuiltIns: entry, replaced @babel/polyfill with import 'core-js/stable'. Has anyone else experienced this?

Tweaking a bit more with babel-env to see if we can optimize it.

[poorpaddy]

If someone has the latest working with babel can you post the full solution please. I've been searching/trying stuff posted in github issues and stack overflow for hours now and keep going in circles.

[rtymchyk]

@poorpaddy What problems are you running into?

[rjgotten]

Currently, we can't set the target environment as @babel/runtime like we can do for @babel/preset-env. That means that @babel/runtime injects all possible polyfills even when targeting modern engines: it unnecessarily increases the size of the final bundle.

In other words: @babel/transform-plugin-runtime and builds set up to not pollute the global namespace, will still have to deal with their number one detriment: explosively huge filesize, making the entire exercise a wasted effort for anyone wanting to deploy this strategy on performance-minded websites.

Any timeline on when we can expect this problem to be fixed?

[zloirock]

@rjgotten now I lost any motivation to work on it or another babel features. So no concrete timeline.

Anyway, if your target includes old engines like IE11, you will not see any serious difference even it will be done.

[rjgotten]

Anyway, if your target includes old engines like IE11

Why a single target?

You can easily use build tooling to produce a down-level build for IE11 and an up-level build for modern browsers, or even go more granular if you want and have several levels. That's the beauty of tools like Webpack and Babel, backed by high quality polyfills like CoreJS. The same source can be made to work at several levels against little additional developer effort. Practically all of it can be hidden behind write-once-use-many automation.

now I lost any motivation to work on it or another babel features

That though, is honestly a sad way to respond. Are you attempting to guilt-trip me because I'm critical of the work that was done?

Just for the record: I'm not saying the effort was for naught, because it certainly was not. There are and will be many projects that can benefit from these updates. Just not the segment consisting of high-performance public facing websites, where download-size is a hugely important factor.

And that's sad, because that's quite a big chunk of the market.

There's a risk/benefits decision there and most developers will opt to forego integration with @babel/plugin-transform-runtime and will use the global-polluting integration with @babel/preset-env instead. Simply because the size factor far outweighs the global/non-global choice for those scenarios.

Yes; 'going global' works -- I'm using it now as well, actually. So credit where it's due 👍 -- but it brings its own problems.
Especially if your code has to live in a shared environment. E.g. when you're actually authoring a 'widget' meant to integrate into existing websites as a third-party. Or if you're delivering a website for an owner that loves to experiment with injecting their own code through Google Tag Manager or similar tooling.

I'm already not looking forward to having to deal with corner cases of global polyfills failing or causing havoc 'somewhere.' But I know it's still the lesser of evils.

I'd just like not to have to make that choice to begin with.

[zloirock]

@rjgotten

Are you attempting to guilt-trip me because I'm critical of the work that was done?

Nope. It was related to my current burnout and problems, see #548 (comment)

Just not the segment consisting of high-performance public facing websites, where download-size is a hugely important factor...

For this case, the global version is much more applicable.

E.g. when you're actually authoring a 'widget' meant to integrate into existing websites as a third-party.

Yes, for this case separate bundles and browsers targeting for runtime could be useful.

As I wrote in the article, it can be implemented enough simple, but, as I wrote above, no concrete timeline.

@nicolo-ribaudo has own vision of future of polyfilling in babel and (if I understood correctly) it includes adding browsers targeting to the pure version of core-js too. So most likely one day it will be implemented.

[rjgotten]

@zloirock
Nope. It was related to my current burnout and problems

Ouch. Ok. I was not aware of that. o_O
In that case I offer my sincere apologies.

So most likely one day it will be implemented.

Well; that atleast is something. Thanks. 👍

[nicolo-ribaudo]

Yup! You can find my ideas at babel/babel#10008

[jackvik]

My project is using object.assign in node_modules. where to add the babel core-js to handle the "Object.assign is not a function" error?

[zloirock]

@jackvik you have some different options on how to do it.

[jackvik]

I am using useBuiltIns:"usage" and corejs:3 but still getting object.assign error. I tried import 'core-js/stable/object/assign'; in index.js but still not working. Please help, how to make object.assign work for object.assign being present in node_modules.

[zloirock]

@jackvik did you add core-js@3 to your dependencies?

[jackvik]

yes i have added but for node_modules, it's not adding this object.assign polyfill

[zloirock]

Could you show your configs?