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

47次阅读

共计 3293 个字符,预计需要花费 9 分钟才能阅读完成。

因为 Babel 7.4 之后不再举荐应用 @babel/polyfill,而 @babel/preset-envplugin-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 既能够转换新语法,也能够通过配置转换新的 APIpreset-envpolyfill 会净化全局环境。

target

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

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

useBuiltIns

是否应用其 polyfill 性能(全局环境的 core-js)。有三个值:

  • false:默认值。在不被动 import 的状况下不应用 preset-env 来实现polyfills,只应用其默认的语法转换性能。如果应用默认值false,则应该防止在入口文件引入polyfill,使得打包体积过大。
  • entry:须要手动在入口处引入 polyfill,依据浏览器指标环境 (targets) 的配置,引入全副浏览器暂未反对的 polyfill模块,无论在我的项目中是否应用到。

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

corejs

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

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

  • 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-envplugin-transform-runtime 二者都能够设置应用 corejs 来解决polyfill,二者各有应用场景,在我的项目开发和类库开发的时候能够应用不同的配置。

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

我的项目开发

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

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

类库开发

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

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

正文完
 0