Do I still need this package to polyfill ?

[qiulang]

Hi I see Rethink polyfilling story was closed because of this project. But I read here https://babeljs.io/docs/en/babel-polyfill/ "As of Babel 7.4.0, this package has been deprecated"

So my question is I do not need this package to do polyfill with the latest @babel/core (I use version "7.12.13" ), right ?

But since this package was deprecated what is latest document about polyfill using babel ? How much information in Rethink polyfilling story is invalid now ?

[nicolo-ribaudo]

@babel/polyfill has nothing to do with this. This repository is a collection of Babel plugins to inject imports to other polyfills.

[qiulang]

Oh thanks. I had thought @babel/polyfill was the result of this project. lol So I am a library author and according to the readme I should use @babel/plugin-transform-runtime because @babel/preset-env's useBuiltIns: "usage" will pollute the global scope.

But I just need to polyfill a specific api (Promise.any to be exact) what is the problem of useBuiltIns: "usage" ? Even I use core-js's Promise.any function, what is the problem it will cause ? I still don't understand.

[qiulang]

The readme also said "These packages are highly experimental and they have not been tested in production applications yet.” I am rather confused with those words. So what is the "proper" way to polyfill in in production applications then ?

[ljharb]

@qiulang imo the best practice for package authors is not to rely on polyfills when possible. For Promise.any, I'd suggest depending on https://npmjs.com/promise.any and using that directly. In environments where it's natively available, it will use the native one.

[agilgur5]

Might be necro'ing, but as a long-time user, thought I'd answer too since this wasn't closed and OP didn't quite respond.

The readme also said "These packages are highly experimental and they have not been tested in production applications yet.”

I've used them in multiple production applications and libraries at this point 🙂

So I am a library author and according to the readme I should use @babel/plugin-transform-runtime because @babel/preset-env's useBuiltIns: "usage" will pollute the global scope.

But I just need to polyfill a specific api (Promise.any to be exact) what is the problem of useBuiltIns: "usage" ?

preset-env's useBuiltIns: "usage" is not pure, so for a library author that is not ideal as it will cause (potentially unintended and hard to detect) side-effects when your library is used.

transform-runtime was pure, so good for library authors, but didn't support targets like preset-env did.

The collection of plugins here allow you to get the best of both worlds as a library author, as written in the History and Motivation section of the README.

So what is the "proper" way to polyfill in in production applications then ?

As an application author, one could just use preset-env on its own as polluting scope isn't as much a potential problem, but the packages (and general methodology) here also allow you to use an alternative polyfill other than core-js as well, instead of forcing core-js usage. That's mentioned in the above section of the README as well.

As a library author, one could use targets with usage-pure here to get the "best of both worlds", such as:

{
  "targets": { "firefox": 42 },
  "presets": ["@babel/preset-env"],
  "plugins": [
    ["polyfill-corejs3", {
      "method": "usage-pure"
    }]
  ]
}

The Migration docs offer various examples of different use-cases when moving from preset-env's useBuiltIns to the plugins here.

[nicolo-ribaudo]

These packages are used in preset-env too, so they have been battle-tested. We should probably remove the "highly experimental" notice!