Add back moduleName option to @babel/plugin-transform-runtime

[nicolo-ribaudo]

Q	A
Fixed Issues?	Fixes #16238
Patch: Bug Fix?
Major: Breaking Change?
Minor: New Feature?
Tests Added + Pass?	Yes
Documentation PR Link	babel/website#2867
Any Dependency Changes?
License	MIT

When using @babel/plugin-transform-runtime together with a polyfill provider, we let the polyfill provider choose from which package helpers should be imported, so that they can be polyfilled using the same polyfill as defined by the provider.

However, there is a valid use case for now wanting that: we inject polyfill in @babel/runtime-corejs3&co to make sure that they are compatible with the oldest possible browsers, but especially when developing modern web apps this might not be necessary and thus unnecessarily increases the bundle size. We spent significant effort in the past in making sure that it's safe to transpile @babel/runtime itself, and doing so would let users to transpile it injecting only the polyfills that they actually need for their targets.

When @babel/plugin-transform-runtime has to inject a polyfill, it now first checks whether this moduleName option is set, if not (or if it's set to null) it checks if there is a runtime name provided by a polyfill provider, and if not it fallbacks to @babel/runtime.

This option was already supported in Babel 6, but it had been removed in #8266. Also, I already proposed adding this option ~1 year ago in #15426 for a solution to the "how do we let users use the proper runtime package to match the polyfill provider", while now it's to solve the opposite problem :)

---

An alternative is that we ask users to do this remapping through their bundler options: compiling dependencies only makes sense when bundling, so a bundler is always available.

For example, in Webpack you can do

  resolve: {
    alias: {
      "@babel/runtime-corejs3": path.resolve(__dirname, "@babel/runtime/"),
    },

this feels less clean to me, but it would require no changes on our side.