乐趣区

关于babel7:如何添加-babel-polyfill

jiezi

因为 Babel 7.4 之后不再举荐应用 @babel/polyfill，而 @babel/preset-env 和 plugin-transform-runtime 二者都能够设置 corejs 来解决 polyfill。

@babel/polyfill废除的次要起因有：

  • 此包仅仅是引入了 stable core-js 和 regenerator-runtime/runtime，其中后者能够应用插件 @babel/plugin-transform-regenerator 代替。
  • 此包不能从 core-js@2 平滑过渡到 core-js@3。

Babel 简介

简略来说，Babel 是一个编译器，次要用于将采纳 ECMAScript 2015+ 语法编写的代码转换为向后兼容的 JavaScript 语法，以便可能运行在新旧版本的浏览器等各个环境中。而 Babel 代码转换性能以 plugin 的形式实现，plugin 就是小型的 JavaScript 程序。

preset能够被看作是一组 Babel 插件或 options 配置的可共享模块。

  • plugins 在 presets 前运行；
  • plugins 从前往后程序执行；
  • presets 依据排列程序倒序执行；

babel 次要实现的两个性能：

  1. 转换新语法。将新版 js 语法用旧版语法实现，从而在对应环境中运行，比方箭头函数；

  2. 转换新 API。为旧版运行时打补丁(也被称为 polyfill)，从而应用在新版 js 中定义但在旧版运行时提供的性能，包含三类：

    • 新定义的内置对象，例如 Promise
    • 原有内置对象新增加的静态方法，例如 Array.from
    • 原有内置对象新增加的实例办法，例如 Array.prototype.includes

preset-env

preset-env 既能够转换新语法，也能够通过配置转换新的 API。preset-env 的 polyfill 会净化全局环境。

target

这个字段能够填写 browserslist 的查问字符串，官网举荐应用 .browserslistrc 文件去指明编译的 target，这个配置文件还能够和 autoprefixer、stylelint 等工具一起共享配置。所以不举荐在 .babelrc 的preset-env配置中间接应用 targets 进行配置。

如果须要独自在这里配置 targets 的话，preset-env中指明 ignoreBrowserslistConfig 为true则疏忽 .browserslistrc 的配置项。

useBuiltIns

是否应用其 polyfill 性能（全局环境的 core-js）。有三个值：

  • false：默认值。在不被动 import 的状况下不应用 preset-env 来实现polyfills，只应用其默认的语法转换性能。如果应用默认值false，则应该防止在入口文件引入polyfill，使得打包体积过大。

  • entry：须要手动在入口处引入 polyfill，依据浏览器指标环境 (targets) 的配置，引入全副浏览器暂未反对的 polyfill模块，无论在我的项目中是否应用到。

    import "core-js/proposals/string-replace-all"
  • usage：不须要手动在入口文件引入 polyfill，Babel 将会依据代码应用状况主动注入polyfill，如此一来在打包的时候将会绝对地缩小打包体积。

corejs

配置 core-js，默认值 ”2.0″。此选项仅在与 useBuiltIns: usage 或 useBuiltIns: entry 一起应用时无效。

core-js: JavaScript 的模块化规范库，蕴含 Promise、Symbol、Iterator和许多其余的个性，它能够让你仅加载必须的性能。

  • version:【string】版本号；
  • proposals:【boolean】是否实现提案中的个性；
// .babelrc
{
  "presets": [    
    [      
      "@babel/preset-env",      
      {        
        "targets": {"chrome": "80" // 举荐应用 .browserslistrc},        
        "useBuiltIns": "usage",        
        "corejs": {          
          "version": 3, // 2 和 3 版本都须要手动装置库：yarn add core-js@3 
          "proposals": false        
        }      
      }    
    ]  
  ]
}

plugin-transform-runtime

plugin-transform-runtime 次要做了三件事：

  • 当开发者应用异步或生成器的时候，主动引入@babel/runtime/regenerator，开发者不用在入口文件做额定引入；

  • 动静引入 polyfill，提供沙盒环境，防止全局环境的净化；

    如果间接导入 core-js 或 @babel/polyfill 以及它提供的 Promise、Set 和 Map 等内置组件，这些都会净化全局。尽管这不影响应用程序或命令行工具，但如果代码是要公布给其他人应用的库，或者无奈精确控制代码将运行的环境，则会呈现问题。

  • 所有 helpers 帮忙模块都将援用模块 @babel/runtime，以防止编译输入中的反复，减小打包体积；

corejs

配置值：false, 2, 或者 {version: number, proposals: boolean}，默认值 false。

corejs 装置倡议
false npm install –save @babel/runtime
2 npm install –save @babel/runtime-corejs2
3 npm install –save @babel/runtime-corejs3

helpers

配置值 boolean 类型，默认值 true。
是否用对 moduleName 的调用替换内联 Babel 帮忙程序（classCallCheck、extends 等）。

regenerator

配置值 boolean 类型，默认值 true。
是否将生成器函数转换为应用不净化全局范畴的再生器运行时。

useESModules

配置值 boolean 类型，默认值 false。
启用后，转换将应用帮忙程序，而不是 @babel/plugin-transform-modules-commonjs。这容许在 webpack 等模块零碎中进行较小的构建，因为它不须要保留 commonjs 语义。

应用场景剖析

@babel/preset-env 和 plugin-transform-runtime 二者都能够设置应用 corejs 来解决polyfill，二者各有应用场景，在我的项目开发和类库开发的时候能够应用不同的配置。

不要同时为二者配置 core-js，免得产生简单的不良后果。

我的项目开发

useBuiltIns 应用 usage。plugin-transform-runtime 只应用其移除内联复用的辅助函数的个性，减小打包体积。

{
  "presets": [
    [
      "@babel/preset-env",
      {
        "useBuiltIns": "usage",
        "corejs": {
          "version": 3,
          "proposals": false
        }
      }
    ]
  ],
  "plugins": [
    [
      "@babel/plugin-transform-runtime",
      {"corejs": false}
    ]
  ]
}

类库开发

类库开发尽量不应用净化全局环境的 polyfill，因而 @babel/preset-env 只施展语法转换的性能，polyfill 由 plugin-transform-runtime 来解决，举荐应用 core-js@3，并且不应用未进入标准的个性。

{"presets": ["@babel/preset-env"],
  "plugins": [
    [
      "@babel/plugin-transform-runtime",
      {
        "corejs": {
          "version": 3,
          "proposals": false
        },
        "useESModules": true
      }
    ]
  ]
}
退出移动版