共计 3293 个字符,预计需要花费 9 分钟才能阅读完成。
因为 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 次要实现的两个性能:
- 转换新语法。将新版 js 语法用旧版语法实现,从而在对应环境中运行,比方箭头函数;
-
转换新 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
}
]
]
}