Clarifications regarding migration and backwards compatibility

[ernestostifano]

Hi guys! Thank you for all your great work here, I really think babel-polyfills is the good path to follow. It just took me some time to find it.

Yesterday I started the migration in one library from a @babel/preset-env/@babel/plugin-transform-runtime setup. I carefully read all your notes and some of the source code involved, however, I wrote down some doubts that I would like to clarify before making my changes definitive.

Considering the following situation:

BEFORE	AFTER
{ "presets": [ ["@babel/preset-env", { "spec": true, "modules": false, "targets": "...", "ignoreBrowserslistConfig": true }] ], "plugins": [ ["@babel/transform-runtime", { "version": "^7.17.9", "corejs": { "version": 3, "proposals": true }, "useESModules": true }] ] }	{ "targets": "...", "browserslistConfigFile": false, "presets": [ ["@babel/preset-env", { "spec": true, "modules": false, "ignoreBrowserslistConfig": true }] ], "plugins": [ ["@babel/transform-runtime", { "version": "^7.17.9", }], ["polyfill-corejs3", { "method": "usage-pure" }] ] }

(Having @babel/runtime as a runtime dependency and @babel/preset-env, @babel/plugin-transform-runtime and babel-plugin-polyfill-corejs3 as development dependencies, after migration.)

The following doubts arise:

1. Will @babel/runtime helpers be transpiled/polyfilled? Since we are not referencing them from the corejs source anymore (@babel/runtime-corejs3). For example, if @babel/runtime/helpers/asyncToGenerator is used, will Promise be polyfilled inside it? (Without polluting the global scope). (Maybe this could be a problem because I think it is not possible anymore to disable general polyfills in @babel/plugin-transform-runtime while still importing helpers from @babel/runtime-corejs3.)
2. With babel-plugin-polyfill-corejs3, is it possible to use a specific version of core-js? (like 3.18.1). Should/can we add core-js-pure (or other flavor) as a runtime dependency explicitly in our library?
3. Can proposals be 'opt-in', like with proposals option in @babel/plugin-transform-runtime?
4. Will ES6 modules always be used? How does the plugin decide when to use ES6 or CJS?
5. Is this new system beta? Can it be reliably used in critical projects? With proper testing, etc.

Hope I am not missing or confusing anything. I would really appreciate any insights.

Thank you again!

[ernestostifano]

Reading some previous issues/questions I have found the following possible answers so far:

1. Unsure how usage-pure and transform-runtime should work #32: however, in the case of a library, like ours, which is shipped only transpiled/polyfilled (not bundled), we cannot apply this solution and we are failing to achieve our proposed compatibility target for our consumers. From this point of view @babel/runtime-corejs3 might still be necessary, but just for Babel helpers and not for general polyfilling, could this be achieved somehow? For these helpers, targets support would not be possible though.
2. core-js absolute path import getting added automatically after compilation #108 (comment): seems to suggest that the dependency should be explicitly declared, but it is still unclear to me how to specify and match the version (babel-plugin-polyfill-corejs3 shows a version option in it's README, but it is not documented anywhere, is SemVer syntax supported?). Shouldn't core-js-pure be used to avoid global pollution? Or not anymore?
3. ...
4. ...
5. ...

[ernestostifano]

Hello guys! Any comments on this? (Friendly ping)