Comment originally made by @Kovensky

I don't think external-helpers should be a thing if you're going to use a module system; transform-runtime with useBuiltIns should already cover everything without adding an extra global to the application.

If you're going to separate things into libraries and apps, I think that libraries should only use helpers and use the built-ins from the environment. It is up to the app to provide the polyfills if the environment you expect to run on is outdated. If, for some reason, you still want to prevent your app from patching your environment, you can do a transform-runtime pass on all files transforming builtins.

Comment originally made by @rtsao

If you're going to separate things into libraries and apps, I think that libraries should only use helpers and use the built-ins from the environment.

Agreed on polyfills, but I think helpers belong in the libraries themselves. If I'm writing a library that doesn't need polyfills, my library should work out of the box by someone not using Babel (i.e. they should not need to provide the babel helpers).

As mentioned in #5601, I propose having a standalone babel-helpers package that allows libraries to import individual babel helpers. Then the application can consume the same babel-helpers package as used in node_modules, so you have full de-duplication of babel helpers. Furthermore, if the babel-helpers package exports an ES Module (via the module field of package.json) any unused babel helpers can be tree-shaken. In this case you have truly minimal babel helpers in the client bundle.

I'm doing some issues cleanup, all the points in the original issue have been either solved, or are not actionable from Babel (for example, the webpack chunks).