How do you think about core-js-service?

[Awen-hub]

A few months ago, I have found a dynamic polyfill service https://polyfill.io/v3/ . However, I also found that their service has only basic polyfill. Then I turn to core-js and find a plentiful polyfill in it so I want to create a polyfill service with it. But it is not easy because the polyfill in core-js is not a single file which has lots of dependencies. It seems only a way to solve it is to refactor the file structure in core-js, but it's also a heavy job. Now I find you have created a folder named core-js-service in v4 branch. Do you have any idea to do it?

[Awen-hub]

@zloirock

[zloirock]

How do you think about core-js-service?

I'm thinking about it since 2013. It's a required component for core-js ecosystem. This service requires hard work and it's the reason why it's still not available, but now we have almost all required components.

But it is not easy because the polyfill in core-js is not a single file which has lots of dependencies. It seems only a way to solve it is to refactor the file structure in core-js, but it's also a heavy job.

I can't understand this problem. This service should use bundling, see core-js-builder with the targets option.

Now I find you have created a folder named core-js-service in v4 branch.

In this branch, it's just a cap. I'm experimenting on it locally.

I'm writing a post that will contain more info.

[Awen-hub]

How do you think about core-js-service?

I'm thinking about it since 2013. It's a required component for core-js ecosystem. This service requires hard work and it's the reason why it's still not available, but now we have almost all required components.

But it is not easy because the polyfill in core-js is not a single file which has lots of dependencies. It seems only a way to solve it is to refactor the file structure in core-js, but it's also a heavy job.

I can't understand this problem. This service should use bundling, see core-js-builder with the targets option.

Now I find you have created a folder named core-js-service in v4 branch.

In this branch, it's just a cap. I'm experimenting on it locally.

I'm writing a post that will contain more info.

Glad to have your quick reply.
I consider that just connecting file(the way polyfill-library is using) will be much faster than using the webpack to generate a bundle file in runtime. I think the performance of a common service is very important. However if we want to do as polyfill-library, it may spends too much time to reform core-js.

[zloirock]

Files concatenation was used in core-js to 2015, the proper architecture of the project can't be written on something like this. Cache and warming up of the service solves this problem. esbuild is very fast, but could cause some minor issues like this, after fixing issues I'm thinking to move to it.

[Awen-hub]

Files concatenation was used in core-js to 2015, the proper architecture of the project can't be written on something like this. Cache and warming up of the service solves this problem. esbuild is very fast, but could cause some minor issues like this, after fixing issues I'm thinking to move to it.

It sounds great. At the same time, I think a plugin which can analysis JS files and get the polyfill‘s name we need in our project is also necessary, just like the create-polyfill-service-url(https://www.npmjs.com/package/create-polyfill-service-url) . It can help us get the polyfill we need more exact. I find @babel/standalone (https://www.npmjs.com/package/@babel/standalone) may help core-js to do it. Last, I am really looking forward to see the core-js-service and It is a pleasure to help if I can.

[zloirock]

Yes, something like that is also in plans, but in another form. As I said, the details will be a little later.

[zloirock]

Let's track it in #638.