Docs: Migration of @babel/transform-runtime about babel-polyfills HOT 5 CLOSED

What is the reason that it recommends "method": "usage-pure" and not "method": "usage-global"?

Because usage-pure is the equivalent of what transform-runtime does: it doesn't modify the global objects to install the shims/polyfills. usage-global is more similar to @babel/preset-env's useBuiltIns option.

As a user who wants to do the following, using "method": "usage-global" is more correct for me, right?

• I want to transform my code to my target environment
• I want to add polyfills automatically in my code (not caring about polluting the global namespace)
• I want the babel runtime helpers to be re-used via imports (without repetition of babel helpers in each file)

Yes! I would configure Babel like this:

{
  "targets": { ... }, // you can define your targets globally, so that ever plugin can use them to optimize the output
  "presets": ["@babel/preset-env"], // compile JS
  "plugins": [
    ["polyfill-corejs3", { "method": "usage-global" }], // or "polyfill-corejs2", or "polyfill-es-shims"
    "@babel/transform-runtime" // to deduplicate Babel-specific helpers
  ] 
}

from babel-polyfills.

@nicolo-ribaudo you are amazing! That is exactly the config I had started to code to use. Great to get it confirmed.

There has been a lot of confusion along the way. But I can definitely confirm that the new way you handle this with the motivations https://github.com/babel/babel-polyfills#history-and-motivation feels much more intuitive for me who has been reading up extensively on this the past weeks as a side-project.

If preset-env could in the future only handle transforms, and have polyfills separated as explained in this repo, I do think it will make more sense for users. Removing the polyfill options from present-env and transform-runtime would make this easier for users to understand on how to use this. So you get a thumbs on from me on this path you have taken 👍

from babel-polyfills.

Thanks for the feedback! 😄

from babel-polyfills.

Yes! I would configure Babel like this:

{
  "targets": { ... }, // you can define your targets globally, so that ever plugin can use them to optimize the output
  "presets": ["@babel/preset-env"], // compile JS
  "plugins": [
    ["polyfill-corejs3", { "method": "usage-global" }], // or "polyfill-corejs2", or "polyfill-es-shims"
    "@babel/transform-runtime" // to deduplicate Babel-specific helpers
  ] 
}

To @nicolo-ribaudo:

Is the ordering of plugins correct? Shouldn't we apply @babel/transform-runtime first and then do polyfill-corejs3? Reference to the migration guide: https://github.com/babel/babel-polyfills/blob/main/docs/migration.md#core-js3:

  "plugins": [
+    "@babel/transform-runtime",
+    ["polyfill-corejs3", {
+      "method": "usage-pure"
+    }]
  ]
}

I'm here from discussion: babel/babel#12605 (reply in thread)

from babel-polyfills.

The plugin order does not matter in this case.

from babel-polyfills.