@babel/preset-env, @babel/polyfill和@babel/plugin-transform-runtime

如果你不喜欢广告,请收藏我的网站,下次在网站中搜索
用真金白银赞赏有价值的内容,请通过文末二维码打赏

在平时通过babel转code的时候,有没有认真去研究一下这三个我们最常用的包呢?额……好像前面两个最常用,最后一个不常用。有没有去思考过,为啥要有这些包的区分?在什么情况下使用呢?这篇文章就讲解一下。

@babel/preset-env

这可以说是babel官方的得意之作,最早的时候没有这个包,有的是babel-preset-es2015这样的包,后来每次新标准发布之后,就要新加一个包。babel顺应民意,发布了babel-preset-env这个包,它一次性囊括了已发布的所有标准包。

首先我们需要明确一下,preset-env的首要作用,不是帮我们把ES6+代码转成ES5.它的首要作用是认读ES6+代码。在使用preset-env之前,babel是无法认识ES6+代码的,运行时会报Token错误。在使用preset-env之后,babel才能认识这些代码语法,并将它们抽象出AST树。

其次的作用,才是帮我们转码代码。babel preset说白了,就是一大堆babel plugin的集合。babel的一切转码功能都是靠插件完成的。当然,插件要发挥作用,离不开babel本身的AST抽象能力。也就是babel为插件提供了AST能力,而插件利用该能力,创建/修改AST。

preset-env本身包含了一大堆plugin,并通过配置来控制插件,从而控制转码效果。我们来看下它的几个我们需要了解的常用选项(非常用的不介绍)。

targets

转码之后,要兼容哪些环境。可以在这里控制目标浏览器。随着版本控制的不同,最终生成的代码量也不一样,所以,不要一次性兼容到最低版本,没必要。

它有一个特殊选项 targets.esmodules ,如果这个选项为true,那么表示直接转化为ES6模块规范,而不会转码到require。

modules

将当前模块加载类型转为哪个目标模块类型。默认为commonjs,设置为false时,不会转码模块加载,import from 语法不会转码,这样可以用来为webpack做tree shaking。

useBuiltIns

是否自动加载polyfill。它有三个值可选:false(默认), entry, usage。

默认false表示不自动加载polyfill,此时,需要你自己手动在项目中引入polyfill,这在下面一节细讲。

entry时,需要你在代码中自己手写 import 'core-js'  这行的代码(注意只需要在整个应用中写一次),但是在转码时,它会根据上文targets的情况,选择import对应的core-js模块,而不是把整个core-js都引入。

usage时,不需要你手写 import 'core-js' 但是它能自动识别你当前这个文件都用到哪些core-js模块,然后自动在转码后的代码中import进来。

当useBuiltIns为usage时,preset-env会在文件开头插入类似该图的语句,从而修改全局对象的原型链方法,这样做会污染全局

看上去有点麻烦,感觉好像直接用usage不就好了么。但是实际上,在使用过程中你自然而然就会发现需要采用不同的策略。

corejs

承接useBuiltIns,当useBuiltIns值为entry或usage时,有效。它可以设置为:2,3,{ version, proposals }

因为目前core-js只有2和3两个版本,以后可能会有更多版本。proposals是指提案,在ES标准中,有些提案是铁定会进入到标准的,虽然标准还没有发布,但是core-js已经将它们做进去了。通过 { version: 3, proposals: true } 就可以在代码中使用那些虽然没有被发布,但是肯定要进标准的提案了。

include/exclude

只包含/不包含被列出的文件需要被转码。注意,include如果被设置,那么只包含于这些文件中的文件才会被转码。

loose

这个选项设置为true时,它会尽可能的将ES6+代码转化为ES5标准代码,而非用ES5去实现的ES6+代码,最核心的体现就是class语法的实现。在ES5中,我们通过SomeFunction.prototype.someMethod来创建原型链方法,而在ES6中它的实现完全不同。当loose为true时,preset-env将class语法转化为原型链的实现方式。

@babel/polyfill

这个包是一个纯运行时的包,不是babel插件。它的作用是直接改写全局变量,从而让运行环境支持经过present-env转码后的代码。

大部分情况下,preset-env转码后的代码可以直接使用,但是在涉及到基于generator实现的语法时,例如 for...of 语法,则必须引入regenerator-runtime,因为转码后的代码会生成regeneratorRuntime这个全局变量,而@babel/polyfill引入了core-js和regenerator-runtime/runtime两个包。所以每次你安装完@babel/polyfill之后,它都会提示你,不要再用它了,直接用core-js和regenerator-runtime/runtime就好了。

在我们设置preset-env的useBuiltIns为false(默认值)时,preset-env不会为我们自动引入polyfill,我们要手动引入@babel/polyfill,并会导致整个core-js和regenerator-runtime/runtime被打包进我们的项目。这时,如果用webpack打包,bundle文件的体积应该是最大的。

useBuiltIns为entry时,我们手动引入@babel/polyfill,比false好的是,它不会把所有的core-js模块引入,而是只引入targets需要的。虽然引入的模块比直接引入@babel/polyfill少,但总体而言,它还是会引入很多模块。

使用usage模式,preset-env会自动帮你插入需要的core-js模块,不需要你手动import任何代码。缺点是:babel默认不会检测第三方依赖包代码,知会看当前文件中需要哪些polyfill,所以使用 usage 时,可能会出现引入第三方的代码包未注入模块而引发bug。

@babel/plugin-transform-runtime

这是一个babel插件,使用这个插件的同时,必须同时安装@babel/runtime这个包,而且必须是安装在dependencies里面,而非devDependencies里面。

它有两个作用:

  • 将preset-env所产生的helpers函数提出到一个独立文件中,从而减少代码量
  • 建立运行时沙盒,避免像babel-polyfill一样,修改全局对象,造成全局污染

当我们在写一个独立的第三方库时,在做构建的时候需要用到它。使用这个包之后,在我们自己写的库的代码体系内,可以实现上述两个效果,这样有利于减少代码量,同时又避免污染全局。

我们从它的配置项来看看这两个效果如何配置。

corejs

配置版本,传入corejs的值和同时安装的@babel/runtime包是不一致的,你需要手动安装。例如,你传入2则需要手动安装@babel/runtime-corejs2,传入3则需要手动安装@babel/runtime-corejs3,并且,这三个包只安装对应的一个就好,它们是互斥的。

corejs3有一些新特性,但是会增加代码量。

只有传入corejs之后,上面提到的“建立运行时沙盒”才会生效。它的效果实际上,就是在当前文件使用独立的变量来使用某些ES特性。

当配置了corejs为2时,文件顶部会被翻译出上面这句代码,在整个文件中,Object.keys接口会被替换为_Object$keys这个变量来进行,这样就可以避免污染全局的Object对象。

helpers

是否要将所有helper函数提炼到另外一个公共文件中。默认为true。

当使用@babel/plugin-trasnform-runtime之后,原本babel会直接在文件中创建一个helper函数,现在会采用require的方式,从@babel/runtime中引入这些函数,这样就可以减少代码量

一般情况下,@babel/plugin-transform-runtime插件不需要传入任何配置。在真正使用时,要配合@babel/preset-env同时使用,两者的corejs配置要一致,useESModules也要一致。

配置案例

经过上文的分析只会,从特性、代码量等考虑,当我们要打包一个提供给其他团队使用的第三方包时,我们来分析一下如下配置:

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

需要手动安装:

# 构建时用
npm i -D @babel/plugin-transform-runtime @babel/preset-env @babel/core
# 运行时用
npm i core-js@3 @babel/runtime-corejs3 regenerator-runtime

这样,我们就可以定制我们自己的包了。

而如果是构建整个应用,则不需要使用@babel/plugin-transform-runtime,配置如下:

{
	"presets": [
		["@babel/preset-env", { "modules": false, "useBuiltIns": "usage", "corejs": 3 }]
	],
	"env": {
		"test": {
			"presets": [
				["@babel/preset-env", { "useBuiltIns": "usage", "corejs": 3 }]
			]
		}
	}
}

手动安装:

# 构建时用
npm i -D @babel/preset-env @babel-core
# 运行时用
npm i core-js@3 regenerator-runtime

但是,使用 useBulitIns: 'usage' 不能保证所有的第三方库也使用了上面提到的构建方法,在这种情况下,干脆直接将所有的polyfill全部包含在应用中,从而避免出现有些小问题。

{
	"presets": [
		["@babel/preset-env", { "modules": false, "useBuiltIns": "entry", "corejs": 3 }]
	],
	"env": {
		"test": {
			"presets": [
				["@babel/preset-env", { "useBuiltIns": "entry", "corejs": 3 }]
			]
		}
	}
}

安装的包一样。并且,这个时候,你需要在你的 app 入口文件中增加如下两句:

import 'core-js'
import 'regenerator-runtime'

转码之后,import 'core-js'会被展开为很多行,但是它不会把整个core-js所有模块引入,而是只引入targets配置中所指出的环境所需要的模块。需要注意,不能将这两个包加入到webpack的entry中,否则无法产生babel-env应有的效果。

总之,不推荐直接不配置useBuiltIns而直接import '@babel/polyfill'的做法。

2019-11-07 8222

为价值买单,打赏一杯咖啡

本文价值82.22RMB
已有6条评论
  1. slw 2020-03-24 15:25

    希望你更新一下自己的配置讲解,你可能误解了

  2. 和振峰 2020-01-09 15:22

    @babel/plugin-transform-runtime 为什么在项目中不建议使用  
    corejs  使用 2 一般就够了吧

    • 和*峰 2020-01-09 15:29

      @babel/plugin-transform-runtime又这么多好处,干嘛必须在第三方包用 ,自己项目中不是更好

      • 否子戈 2020-01-10 18:12

        自己的第三方包项目

  3. 神奇海螺 2019-12-23 18:58

    帮助我弄清楚了心中的疑问,很实用。我想用于团队内容分享(注明出处),可以么?

    • 否子戈 2019-12-23 19:15

      可以,不过里面的内容还需要你自己甄别,我后来发现自己推荐的配置方式并不好,你可以根据自己的情况调整