babel-polyfills icon indicating copy to clipboard operation
babel-polyfills copied to clipboard

Published 20 hours ago • verified publisher icon babel

Clarifications regarding migration and backwards compatibility

Open ernestostifano opened this issue 2 years ago • 2 comments

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 avatar Apr 21 '22 08:04 ernestostifano

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

  1. https://github.com/babel/babel-polyfills/issues/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. https://github.com/babel/babel-polyfills/issues/108#issuecomment-963493007: 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 avatar Apr 21 '22 08:04 ernestostifano

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

ernestostifano avatar Jan 20 '23 11:01 ernestostifano