The most recent polyfills via polyfill-service?

[dy]

Hi. It is really great tool, but it too fast becomes outdated due to lack of modern polyfills.

I know, there is an option to set up autopolyfiller to attach custom polyfills, but it is a separate headache for module developers. Instead of that it is faster to manually pick needed polyfills and concat them to the bundle. That makes autopolyfiller useless, unfortunately.

I’d suggest using the API of the most actual polyfill database, instead of autopolyfiller-stable. That way you get rid of polyfills maintenance headache and make users happy.

[paulirish]

For sure. You should be pulling from https://github.com/Financial-Times/polyfill-service which is built for this. @samgiles

[samgiles]

This is a great idea, I should set up and release the service to the NPM registry to make this easier: https://github.com/Financial-Times/polyfill-service/issues/110

[azproduction]

I am sorry guys for not responding for so long time. I'll use Financial-Times's clone as soon as I have a stable internet connection at home. Right now I am relocating a bit...

Btw, @samgiles there is complains about quality of polyfills https://github.com/azproduction/autopolyfiller-stable/issues/1reported by @monolithed

[samgiles]

Quick update on quality of polyfills: we've made a lot of effort to improve the quality of the polyfills. This is an ongoing effort.

[azproduction]

@samgiles thanks! I'll force myself to switch to Financial-Times/polyfill-service this week.

[tcoopman]

Any updates on this?

[azproduction]

@tcoopman it still does not have a npm repo: https://github.com/Financial-Times/polyfill-service/issues/110 // cc @samgiles

Ah, but it has a package version at least - finally. I'll do the next attempt this week. Thanks, @tcoopman for ping ;)

[tcoopman]

@azproduction looking forward to it. Thanks :-)

[smacker]

actually autopolyfiller is broken already.

Error: Cannot find module 'polyfill'

I think it's because https://github.com/jonathantneal/polyfill default brunch is "deprecated" now.

[azproduction]

Making a temp fix, please wait. It was nice of @jonathantneal to do that :)

[azproduction]

@smacker recent issue with deprecated jonathantneal/polyfill was fixed in autopolyfiller@1.4.1. Sorry for the delay.

[azproduction]

Another critical Financial-Times/polyfill-service's issue appears https://github.com/Financial-Times/polyfill-service/issues/230

[azproduction]

Blocked by https://github.com/Financial-Times/polyfill-service/issues/233

[danielberndt]

Seems like https://github.com/Financial-Times/polyfill-service/issues/233 is fixed now. Any updates on this issue here?

[monolithed]

I see the following problems:

https://github.com/Financial-Times/polyfill-service/issues/331 https://github.com/Financial-Times/polyfill-service/issues/341 https://github.com/Financial-Times/polyfill-service/issues/340 https://github.com/Financial-Times/polyfill-service/issues/339 https://github.com/Financial-Times/polyfill-service/issues/352

There is no no guarantee for backward compatibility of new versions

For example, my grunt plugin is broken, by reason of:

"polyfill-service: '^1.1.0'

^ — used to guarantee full backward compatibility, but polyfill-service does not!

And possible reasons as well: https://github.com/Financial-Times/polyfill-service/issues/271 https://github.com/Financial-Times/polyfill-service/issues/270 https://github.com/Financial-Times/polyfill-service/issues/303

[alexander-akait]

@azproduction Will the migration to polyfill-service?

[azproduction]

@sheo13666 I don't know about quality, but polyfill-service is less stable than it was originally :-) It is better to wait at least for separate polyfills repo.

[alexander-akait]

@azproduction Used polyfill-service, stability problems did not notice. I think the creators are not divided into separate repositories.

[smacker]

@azproduction some of current polyfills are broken. For example Array.prototype.some. But polyfill-service fixed it.

[triblondon]

@azproduction I'm sorry the polyfill service hasn't been easy to pick up for your use case. We'd like to ensure it is, and we're working through those issues.

[azproduction]

@triblondon thanks. The biggest issue is that polyfill-service is not only database, but tool, which requires lots of unnecessary dependences. Any plans for extracting it as a standalone database?

[triblondon]

No. There's a discussion of that here: https://github.com/Financial-Times/polyfill-service/issues/125. Basically the tool is required to test the polyfills, so the two are inseparable. Also, since that discussion, we now have some polyfills that require dependencies that are private to the service like _enqueueMicrotask. We are not intending to make the consumption of the raw polyfill source a supported use case, so for your purposes you would use the service API to generate the polyfill source that you need.

[azproduction]

you would use the service API to generate the polyfill source that you need

@triblondon getPolyfillString(options) relies on uaString which is not possible to get in my case.

Or can I hack it like that?

getPolyfillString({
    uaString: '',
    features: {
        'Array.prorortpe.forEach': {}
    }
});

[triblondon]

The problem with doing that is that some polyfills have variants per-browser. If a polyfill has totally different code in IE vs FF, and you don't specify a UA, we have no idea which variant to serve. Some have default versions, but those tend not to work in the specific browsers that we have created variants for.

The library is designed to create the smallest possible bundle for a known browser.

That said I just had a thought for how we could support the best of both worlds, but it would be a major change. I've logged it as https://github.com/Financial-Times/polyfill-service/issues/366

[azproduction]

@triblondon I see. And for Autopolyfiller browser-agnostic(or with runtime activation) polyfills are the must.

[triblondon]

Your current mechanism requires browser agnostic bundles, but I would argue that you could improve your tool by outputting a <script> tag targeting cdn.polyfill.io rather than offering up a single precompiled bundle that is served to all browsers. Then we wouldn't need to figure out a way of supporting browser agnostic bundles, which I see as an inferior method of using the service to the one we already have.

[jonathantneal]

Has this been resolved? It think the polyfill service provides the tools you need. I would love to use this today with grunt-autopolyfiller.

It finally dawned on me what all of this was doing, as it has now affected me :)

This is still a significant problem for JS devs who want something like autoprefixer for writing JS. Who don’t want to know all the ins and outs of old browsers, who want to only fetch the polyfills they need for a certain stack of browsers, but whose clients won’t necessarily let them link to an awesome cdn service as FT provides.

[dy]

It is still a very requested feature in many respects.

For example, there is a polyify transform, which can solve the issue of automatic polyfillying of any browserify bundles. That would remove a pain of polyfilling bundles for IE, mozilla, safari, iOS etc., as it is always a headache to manually search for features in code needed to polyfill and then generate proper URL for polyfill.io, like `

`. That would also remove issues related with [babelify](https://github.com/babel/babelify), to let it just easily use `Object.assign` instead of [`xtend`](https://www.npmjs.com/package/xtend) etc. For now it inserts [core-js](https://github.com/zloirock/core-js), quite huge and ungraceful. In many respects it would allow to reduce code size, deps, and a headache significantly. @azproduction what problems are there preventing from closing that feature-request? What is a best way to contribute?

[triblondon]

Hi @azproduction, recent changes in the polyfill service may be of interest to you:

• We killed off variants. We could trivially make it possible to request a bundle without specifying a UA. If you are interested in picking up this project and that feature would make it possible for you to update autpolyfiller to use our new library, I'd be happy to implement it
• Version releases are now more frequent and should be less likely to violate semver. We have a deprecation process and better contribution standards

[jonathantneal]

If no one else picks this back up, I may. Please let me know if you are interested in helping. This would make an excellent Gulp/Grunt task at the least.

[dy]

@azproduction just wonder if you'd consider granting access to other maintainers: me, @jonathantneal, @browserify or alike.

[azproduction]

This project was abandoned for 4 years and has only 200 installations according to npm. Over the 4 years so many things changed. Has it any value today?

[dy]

@azproduction enabling polyfill-service as a source opens potential for browserify/rollup/webpack autopolyfillers. Definitely it has.