Original: www.yuque.com/xiezhongfu/…

@babel/polyfill

IO /docs/en/bab…

As of Babel 7.4.0, this package is obsolete and the source code is introduced directly to Corejs and Regenerator



Github.com/babel/babel…

  • @babel/plugin-transform-runtime: @babel/plugin-transform-runtime:
  • Simulated ES6+ environment (excluding: Stage 0/1/2/3)
  • Add it at the entrance to the program, once and for all
  • Adding poliyFill to each prototype causes global contamination

Evolutionary scheme

  1. @babel/preset-env + useBuiltIns
  2. You manually import the polyfill subpackages you need separately

There are two alternatives, and the first is recommended, which is essentially an automated version of the second. How do you automate it? Automatically select which polyfill subpackages are required based on the target environment to run. See below for details.

@babel/preset-env

IO /docs/en/pre… Babeljs. IO/docs/en/bab…

@babel/preset-env based on some awesome projects: Browserslist, compat-table, electro-to-chromium,…… @babel/preset-env Automatically ADAPTS JS features required by the preset target environment, Babel conversion plugin (excluding stage-0/1/2/3), Corejs’ Poliyfill. Autoadaption can selectively pollute the whole world, and of course can be converted to ES5 indiscriminately, see babeljs. IO /docs/en/bab…

You need to know how to customize @babel/preset-env in Webpack and master @babel/preset-env + useBuiltIns instead of @babel/polyfill.

Plan 1

Scheme 2

  • Install @ Babel/polyfill
  • Introduce @babel/ Polyfill at the entrance to the app
  • In.babelrcuseBuiltIns: 'entry'

Plan 3

  • Install @ Babel/polyfill
  • In.babelrcuseBuiltIns: 'false'This is the default behavior
  • Add @babel/ Polyfill at the entrance to the WebPack configuration

@babel/plugin-transform-runtime

IO /docs/en/bab… Github.com/babel/babel…

terms

Helper: For example, Babel uses the _extend function to copy properties from one object to another

Why the @babel/ plugin-transform-Runtime?

  • You don’t want to pollute
  • You want to use it in a library
  • Default helper functions are declared or defined once in all required files, which is wasteful and not supported across files

@babel/plugin-transform-runtime provides a sandbox environment that points to Corejs when using some of the older JS features. It doesn’t pollute the world, but because it didn’t polyfill prototype, Some older JS instance methods are not available, such as array.prototype.includes.

@babel/plugin-transform-runtime lets all helper functions point to the @babel/ Runtime component. This saves space and supports cross-file support for unified management. This requires @babel/ Runtime to be pre-installed.

configuration

In the.babelrc configuration file, take the default parameter configuration

{
  "plugins": [["@babel/plugin-transform-runtime",
      {
        "absoluteRuntime": false."corejs": false."helpers": true."regenerator": true."useESModules": false}}]]Copy the code

corejs

As can be seen from the default “corejs”: false, @babel/plugin-transform-runtime assumes that all polyfills need to be supplied by the user:



Github.com/babel/babel…





  • To set corejs to 3, install @babel/ Runtime-corejs3
  • To set corejs to 2, install @babel/ Run-time corejs2
  • To set corejs to false, install @babel/ Runtime

absoluteRuntime

By default, Babel loads a version of @babel/ Runtime that is already configured and installed from node_modules. The absoluteRuntime parameter modifies this default behavior by specifying where to load the corresponding @babel/ Runtime.

For details about other configuration items, see babeljs. IO /docs/en/bab…