【问题标题】:standard babel presets requirements标准 babel 预设要求
【发布时间】:2017-03-14 14:14:01
【问题描述】:

为了设置 webpack + babel + react,我被告知在 .babelrc 中包含以下内容:

"presets": ["latest", "stage-0", "react"]

我想了解:为什么要使用 babel 预设,它们允许我做什么(除了 babel 本身)?这是一个问题。希望这不是基于意见的(就 stackoverflow 而言),而是关于 babel 的工作原理。

据我在docs, preset-latest 中读到的,结合了preset-es2015 + preset-es2016 + preset-es2017。据我了解,这些是即将推出的 ES 版本的官方接受的功能,而 latest 不仅是选择 ES2015 的简写,而且是一次性选择所有未来版本的简写。规格不会改变,因此它足够稳定,可以在生产中使用。

但是stage-0stage-1stage-2stage-3 怎么样?它们代表的功能仍然是即将推出的 ECMAScript 版本的非官方提议,还是代表其他东西? Babel docs 对此并不清楚。这是第二个问题。

最后,插件预设有什么区别?

【问题讨论】:

  • 文档似乎涵盖了您的大部分问题:“现在,开箱即用的 Babel 不做任何事情。它基本上就像 const babel = code => code; 通过解析代码然后生成再次输出相同的代码。您需要为 Babel 添加一些插件才能执行任何操作(它们会影响第二阶段,转换)。预设不想组装自己的插件集?没问题!预设是可共享的.babelrc 配置或只是一组 babel 插件。每个年度预设仅编译当年批准的内容。使用预设最新来转换所有年度预设。"...
  • ... "Stage-X (Experimental Presets) stage-x 预设中的任何转换都是对尚未获准加入的语言的更改Javascript 的一个版本(例如 ES6/ES2015)。” babeljs.io/docs/plugins

标签: javascript ecmascript-6 babeljs


【解决方案1】:

...为什么要使用 babel 预设,它们允许我做什么...

一个 Babel 预设可以方便地定义一组 Babel 插件,这样您就不必在 .babelrc 中的 "plugins" 下(或在您声明配置的任何位置)明确声明要使用它们中的每一个。

看看es2016预设的源代码,你就会明白我的意思......它只是导出了一个插件数组:https://github.com/babel/babel/blob/master/packages/babel-preset-es2016/src/index.js

...(除了 babel 本身)?

Babel 本身就是它的插件的一个接口。它利用了一个兄弟程序babylonacorn 的一个分支,它为插件提供了一种特定的解析、检查和操作程序源代码的方式,以便根据插件添加您想要的功能你用。

最后,插件和预设有什么区别?

如前所述,预设本身不包含功能,而是包含插件列表。这些通常代表一些相关的功能组。例如,stage-0 预设将包含所有实现提案功能的插件,这些功能处于 ECMAScript 的“管理机构”TC39 定义的process of submission 的零阶段。

您可能已经注意到预设是 JavaScript 文件而不是 JSON。这是因为预设定义的插件列表可以从配置中派生。看一下env预设,例如:https://github.com/babel/babel-preset-env/blob/master/src/index.js

但是 stage-0、stage-1、stage-2、stage-3 怎么样?它们是代表即将到来的 ECMAScript 版本的非官方提议的功能,还是代表其他东西?

没有“官方”提案。任何人都可以提交提案。但是,如果您所说的官方是指该提案是否被认真考虑,那取决于 1)它处于流程的哪个阶段,以及 2)社区对其作为新功能的价值的普遍考虑。但是,即使是在最后阶段,您也应该始终对提案是否会被接受持保留态度,正如我们在Object#observe 中所经历的那样,即dropped at the very last minute

【讨论】:

    【解决方案2】:

    我也不明白为什么"modules": false 以及为什么有“env”设置以及env 有自己的预设配置。

    最后,我发现这篇文章What's in our .babelrc?解释得很好,例如

    其次,我们将 modules 设置为 false 以确保 import 语句是 保持原样(反对将它们转换为要求)。我们正在这样做 让 Webpack 能够静态分析我们的代码以生成 更高效的捆绑包。

    最后,我们为 Jest 提供了一个特定于环境的覆盖,我们的测试 选择的框架。由于 Jest 在 node 中运行,我们需要转译 我们的导入需要,并针对我们的任何节点运行时 目前正在工作。

    【讨论】:

      猜你喜欢
      • 2016-12-01
      • 2016-03-12
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2011-12-20
      • 1970-01-01
      • 2015-05-26
      • 2016-11-25
      相关资源
      最近更新 更多