它是一個編譯器可讓你使用最新版本的ES規範好比ES2015(ES6),ES2016(ES7),ES2017(ES8)的寫法並把它編譯成老的ES5的寫法。前端
首先babel的轉換其實作了兩件事情node
let array = [1, 2, 3, 4, 5, 6]; array.includes(item => item > 2); ----------------------------> 轉換後 var array = [1, 2, 3, 4, 5, 6]; array.includes(function (item) { return item > 2; });
let array = [1, 2, 3, 4, 5, 6]; array.includes(item => item > 2); new Promise() async function a(){ console.log(1); } --------------------------->轉換後 "use strict"; require("regenerator-runtime/runtime"); require("core-js/modules/es6.promise"); require("core-js/modules/es6.object.to-string"); require("core-js/modules/es7.array.includes"); var array = [1, 2, 3, 4, 5, 6]; array.includes(function (item) { return item > 2; }); new Promise(); function a() { return regeneratorRuntime.async(function a$(_context) { while (1) { switch (_context.prev = _context.next) { case 0: console.log(1); case 1: case "end": return _context.stop(); } } }); }
可是可是,"平平無奇"的babel自己只會轉義語法,可是咱們還想用Promise,Object.assign
等等。因此就會有這麼大一堆不明因此的東西es6
@babel/polyfill,@babel/preset-env,@babel/plugin-transform-runtime,@babel/runtimejson
很容易理解,它就是各類API墊片,只要在主入口引用import '@babel/polyfill'
,就能完美使用各類新的API,徹底沒有任何須要配置的地方。api
可是可是,這樣就是把整個第三方墊片引入,打包出來會很是的大。因此就用到接下來的@babel/preset-envpromise
@babel/preset-env 主要乾的事情呢,根據你的設置表示你要啥,它就給你啥,很少給也很多給。
使用@babel/preset-env最主要的配置字段就是useBuiltIns
和target
瀏覽器
//babel.config.js const presets = [ [ "@babel/env", { targets: { "browsers": ["> 1%", "last 2 versions", "not ie <= 8"] }, useBuiltIns: "usage", }, ], ]; module.exports = { presets };
target表示因此編譯的代碼運行的環境,能夠是瀏覽器,能夠是node,只要設置相應的字段,它就能根據規則插入和轉義相應的語法跟APIbabel
例如如下的 "browsers": ["> 1%", "last 2 versions", "not ie <= 8"]
表示兼容市場佔有率>1%,瀏覽器的最新兩個版本,ie8如下不兼容async
useBuiltIns有三種取值,不一樣的取值會影響API的導入方式函數
就是不用polyfill,若是在業務入口 import '@babel/polyfill'
, 會無視 .browserslist 將全部的 polyfill 加載進來。
須要手動import '@babel/polyfill'
,它會根據targets
中的配置來過濾出polyfill
不須要手動import '@babel/polyfill'
(加上也無妨,編譯時會自動去掉), 且它會根據targets
中的配置來過濾出polyfill + 業務代碼使用到的新 API 按需進行 polyfill。
useage並不會對第三方包作檢測,因此若是某些第三包使用高級的API那麼在低版本的瀏覽器上也是會報錯的,例如:Array.from
基本上的開發使用@babel/preset-env
+@babel/polyfill
已經徹底很完美了
可是以上看起來好完美,可是還有一個巨大問題!!!
"use strict"; require("regenerator-runtime/runtime"); require("core-js/modules/es6.promise"); require("core-js/modules/es6.object.to-string"); require("core-js/modules/es7.array.includes"); var array = [1, 2, 3, 4, 5, 6]; array.includes(function (item) { return item > 2; }); new Promise(); function a() { return regeneratorRuntime.async(function a$(_context) { while (1) { switch (_context.prev = _context.next) { case 0: console.log(1); case 1: case "end": return _context.stop(); } } }); }
以上全部的墊片的導入都是直接掛載在全局對象上的,對於寫業務API的時候這樣並不影響使用,可是若是對於開發第三方包的狀況,babel-polyfill 會污染全局變量,給不少類的原型鏈上都做了修改,這種狀況就會變得很是不可控。
更改babel配置
const presets = [ [ "@babel/env", { targets: { "browsers": ["> 1%", "last 2 versions", "not ie <= 8"] }, // useBuiltIns: "usage", }, ], ]; const plugins = [ [ "@babel/plugin-transform-runtime", { "corejs": false, "helpers": true, "regenerator": true, "useESModules": false } ] ] module.exports = { presets,plugins };
其中的corejs參數有坑,後面說!
咱們在來看看打包結果
"use strict"; var _interopRequireDefault = require("@babel/runtime-corejs2/helpers/interopRequireDefault"); var _regenerator = _interopRequireDefault(require("@babel/runtime-corejs2/regenerator")); var _promise = _interopRequireDefault(require("@babel/runtime-corejs2/core-js/promise")); // import "@babel/polyfill" var array = [1, 2, 3, 4, 5, 6]; array.includes(function (item) { return item > 2; }); new _promise.default(); function a() { return _regenerator.default.async(function a$(_context) { while (1) { switch (_context.prev = _context.next) { case 0: console.log(1); case 1: case "end": return _context.stop(); } } }); }
是否是很神奇全部的新api都包裹在一個對象裏,沒有去污染全局變量。
soga,既然這麼神奇,爲嘛不直接一步到位用這種方法呢?
咱們仔細一點看的話,發現下面的代碼並無被轉化,這就是babel/plugin-transform-runtime的缺點了,它並無去轉義實例新API的方法,若是在代碼裏使用到了新API的實例方法,這裏是會跪的。
var array = [1, 2, 3, 4, 5, 6]; array.includes(function (item) { return item > 2; });
還須要留意的一點,在package.json下@babel/plugin-transform-runtime是在devDependencies,@babel/runtime是在dependencies下(由於裏面都是轉化的API墊片)
"devDependencies": { "@babel/plugin-transform-runtime": "^7.7.6", }, "dependencies": { "@babel/runtime": "^7.7.6" }
@babel/runtime內部集成了
轉換一些內置類 (Promise, Symbols等等) 和靜態方法 (Array.from 等)。絕大部分轉換是這裏作的。自動引入
做爲 core-js 的拾遺補漏,主要是 generator/yield 和 async/await 兩組的支持。當代碼中有使用 generators/async 時自動引入。
最後大殺器,無敵巨坑:corejs3
咱們應該常常在其餘文檔和使用說明中看到 runtime 不支持實例方法,確實在以前的使用中,不管是 Babel 7.0.0 ~ 7.4.0 抑或 Babel < 7.0.0, 對此都無能爲力。只能經過配置 corejs (可選 false | 2)來決定是否使用 babel/runtime-corejs 替代core-js 抑或 polyfill (可選 true | false)來決定是否全局引入新的內置函數(new built-ins),然而其實這二者並無根本改變, corejs: 2 實際上等同於 7.0.0 版本以前的 polyfill: true。
重點: 真正的改變出如今 Babel 7.4.0 以後,你能夠選擇引入 @babel/runtime-corejs3,設置 corejs: 3 來幫助您實現對實例方法的支持。
若是在Babel 7.4以後的版本,更改配置corejs : 3
const plugins = [ [ "@babel/plugin-transform-runtime", { "corejs": 3, //"corejs": false // 可選 false | 2 | 3 "helpers": true, "regenerator": true, "useESModules": false } ] ] module.exports = { presets,plugins };
在看轉化結果
var _includes = _interopRequireDefault(require("@babel/runtime-corejs3/core-js-stable/instance/includes")); var array = [1, 2, 3, 4, 5, 6]; (0, _includes.default)(array).call(array, function (item) { return item > 2; });
它連實例API都轉了,(早幹嗎去了,前端ER真的學不動了!!!!
最後附上Webpack版本Babel配置
{ "presets": [ [ "@babel/preset-env", targets: { "browsers": ["> 1%", "last 2 versions", "not ie <= 8"] }, ], ], "plugins": [ ["@babel/plugin-transform-runtime", { "corejs": 3 }] ] }