摘要：歸納總結在前端的發展過程中，的兼容性，一直是前端頭痛的問題，在以前的一些有些項目中，為解決瀏覽器兼容而花費的時間甚至還要多余實際的業務邏輯開發時間，就是其中處理兼容的轉譯工具或者叫平臺。初稿完成初步規范。完成將被添加到下一年度發布。

github: babel歸納總結

在前端的發展過程中，javascript的兼容性，一直是前端頭痛的問題，在以前的一些有些項目中，為解決瀏覽器兼容而花費的時間甚至還要多余實際的業務邏輯開發時間，babel就是其中處理兼容的轉譯工具（或者叫平臺）。

javascript在不斷發展，新的提案標準每年都會有，在得到廣泛普及之前，Babel 把用最新標準編寫的 JavaScript 代碼向下編譯成可以在今天隨處可用的版本

babel的編譯過程分為3步，解析（parse），轉換（transform），生成（generate），對應的三個插件分別是Babylon、babel-traverse、babel-generator。
babylon將源碼轉換為抽象語法樹（AST）；babel-traverse通過AST生成一個便于操作、轉換的path對象，供我們的babel插件處理；babel-generator讀取AST并將其轉換為代碼和源碼映射。這些過程不是本文的關注點，我們關注的是結果，哪些插件與我們的生產息息相關，我們如何去使用babel的插件。

vue腳手架生成的項目在.babelrc文件中的配置：

{
  "presets": [
    ["env", {
      "modules": false,
      "targets": {
        "browsers": ["> 1%", "last 2 versions", "not ie <= 8"]
      }
    }],
    "stage-2"
  ],
  "plugins": ["transform-vue-jsx", "transform-runtime"]
}

babel插件推崇的是功能的單一性，就是每個插件的功能盡可能的單一，比如我要使用es6的箭頭函數，那就可以裝一個轉換插件npm i -D @babel/plugin-transform-arrow-functions，將其寫進.babelrc文件里就行了：詳情

{
  "presets": [],
  "plugins": ["@babel/plugin-transform-arrow-functions"]
}

這樣，我們寫的:

(a) => [...a]

會被該插件轉換為：

function (a) {
  return [...a]
}

這個插件也只解決箭頭函數的轉換，就算函數內部用了其它新語法也不管，這個好處是很明顯的，就跟咱寫項目推崇組件的細膩度一個道理

然而呢，js發展有點快，想一下那個es2015（es6）一下加了多少東西，我們要使用還得一個一個的npm i -D xxx，這個有點小麻煩，所以就可以采用presets配置項。npm i -D babel-preset-es2015，然后配置.babelrc。詳情

為了承接上文，這里暫時先用babel6的寫法，babel7里也可以用babel-preset-es2015，但是文檔里去掉了，es2015、es2016、es2017（2018年的東西直接寫在env里了，7月份2019年的新標準就要來羅@_@）等都被放在env里面了，以后這幾個preset會不會砍掉就不知道咯

{
  "presets": ["es2015"],
  "plugins": []
}

這樣我們就可以使用包括箭頭函數在內的es6的新語法而不用去擔心兼容問題。這下這兩個的關系也就清晰了，presets里面配置的是一些plugins集合

在babel 7.3.0里面，presets -- 對應插件有這些：

env -- @babel/preset-env

stage-0 -- @babel/preset-stage-0

stage-1 -- @babel/preset-stage-1

stage-2 -- @babel/preset-stage-2

stage-3 -- @babel/preset-stage-3

flow -- @babel/preset-flow

react -- @babel/preset-react

minify -- babel-preset-minify

typescript -- @babel/preset-typescript

在presets配置里面，我們看到了：

["env", {
  "modules": false,
  "targets": {
    "browsers": ["> 1%", "last 2 versions", "not ie <= 8"]
  }
}]

這個env是@babel/preset-env這個集合插件配置項，這里的配置項：

modules："amd" | "umd" | "systemjs" | "commonjs" | "cjs" | "auto" | false, defaults to "auto".

意思就是讓babel把es6 模塊轉化為其它模塊化類型。如果選擇 false 就不進行模塊化轉，我們的目標是瀏覽器，es6以前js是沒有模塊化的，commonjs、amd等只是社區方案，沒有瀏覽器支持的，所以我們設置為false，如果我們寫node上運行的代碼，就要設置為"commonjs"

target：就是告訴babel你的js要兼容哪些環境，它會幫你將你寫的js轉譯成目標環境兼容的js語法，這個具體配置可以看browserslist

那就是說，js無論用什么新玩意，@babel/preset-env都能跟我兼容到我想要的環境？帶著問題，我們再看看官網的介紹，What is Babel：

Transform syntax（轉換語法）

Polyfill features that are missing in your target environment （Ployfill新特性--也就是Api）

Source code transformations（源碼轉換）

And more！

再看看通過env轉換的幾個demo：

a => a
// 轉為
function (a) {return a}

function func (b = false) {return false}
// 轉為
function func (b) {
  b = b || false
  return b
}

比較明顯，上面的都屬于轉換語法，所以應該說“js無論用什么新語法，@babel/preset-env都能幫你兼容到目標環境”。

@babel/preset-env具體可以幫我們轉化哪些呢？看這兒JavaScript新特性和Babel插件的映射關系，這個是@babel/preset-env集合插件所包含的插件列表，每個插件對應轉換一個新特性，至于沒有的，比如promise、Array.from等，請往下看。

在上面的配置中，我們看到env下面有個stage-2。stage-x，這里面包含的都是當年最新規范的草案，每年更新。細分為如下幾步

Stage 0 - 稻草人: 只是一個想法，經過 TC39 成員提出即可。

Stage 1 - 提案: 初步嘗試。

Stage 2 - 初稿: 完成初步規范。

Stage 3 - 候選: 完成規范和瀏覽器初步實現。

Stage 4 - 完成: 將被添加到下一年度發布。

官網里有一句話It is important to note that @babel/preset-env does not support stage-x plugins.，就是說@babel/preset-env中不包含在草案階段的新屬性的轉換插件

其實我們通過plugin-features，以及proposals/finished-proposals（其中2019就是今年的stage-4）,可以發現@babel/preset-env是包含了stage-4階段的plugins的。

比如寫react的同學比較熟悉的decorators目前就處于stage-2階段，我們要用這些處于草案階段的新屬性，可以安裝npm i -D @babel/preset-stage-2，然后在presets里寫上stage-2，babel就會通過那些處于草案階段的新屬性的插件將我們代碼中的用到的新屬性轉譯成為es5

此外，低一級的 stage 會包含所有高級 stage 的內容，例如 stage-2 會包含 stage-2, stage-3 的所有內容。

Babel 幾乎可以編譯所有時新的 JavaScript 語法，但對于 APIs 來說卻并非如此。比如說：Promise、WeakMap、Array.from 、Object.assign、Array.prototype.includes、generator等。為了解決這個問題，我們使用一種叫做 Polyfill（代碼填充，也可譯作兼容性補丁） 的技術。能讓你提前使用還不可用的 APIs。

引入它很簡單，我們npm i -S @babel/polyfill，

在vue中的入口文件main.js文件的最上面：

import "@babel/polyfill";

或者在webpack入口里引入：

  module.exports = {
    entry: ["@babel/polyfill", "./main.js"],
  };

兩者任選其一

上面這兩種方式是將整個polyfill都引入了，很多代碼其實對我們是沒有用的，比如，我們的env配置的是不需要兼容ie9以下的瀏覽器，這種引入方式把所有兼容ie的代碼都引入了，包含ie8以下，所以，一般我們會在.babelrc文件里的env里配置下useBuiltIns參數，這樣babel在引入的時候會根據我們env環境去加載相應的polyfill：詳細

有如下三種方式

如果在 .babelrc 中設置 useBuiltIns: "usage"，則不要在 webpack.config.js entry 數組或 源碼中包含 @babel/polyfill。注意，仍然需要安裝 babel-polyfill（就是說 npm i -S @babel/polyfill后就不管了）。

如果在 .babelrc 中設置 useBuiltIns: "entry"，在應用程序入口（main.js）的頂部引入 @babel/polyfill。

如果在 .babelrc 中沒有明確設置useBuiltIns的值（就是你沒有去配置這項）或者設置了 useBuiltIns: false，將 @babel/polyfill 添加到 webpack.config.js 的入口數組中。

// .babelrc
{
  ["env", {
    "modules": false,
    "targets": {
      "browsers": ["> 1%", "last 2 versions", "not ie <= 8"]
    },
    // 是否自動引入polyfill，開啟此選項必須保證已經安裝了babel-polyfill
    // 在這里設置自動引入后，babel會根據你配置的兼容的環境，去按需加載polyfill的代碼，這樣能保證代碼量最少
    // 參數：Boolean，默認為false.
    "useBuiltIns": false
  }]
}
// webpack.base.conf.js
module.exports = {
  entry: ["@babel/polyfill", "./main.js"],
};

我們看到上面的配置中有個transform-runtime，這個是配置@babel/plugin-transform-runtime，它是做什么的呢？官網說：一個插件，通過重復使用babel注入的助手（helper）代碼，來減少代碼體積，我們看看它是如何工作的。

npm i -D @babel/plugin-transform-runtime

// .babelrc
{
  "plugins": [
    "@babel/plugin-transform-runtime",
    // 默認配置
      {
        "absoluteRuntime": false,
        "corejs": false,
        "helpers": true,
        "regenerator": true,
        "useESModules": false
      }
  ]
}

比如這個es6的class類：

class Person {
}

在沒有使用transform-runtime時，每個使用class函數處，Babel 會生成class的helper函數放置在文件頂部，就是說在多個文件里使用了class, babel就會在每個文件里面都生成相同的helper：

"use strict";

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);
};

這樣不必要的重復會使我們的代碼體積非常雍腫，transform-runtime就是來解決這個重復生成helper的問題的，它會將這個es6的class語法的helper函數放在babel-runtime/helpers里，然后在使用處通過require引入，這樣就沒必要在每個使用處重復定義helper了，達到了減少代碼體積的效果。

"use strict";

var _classCallCheck2 = require("babel-runtime/helpers/classCallCheck");

var _classCallCheck3 = _interopRequireDefault(_classCallCheck2);

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

var Person = function Person() {
  (0, _classCallCheck3.default)(this, Person);
};

@babel/runtime和@babel/polyfill這兩個模塊功能幾乎相同，就是轉碼新增 api

@babel/polyfill 把原生的方法重寫了，以promise為例，判斷環境promise存不存在，不存在就寫個全局作用域的promise。它會一次引入所有的api的polyfill，只是根據env配置引入的包大小可能會不同。

@babel/runtime 是寫了個helper函數，以promise為例，你代碼中的promise都會被換成_promise，然后babel會生成一個_promise helper函數，大致也是目標環境存在就用原生的，不存在就用polyfill的promise。而且這個是按需引入的，如果你的項目中只使用了promise，就只會引入promise的polyfill。但是它有個問題，實例上的方法無能為力，比如 Array上的form方法，String上的includes等

根據它們兩的特點，@babel/polyfil一般用于前端項目，@babel/runtime一般用來寫插件

Babel 的 CLI 是一種在命令行下使用 Babel 編譯文件的簡單方法。有時候我們只是寫一個插件，需要用babel轉一下我們代碼中的高階語法，因為項目可能不太大，用不到構建工具，就可以用babel-cil。轉換依據我們的.babelrc文件或者package.json中babel選項

編譯一個文件

babel my-file.js

如果我們想要把一個目錄整個編譯成一個新的目錄，可以使用 --out-dir 或者 -d。.

$ babel src --out-dir lib
# 或
$ babel src -d lib

babel-loader是什么呢？前面說了，我們可以通過babel-cil在命令行里告訴babel轉譯哪些js，也可以通過babel-register，在代碼里通過require來轉，但是，現在前端開發是一個工程化過程，依賴關系比較復雜，在一個稍微大點兒的項目中還真沒法手動告訴babel要處理哪些文件，比如一個.vue文件，里面還包含html、css，還有一些不是js的鬼語法，這時候就要借助其它插件先提前處理下，所以，webpack根據依賴關系，加載文件的時候遇到js文件后，會將文件內容的js字符串根據loader配置的先后順序，挨個兒傳遞給它們處理，babel-loader就是其中之一

babel就是將目標環境（瀏覽器）通過打補丁升級成支持最新javascript語法的環境的工具。

// .babelrc
{
    "presets": [
      ["env", {
        // 這里默認是false，不用再寫一遍
-        // "modules": false,
        // 一般不多帶帶寫出來，babel/preset-env會自個讀取package里面的browserslist，與css兼容環境保持一致
        // https://github.com/browserslist/browserslist
-      //  "targets": {
-        //  "browsers": ["> 1%", "last 2 versions", "not ie <= 8"]
-      //  },
      }],
      "stage-2"
    ],
    "plugins": ["transform-vue-jsx", "transform-runtime"]
  }

// webpack.base.conf.js
module.exports = {
  entry: ["@babel/polyfill", "./main.js"],
};

參考：

babel

Babel 用戶手冊

Babel 插件手冊

babel-vs-babel-core-vs-babel-loader

babel全家桶

tc39草案

你真的會用 babel 嗎？

babel-preset-env/data/plugin-features.js

babel-plugin-transform-runtime 和 babel-runtime 的區別？