【问题标题】:Which Babel transformers should I blacklist for a Chrome app?我应该将哪些 Babel 转换器列入 Chrome 应用程序的黑名单?
【发布时间】:2015-09-28 13:01:16
【问题描述】:

我正在编写 ES6+ 代码并使用 Babel 编译它(目前使用 {stage: 0} 作为我的 .babelrc 配置)。

所以我正在将所有内容编译到 ES5。但我只针对 Chrome v47+,它原生支持一些 ES6+ 功能。

我可以将哪个默认 Babel transformers 列入黑名单(禁用)并且仍然让我的代码在 Chrome 47+ 中运行?

【问题讨论】:

标签: javascript google-chrome ecmascript-6 babeljs


【解决方案1】:

可用的 ES6+ 功能

ES6 Feature             Release   Babel Transformer                   Spec. Compliant*
--------------------------------------------------------------------------------------
Rest Parameters        | 47      | es6.parameters                    | ✔
Spread                 | 46      | es6.spread                        | ✔
Arrow Functions        | 45      | es6.arrowFunctions                | ✔
Extended Obj. Literals | 45      | es6.properties.shorthand/computed | ✘
Computed Prop. Names   | 44      | es6.properties.shorthand/computed | ✘
Classes                | 42      | es6.classes                       | ✘
Template Strings       | 41      | es6.templateLiterals              | ✘
Generators             | 39      | regenerator                       | ✘
JS iterators           | 38      | es6.forOf                         | ✘
Block bindings         | 18      | es6.blockScoping/constants        | ✘

*我已经导出了 Spec 列。通过查看当前实现所基于的规范草案来符合(re: Chrome not Babel)。例如“Editor's Draft”——我认为这意味着实现可能不完整或不正确。

______

Babel Transformer 依赖项

这些是我从 Babel 源代码中确定的转换器之间的依赖关系:

Transformer               Dependencies
--------------------------------------------
es7.classProperties      | es6.classes
es7.decorators           | es6.classes
es7.asyncFunctions       | es6.classes
es7.objectRestSpread     | es6.destructuring

______

结论

似乎没有 ES6 Babel 转换器依赖于另一个。因此,任何在 Chrome 中实现的 ES6 功能,都是规范的。兼容,你不再需要依赖 Babel。它们是:es6.parameterses6.spreades6.arrowFunctions

【讨论】:

  • 很好的答案!也感谢您的参考:)
  • 出色的答案,谢谢。但是,如果不是 100% 符合规范,您是否会排除使用 Chrome 原生功能?通过查看compat table 中未涵盖的确切内容,如果我愿意接受小的不合规细节,我似乎可以启用一些额外的功能——例如。 ES6 类只在严格模式下工作,如果你总是使用严格模式,这没问题。这是一个公平的立场还是我错过了什么?
  • @callum - 存在实现更改并且您的代码不再按预期运行的风险。当然,只要你愿意在这方面放弃稳定,你的立场是公平的。我承认实现的改变足以严重影响您的应用程序的可能性很小,我的回答是迎合那些我们绝对可以说足够安全以开始本地使用的功能。你有一些喘息的空间!
【解决方案2】:

目前它不像为环境支持的功能禁用转换器那么简单,因为某些转换器依赖于其他转换器。例如,es7.asyncFunctions 转换器依赖于es6.classes,即使对于本机支持类的环境也是如此。通过“依赖”,我并不是说es7.asyncFunctions 自动调用es6.classes,我的意思是es6.classes 必须单独启用(明确地或不被列入黑名单)。见babel/babel#2415

也可能感兴趣:babel/babel#2340

【讨论】:

  • 这个。此外,Chrome 在 v47 中支持有许多功能,但要么不是 100% 完整,要么不符合规范。根据 OP 代码要求和应用程序需求,他们可能希望适当地禁用转换器。
猜你喜欢
  • 2014-05-08
  • 1970-01-01
  • 1970-01-01
  • 2012-05-04
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-01-03
  • 2020-01-11
相关资源
最近更新 更多