core-js/regenerator-runtime as polyfill options

As raised initially in #103, as a nice solution for minimizing the work needed of eslint-plugin-compat users (and one far easier than some kind of polyfill detection), it would be nice if one could simply indicate use of ~@babel/polyfill~ core-js and regenerator-runtime (maybe within a ‘polyfillImplementations’ settings field if not overloading the polyfills property) and have eslint-plugin-compat be aware that polyfills such as Promise were already covered by those bundles…

One possible challenge might be if new versions of the polyfill changed which polyfills are available, so maybe there should be a version of ~@babel/polyfill~ core-js/regenerator-runtime indicated (defaulting to the latest).

[bjankord]

+1 for this feature. One idea that came to mind around implementing this would be using https://github.com/zloirock/core-js/tree/master/packages/core-js-compat and passing the project’s browserslist config to core-js-compat to generate a listing of all the required core-js modules for a project. This could then be passed on to compat settings under the hood if users specify core-js as a polyfillImplementations in settings. It would likely need a transform between the listing returned from core-js-compat and the config needed for compat. e.g. core-js-compat returns es.promise where compat expects Promise.

[julienben]

Indeed, this would be super useful!

Also, Core-js as an option. It’s included inside @babel/polyfill and telling eslint-plugin-compat v3 about every polyfill inside of it would require a very long array.