preface

Although Babel is widely available online, I would like to share my experience with you. If there are any mistakes, please point them out. Thank you.

Today we are going to talk about the syntax conversion and polyfill of @babel/preset-env and plugin-transform-Runtime. Since @babel/polyfill is no longer recommended after Babel 7.4, @babel/ Polyfill is not covered in this article.

Preset-env

Babel V7 recommends using @babel/preset-env instead of many past polyfills, and today we can use preset-env to conveniently and quickly meet the needs of grammar shifts and polyfills.

@babel/preset-env is a smart preset that allows you to use the latest JavaScript without needing to micromanage which syntax transforms (and optionally, browser polyfills) are needed by your target environment(s).

Obviously, preset-env can be converted to a new syntax and can even be configured to transform a new API by configuring its options for functional support.

There are three key options that are commonly used for @babel/preset-env:

  • targets
  • useBuiltIns
  • corejs

target

The targets field is used to fill in the browserslist query string, which is officially recommended. The browserslistrc file is used to specify compiled targets, which can also be shared with tools like autoprefixer and stylelint.

Therefore, it is not recommended to use targets directly in the. Babelrc preset-env configuration to some extent.

If targets needs to be configured separately here, the configuration item of browserslistrc is ignored if ignoreBrowserslistConfig is set to true in preset-env.

useBuiltIns

The second is useBuiltIns used to specify polyfill schemes, which default is false and do not use preset-env to implement polyfills without actively importing, only using its default syntax conversion function.

If you use the default value false, you should avoid introducing polyfill in the entry file, which makes the packaging too bulky.

But if we need to use its Polyfill feature, there are two options:

  • entry
  • usage

Entry refers to the introduction of a Polyfill module that is not currently supported by all browsers, regardless of whether it is used in the project, based on the configuration of the browser target environment (Targets).

Install two packages first:

yarn add core-js@3 regenerator-runtime

Copy the code

All we need to do is introduce polyfill in the entry (or add these two packages as additional entry in the WebPack configuration file) :

import 'core-js/stable'

import 'regenerator-runtime/runtime'

Copy the code

For project development, this scheme is more secure. Although introducing all modules that are not currently supported by the browser may cause unused modules in some projects to take up some extra volume, you can avoid the improper handling of polyfill, the third-party library introduced in the project, and resulting in reference exceptions.

Second, when setting useBuiltIns to Usage, we do not need to manually introduce polyfill in the entry file, Babel will automatically inject polyfill based on our code usage, which will reduce the packaging volume when packaging.

The only problem: There will be reference exceptions when polyfill mishandles third-party libraries introduced in the project, and using popular libraries widely used by the community can reduce this risk.

corejs

Core-js is a fully modular javascript standard library.

It is recommended that browser polyfill be managed by Corejs uniformly.

Core-js V2 is no longer maintained. V3 is recommended

Let’s look at an example of an overall preset-env configuration using Entry:

// .babelrc

{

  "presets": [

    [

      "@babel/preset-env".

      {

        "targets": {

          "chrome": "80" //.browserslistrc is recommended

        },

        "useBuiltIns": "entry".

        "corejs": {

          "version": 3.Yarn add core-js@3 is required for version 2 and version 3

          "proposals": false

        }

      }

    ]

].

  "plugins": []

}

Copy the code

Personally, I do not recommend using the capabilities of proposals, only the features in the latest specification.

Then manually introduce polyfill in the entry file:

import 'core-js/stable';

import 'regenerator-runtime/runtime';

// other code

Copy the code

Plugin-transform-runtime

Please install the library before using:

Yarn add @babel/runtime // The default corejs isfalseIf core-js v3 runtime is used, @babel/runtime-corejs3 needs to be installed

yarn add -D babel-plugin-transform-runtime

Copy the code

In fact, polyfills of preset-env pollute the global environment, which is fine for a project development, but if we are developing a library for other developers, I think we should not pollute the global environment and provide better package size and efficiency.

A plugin that enables the re-use of Babel’s injected helper code to save on codesize.

The plugin-transform-Runtime does three main things:

  • Automatically introduced when developers use asynchrony or generators@babel/runtime/regeneratorDevelopers do not have to make additional introductions in entry files
  • Provide sandbox environment to avoid global environment pollution
  • removebabelinlinehelpers, unified use@babel/runtime/helpersInstead, reduce the packing volume

When using this scheme, there is no need to manually import core-js and Regenerator-Runtime in the entry file. You are advised to check the official documents for detailed configuration items.

Application Scenario Analysis

Both @babel/preset-env and plugin-transform-Runtime can be set to use Corejs to handle polyfills. Both have their own scenarios and can be used in different configurations for project development and class library development.

Do not configure core-JS functionality for both to avoid complex consequences.

Finally, let’s look at the Babel configuration items in two scenarios:

Project development

UseBuiltIns uses Usage to optimize package size by using quality libraries that are widely used in the community and not using features that are not yet in the specification. Plugin-transform-runtime only uses its feature of removing inline multiplexing auxiliary functions to reduce packaging volume.

{

  "presets": [

    [

      "@babel/preset-env".

      {

        // Targets officially recommends using the.browserslistrc configuration

        "useBuiltIns": "usage".

        "corejs": {

          "version": 3.

          "proposals": false

        }

      }

    ]

].

  "plugins": [

    [

      "@babel/plugin-transform-runtime".

      {

        "corejs": false // Default value, but still need yarn add @babel/runtime

      }

    ]

  ]

}

Copy the code

The class library development

Library development tries not to use polyfills that pollute the global environment, so @babel/preset-env is only used for syntactic conversions, polyfills are handled by plugin-transform-Runtime, core-js@3 is recommended, and preset features are not used.

{

  "presets": [

    [

      "@babel/preset-env".

    ]

].

  "plugins": [

    [

      "@babel/plugin-transform-runtime".

      {

        "corejs": {

          "version": 3.

          "proposals": true

        },

        "useESModules": true

      }

    ]

  ]

}

Copy the code

In general, it is important to refer to the official documentation when configuring the development environment to reduce the possibility of errors.

reference

  • @ Babel/preset – env, Babel

  • @ Babel/plugin – transform – runtime Babel

  • Learn from your Mistakes: What 99% of developers don’t know about Babel