Allow polyfill providers to specify custom @babel/runtime pkg

[nicolo-ribaudo]

Q	A
Fixed Issues?	Closes #15426, fixes babel/babel-polyfills#128 (comment) (point 1), fixes #15572
Patch: Bug Fix?
Major: Breaking Change?
Minor: New Feature?
Tests Added + Pass?	Yes
Documentation PR Link
Any Dependency Changes?
License	MIT

This PR allows polyfill providers to specify their own alternative to @babel/runtime, instead of hard-coding @babel/runtime-corejs2 and @babel/runtime-corejs3 in @babel/plugin-transform-runtime. It is a much better alternative to #15426, since it doesn't require extra configuration from users.

As copilot notices below, most of the changes in this PR are actually just extracting code to a new polyfills.ts file so that all the corejs/regenerator logic is self-contained, and can be more easily removed in the future.

The parallel PR in the babel-polyfills repository is babel/babel-polyfills#160, and this PR's tests will fail until that one is released.

I'm marking this as internal, since technically is a new feature for @babel/plugin-transform-runtime but in practice it only changes how we internally communicate options between the various plugins.

---

EDIT by me: this was fun, but it's also not what I needed 😂

🤖 Generated by Copilot at 48af4cd

Summary

🚚🔌🆕

Refactor the polyfill logic of babel-plugin-transform-runtime into a separate module. This makes the main plugin code cleaner and more maintainable, and fixes the regenerator import path.

To make the main plugin more neat
They moved the polyfill logic to polyfills.ts
With core-js and regenerator in tow
They used a secret key for some options, you know
And updated the helper import to the latest

Walkthrough

• Extract core-js and regenerator polyfill plugins to a separate module polyfills.ts (link, link, link, link, link)
• Simplify helperGenerator function by using lazy evaluation of modulePath instead of moduleName (link)
• Update import path of regenerator helper to @babel/helpers/regenerator (link)
• Use a secret key to pass compatibility options to polyfill plugins (link)

[babel-bot]

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/54497/

[nicolo-ribaudo]

This is the main change. Instead of computing modulePath from the plugin options, we now generate it based on file.get("runtimeHelpersModuleName").

[nicolo-ribaudo]

This test is to make sure that when using preset-env to load polyfills, and when using transform-runtime just for helpers, the helpers are loaded from the package without polyfills (for backwards compatibility).

[nicolo-ribaudo]

The failure on older Node.js versions is because they do not resolve symlinks:

   Expected /home/runner/work/babel/babel/packages/babel-plugin-transform-runtime/test/fixtures/absoluteRuntime/true-corejs3-proposals/output.js to match transform output.
    To autogenerate a passing version of this file, delete the file and re-run the tests.

    Diff:

    - Expected
    + Received

    @@ -1,6 +1,6 @@
    - var _mapInstanceProperty = require("<CWD>/packages/babel-runtime-corejs3/core-js/instance/map.js");
    + var _mapInstanceProperty = require("<CWD>/node_modules/@babel/runtime-corejs3/core-js/instance/map.js");
      var _marked = /*#__PURE__*/babelHelpers.regeneratorRuntime().mark(makeIterator);
      _mapInstanceProperty(Array);

I'm not sure about what in this PR causes that to change, I will investigate (I don't think it's a bug, but it's annoying to have this difference).

[nicolo-ribaudo]

I'm merging this PR because I need to rebase #15633 on top of this, to ensure that the SuppressedError polyfill is injected in our polyfilled helpers.