Feature Request
Is your feature request related to a problem? Please describe.
While @babel/preset-env has useBuiltIns (and exclude: ["@babel/plugin-transform-regenerator"]) to reduce what is consumed out of core-js (or regenerator-runtime), libraries are still forced to determine targets and consumers are all still forced to use core-js or regenerator-runtime (and have no choice as to their own wishes for targets). OTOH, when useBuiltins is not used, libraries or applications are unaware of what dependencies ought to be added or having an automated way to get at this, at least without going through another Babelification routine.
Describe the solution you'd like
I am thinking Babel (as with @babel/preset-env) could optionally save a config file indicating the polyfills for builtins in use within a package (though bundling it separately from the distribution file, say as JSON).
A build tool employed optionally by an application could look for this config file in each of its dependencies and add core-js or regenerator-runtime imports to the application's entry file (eliminating duplicate import statements if different projects required the same).
Describe alternatives you've considered
(Explained above.)
Teachability, Documentation, Adoption, Migration Strategy
Libraries using @babel/preset-env could set a new option buildBuiltinsJSON to true and probably avoid setting useBuiltIns.
Consuming applications would ideally have access to a command line or programmatic tool from Babel to add (or replace existing) imports within a specified entry file for their application, based on the .babel-builtins.json files across all of their dependencies.
Feature Request
Is your feature request related to a problem? Please describe.
While
@babel/preset-envhasuseBuiltIns(andexclude: ["@babel/plugin-transform-regenerator"]) to reduce what is consumed out of core-js (or regenerator-runtime), libraries are still forced to determine targets and consumers are all still forced to usecore-jsorregenerator-runtime(and have no choice as to their own wishes for targets). OTOH, whenuseBuiltinsis not used, libraries or applications are unaware of what dependencies ought to be added or having an automated way to get at this, at least without going through another Babelification routine.Describe the solution you'd like
I am thinking Babel (as with
@babel/preset-env) could optionally save a config file indicating the polyfills for builtins in use within a package (though bundling it separately from the distribution file, say as JSON).A build tool employed optionally by an application could look for this config file in each of its dependencies and add
core-jsorregenerator-runtimeimports to the application's entry file (eliminating duplicate import statements if different projects required the same).Describe alternatives you've considered
(Explained above.)
Teachability, Documentation, Adoption, Migration Strategy
Libraries using
@babel/preset-envcould set a new optionbuildBuiltinsJSONtotrueand probably avoid settinguseBuiltIns.Consuming applications would ideally have access to a command line or programmatic tool from Babel to add (or replace existing) imports within a specified entry file for their application, based on the
.babel-builtins.jsonfiles across all of their dependencies.