Record their scattered harvest, essays.

Some basic

Babel role is to convert new features JS code is the code most browsers can run.
babel transcoding is divided into two parts, one is the syntax conversion, a conversion is the new API.
For conversion API is divided into two parts, one of which is private API, an example of a static method (Method Array.prototype.includes or the like) and global objects Object.assign like.
babel transcoding dependent plugin, plugin under no circumstances do just babel code => code.
plugin There are many, one imported, particularly troublesome, this time we know preset.

is a collection of many preset plugin, the configuration is as follows:

.babelrc file

{
  "presets": ["env"]
}

If there is a preset-env configuration items:

{
  "presets": [
    [
      "env",
      {
        // 这里就是配置项
      }
    ]
  ]
}

It can be observed if a preset configuration may need to be replaced with a string array, the first item is a preset name, the second term is opetions. plugin with preset.

Note: preset is executed from right to left, left to right plugin is executed, and the plugin performed prior to preset.

Upgrade babel6 to babel7 is disruptive, mainly usage summary polyfill and under different babel6 and babel7 in.

babel-polyfill

Mentioned above babel mainly do two things, one is transformational grammar, is compatible with a new API.

The role of babel-polyfill is compatible with the new API.

babel6

As far as I know, there are four ways to use polyfill in babel6 in:

The introduction of direct (impact globally, once and for all)

In the entrance file import 'babel-polyfill' / require('babel-polyfill'). Use webpack, then you can add the entry entry: ['babel-polyfill', 'src/index.js'].

Advantages:
once introduced, the global use.
Instance methods and static methods are converted, more comprehensive.

Disadvantages:
impact of global scope.
Break out of the pack is relatively large, no matter useless to have played into it.

Usage scenarios:
development of business projects, more comprehensive, so the problem will not be missed, such as the need for such an approach Object.assign or polyfill in ios8 above.
A separate introduction of the babel-runtime

And introduced directly at the inlet of different polyfill, polyfill the plug-in module is incorporated private.
For polyfill need to manually introduced,import Promise from 'babel-runtime/core-js/promise'

Pros:
The module is private, will not affect the global scope.
Break out of the pack because of the introduction of on-demand package will not be great.

Cons:
Because they do not affect the global scope, so it will not turn instance and static methods such API.
Manual introduction of the desired, it might be missing.

Usage scenarios:
development libraries, frameworks and the like can be used, as in the case of others with your knowledge of the thing and then you change someone else's global environment, and then to an embarrassing mistake.
Use babel-plugin-transform-runtime demand introduced

This plugin was not easy, there are several functions:
1. polyfill and plug-babel-runtime as the introduction of private, will not affect the global scope. And the introduction of automatic demand polyfill required, to avoid having to manually introduced one by one as babel-runtime.
2. You can extract various helper syntax conversion when each module is generated as a reference.
3. Automatic conversion generators / async.
Pros:
The module is private, will not affect the global scope.
Break out of the pack because of the introduction of on-demand package will not be great.
Automatic introduction of demand, no manual, to prevent the omission.
Extracting helper, greatly reducing redundant code.

Cons:
Because they do not affect the global scope, so it will not turn instance and static methods such API.

Usage scenarios:
with babel-runtime.

NOTE: The plug-in dependencies babel-runtime.
Disposed in a configuration item in babel-preset-env

{
   "presets": [
   	[
   		"env", 
   		{
   			"useBuiltIns": boolean
   		}
   	]
   ]
}

useBuiltIns option for dividing the inlet import 'babel-polyfill' / require(babel-polyfill)into the environment by introducing polyfill. The first embodiment is introduced in the same manner polyfill, but will be incorporated as needed according to the configuration of the environment, little better.

Summary:
Core 1. babel6 has babel-core babel-cli babel- node babel-register babel-polyfill, these will be modified babel7.
2. polyfill is dependent on the core-js
3. babel7.4 abandoned @ babel / polyfill directly dependent on core-js @ 2 or 3.

babel-plugin-transform-runtime configuration item

{
  "helpers": false, // defaults to true
  "polyfill": false, // defaults to true
  "regenerator": true, // defaults to true
  "moduleName": "babel-runtime" // defaults to "babel-runtime"
}

For automatic processing and extraction of helper dependent polyfill babel-runtime it is completed, so that the plug-in dependencies babel-runtime.

polyfill examples

input:

var promise = new Promise;

output:

var _promise = require("babel-runtime/core-js/promise");  // 注意这里，根本是从core-js里面引入的
 
var _promise2 = _interopRequireDefault(_promise);

function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }

var promise = new _promise2.default();

helper examples:

input:

class Person {}

usually turns into:

"use strict";
 // 这就是helper函数，每个模块都会被实现一遍，十分浪费，冗余。
function _classCallCheck(instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError("Cannot call a class as a function"); } }
 
var Person = function Person() {
  _classCallCheck(this, Person);
};

By runtime turn about:

"use strict";
 
var _classCallCheck2 = require("babel-runtime/helpers/classCallCheck"); // 从runtime中引入，没有再实现一遍
 
var _classCallCheck3 = _interopRequireDefault(_classCallCheck2);
 
function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }
 
var Person = function Person() {
  (0, _classCallCheck3.default)(this, Person);
};

generator is also require("babel-runtime/regenerator");introduced.

babel7

babel7 made major changes, abandoned stage-xthe preset, also added a namespace to distinguish between official and unofficial plug-in plug-ins, @ babel / core, @ babel / cli and so on.

Recommended @ babel / preset-env.

@babel/plugin-transform-runtime

The introduction of the plug-in has two main action

In babel7, the original plug-babel-plugin-transform-runtime also made changes -> @ babel / plugin-transform-runtime. And in function becomes powerful.

Remove the configuration items polyfill Tim, added corejs configuration items (default is polyfill).

.babelrc configuration:

{
  plugins: [
    ["@babel/plugin-transform-runtime", {
      "absoluteRuntime": false, // 不是很清除干啥的
      "corejs": false, // 下面详解
      "helpers": true, // 助手函数是否提取，同babel-plugin-transform
      "regenerator": true, // 同babel-plugin-transform
      "useESModules": false
    }]
  ]
}

For configuration items corejs: false | 2 | 3.

false reliance @ babel / runtime, in fact, and configuration Polyfill, is the default option.
2 dependent Babel @ / Runtime-corejs2
. 3 dependent @ babel / runtime-corejs3

corejs2 and corejs3 still very different. corejs2 convert only global variables (Object) and static methods (Object.assign), not conversion method (Array.prototype.includes) on the prototype, corejs3 method on the prototype will be converted.

Note transform-runtime add this plug-polyfill are private, it will not affect the global environment, but also demand the introduction, very nice.

Summary:
@ Babel / plugin-Transform-Runtime has three main functions:
- when a generators/asynctime automatic introduction @babel/runtime/regenerator.
- Adding new features implemented as API.
- extract each inline module helper who asked reference.

@babel/preset-env

In addition to the above said @babel/plugin-transform-runtimeplug, I would like to record the @babel/preset-envchange on the polyfill.

This preset in babel6 when he took a lot of features, this article only records related configuration and polyfill, useBuiltInsand corejs.

useBuiltIns

Is a boolean value in configuration item babel-preset-env in at @ babel / preset-env when the expansion of several options "useage"and "entry".

The default value is false, it would not automatically introduce polyfills, and does not process import "@ babel / polyfill" and import "corejs".

Note: babel7.4 give up @babel/polyfill, it is proposed to be used directly corejs.

entry

And options true babel-preset-env like automatically according to the needs of the environment division introduced polyfill. Note can only be introduced once at the entrance, many will complain.

You need to have the entrance documents import "core-js/stable"and import "regenerator-runtime/runtime".

usage

The introduction of demand will cause global pollution . In my understanding this option is just an entry enhancements, the need to introduce a manual at the entrance, and how much demand can be introduced in accordance with the usage characteristics.

corejs

Found: 2, or 3 { version: 2 | 3, proposals: boolean }, the default is 2.

This is a newly added configuration item. This option will only useBuiltInsoption usageor entryand @babel/preset-envworks if the correct version of the corresponding import corejs.

Stabilization of ECMAScript properties by default only injected. There are three characteristics can be modified:

At that time a configuration useBuiltIns: "entry"can be imported directly Proposalimport "core-js/proposals/string-replace-all"
At that time with useBuiltIns: usage when there are two options:
- The shippedProposals (another configuration item @ babel / preset-env's) option is set to true. This will enable the proposal have been provided for some time in the browser polyfill and conversion.
- Use corejs: {version：3，proposal：true}. Such padding for each core-js support the proposal can be achieved.