>[success] # babel -- 总结 ~~~ 1.babel 三个主要阶段：解析（Parsing）,转化（Transformation）以及 代码生成（Code Generation）, 解析阶段生成tokens，根据语法解析生成ast，转化阶段对应规则将ast语法树生成新的语法树格式 ，代码生成阶段将新的语法树生成代码字符串，babel如图经过这些api 去转换 ~~~  >[danger] ##### 使用场景的区别 @babel/plugin-transform-runtime vs @babel/preset-env ~~~ 1.写类库时，使用`@babel/plugin-transform-runtime` 会配合'@babel/runtime',提取出helps作为共 用模块，进而缩小最终编译输出的体积,并且使用'@babel/runtime-corejs'不会产生垫片的全局污染 但是因此也失去了通过target 引入最小编译 和"foobar".includes("foo")就无法进行转换或兼容了 在写类库讲究是隔离和体积 2.写应用时，使用'@babel/preset-env' ,可以利用target 引入项目最小依赖和最小转换，在业务讲究 是根据环境最小引入 产生主要原因：因为babel 中插件的应用顺序是：先 plugin 再 preset，plugin 从 左到右，preset 从右到左，这样 plugin-transform-runtime 是在 preset-env 前面的。等 @babel/plugin-transform-runtime 转完了之后，再交给 preset-env 这时候已经做了无用的转换 了。而 @babel/plugin-transform-runtime 并不支持 targets 的配置，就会做一些多余的转换和 polyfill。 ~~~ >[danger] ##### 一个使用配置 ~~~ 1.二者可以组合使用的，下面就是只用'@babel/plugin-transform-runtime' 提取helper 函数能力 但不用他不污染全局垫片，是为了让"@babel/env" target 可以进行最小依赖特性 { "presets": [ [ "@babel/env",{ "useBuiltIns": "usage", // 按需引入corejs "targets": { "chrome":20 }, "corejs": 3, // 使用corejs3 版本 "debug":true // 打印出来使用插件 } ] ], "plugins": [ [ "@babel/plugin-transform-runtime", { "corejs": false,// 不使用防止污染全局垫片 "helpers": true, "regenerator": true, } ] ] } ~~~