Babel @babel/plugin-transform-runtime
本节咱们来学习 @babel/plugin-transform-runtime 和 @babel/runtime 。
Babel 中应用辅助函数来实现常见性能,例如 _extend() 函数,每个编译后的文件都须要定义它所须要应用的辅助函数。但这样显然会造成很多反复,所以 Babel 把所有的辅助函数都封装于 @babel/runtime,每个编译后的文件只须要援用 @babel/runtime 即可。
@babel/runtime 插件能够将工具函数的代码转换成 require 语句,指向为对 @babel/runtime 的援用。每当要转译一个 API 时,都要手动加上 require(‘@babel/runtime’)。简略说 @babel/runtime 更像是一种按需加载的实现,比方哪里须要应用 Promise,只有在这个文件头部增加如下代码即可:
require Promise from '@babel/runtime/core-js/promise'
而为了方便使用 @babel/runtime 插件,解决手动 require 的苦恼。它会剖析咱们的 ast 中,是否有援用 @babel/runtime (通过映射关系),如果有就会在以后模块顶部插入咱们须要的垫片。
transform-runtime 是利用插件自动识别并替换代码中的新个性,所以不须要再引入,只须要装好 @babel/runtime 和配置 plugin 就能够了。
装置配置
大多数状况下,咱们应该装置 @babel/plugin-transform-runtime 作为开发依赖项,即在装置命令中加上 –save-dev,并且将 @babel/runtime 作为生产依赖项,在装置命令中应用 –save。
装置命令如下所示:
> npm install --save-dev @babel/plugin-trabsform-runtime
> npm install --save @babel/runtime
装置好后,咱们能够在 .babelrc 配置文件中进行配置,@babel/plugin-transform-runtime 是否要开启某项性能,都是在配置项里设置的,某些配置项的设置是须要装置 npm 包。@babel/plugin-transform-runtime 在没有设置配置的时候,其配置项参数取默认值。
上面两个配置成果是一样的:
// 默认配置
{
"plugins": [
"@babel/plugin-transform-runtime"
]
}
// 设置其配置项
{
"plugins": [
[
"@babel/plugin-transform-runtime",
{
"helpers": true,
"corejs": false,
"regenerator": true,
"useESModules": false,
"absoluteRuntime": false,
"version": "7.0.0-beta.0"
}
]
]
}
配置项解说
- helpers:该配置项用来设置是否要主动引入辅助函数包,取值为布尔值,默认为 true。
切换是否用对moduleName的调用替换内联的babel帮忙程序(类调用查看、扩大等)。
- corejs:用来设置是否做 API 转换以防止净化全局环境。corejs 可选值为是 false、2 和 3。个别状况下 corejs 取值为 false,即不对 Promise 这一类的 API 进行转换。而在开发 JS 库的时候设置为 2 或 3。
- regenerator:和 corejs 一起用来设置是否做 API 转换以防止净化全局环境。regenerator 取值为布尔值,默认为 true。
- useESModules:用来设置是否应用 ES6 的模块化用法,取值为布尔值,默认为fasle。在用 webpack 一类的打包工具的时候,咱们能够设置为 true,以便做动态剖析。
- absoluteRuntime:用来自定义 @babel/plugin-transform-runtime 引入 @babel/runtime/ 模块的门路规定,取值是布尔值或字符串。没有非凡需要,咱们不须要批改,默认为 false 即可。
- version:该项次要是和 @babel/runtime 及其进化版 @babel/runtime-corejs2、@babel/runtime-corejs3 的版本号有关系,这三个包咱们只须要依据须要装置一个。咱们把装置的 npm 包的版本号设置给version 即可。
长处
- 不会净化全局变量。
- 屡次应用只会打包一次。
- 依赖对立按需引入,没有反复和多余的引入。
毛病
- 不反对实例化的办法,例 Array.includes(x) 就不能转化
- 如果应用的 API 用的次数不是很多,那么 transform-runtime 引入 polyfill 的包会比不是 transform-runtime 时大
- 随着利用的增大,雷同的 polyfill 每个模块都要做反复的工作(检测,替换),尽管 polyfill 只是援用,编译效率不够高效。
发表回复