babel 7.0.0-0

by Henry Zhu

朱Henry

我们即将接近7.0 Babel版本。 这是我们一直在做的所有很酷的事情。 (We’re nearing the 7.0 Babel release. Here’s all the cool stuff we’ve been doing.)

> 6 months later, the actual release https://twitter.com/left_pad/status/1034204330352500736!

> 6个月后，实际发布https://twitter.com/left_pad/status/1034204330352500736 ！

Hey there ?! I’m Henry, one of the maintainers on Babel.

嘿 ？！ 我是亨利 ，是通天塔的维护者之一。

> EDIT: I’ve left Behance and have made a Patreon to try to pursue working on open source full time, please consider donating (ask your company).

>编辑：我已经离开Behance ，并创建了Patreon来尝试全职从事开源工作 ，请考虑捐赠(询问您的公司)。

巴别塔快速入门 (A quick intro to Babel)

Some people like to think of Babel as a tool that lets you write ES6 code. More specifically, a JavaScript compiler than will convert ES6 into ES5 code. That was pretty fitting back when its name was 6to5, but I think Babel has become a lot more than that.

有些人喜欢将Babel视为可让您编写ES6代码的工具。 更具体地说，JavaScript编译器会将ES6转换为ES5代码。 当它的名字是6to5时，这还算合适，但我认为Babel的意义已不止于此。

Now let’s back up a bit. The reason why this is even necessary in the first place is because, unlike most languages on the server (even Node.js), the version of JavaScript that you can run depends on your specific browser version. So it doesn’t matter if you are using the latest browsers if your users (that you want to keep) are still on IE. If you want to write the class A {} , for example, then you’re out of luck — some number of your users will get a SyntaxError and a white page.

现在让我们备份一下。 首先甚至需要这样做的原因是，与服务器上的大多数语言(甚至是Node.js)不同，可以运行JavaScript版本取决于特定的浏览器版本。 因此，如果您要保留的用户仍在IE上，则是否使用最新的浏览器都没有关系。 例如，如果您要编写class A {} ，那么您就不走运了-某些用户将收到SyntaxError和白页。

So that’s why Babel was created. It allows you to write the version of JavaScript you desire, knowing that it will run correctly on all the (older) browsers you support.

这就是创建Babel的原因。 知道它可以在您支持的所有(旧)浏览器上正确运行，它使您可以编写所需JavaScript版本。

But it doesn’t just stop at “ES6” (some people like to say ES2015). Babel has certainly expanded upon its initial goal of only compiling ES6 code, and now compiles whatever ES20xx version you want (the latest version of JavaScript) to ES5.

但这不仅止于“ ES6”(有些人喜欢说ES2015)。 Babel当然已经扩展了仅编译ES6代码的最初目标，现在可以将所需的任何ES20xx版本(JavaScript的最新版本)编译到ES5。

正在进行的过程 (The ongoing process)

One of the interesting things about the project is that, as long as new JavaScript syntax is added, Babel will need to implement a transform to convert it.

关于该项目的有趣事情之一是，只要添加了新JavaScript语法，Babel将需要实现转换以对其进行转换。

But you might be thinking, why should we even send a compiled version (larger code size) to browsers that do support that syntax? How do we even know what syntax each browser supports?

但是您可能会想，为什么我们还要向支持该语法的浏览器发送编译后的版本(更大的代码大小)？ 我们甚至如何知道每个浏览器支持什么语法？

Well, we made babel-preset-env to help with that issue by creating a tool that lets you specify which browsers you support. It will automatically only transform the things that those browsers don’t support natively.

好吧，我们制作了babel-preset-env来解决该问题，方法是创建一个工具，让您指定要支持的浏览器。 它将仅自动转换那些浏览器本身不支持的功能。

Beyond that, Babel (because of its usage in the community) has a place in influencing the future of the JavaScript language itself! Given that it is a tool for transforming JS code, it can also be used to implement any of the proposals submitted to TC39 (Ecma Technical Committee 39, the group that moves JavaScript forward as a standard).

除此之外，Babel(由于其在社区中的使用)在影响JavaScript语言本身的未来方面具有一定的地位！ 鉴于它是用于转换JS代码的工具，因此它也可以用于实施提交给TC39 (Ecma技术委员会39，该组织将JavaScript向前推进为标准的小组)的任何提案。

There is a whole process a “proposal” goes through, from Stage 0 to Stage 4 when it lands into the language. Babel, as a tool, is in the right place to test out new ideas and to get developers to use it in their applications so they can give feedback to the committee.

从“阶段0”到“阶段4”，进入“建议”阶段需要经历一个完整的过程。 Babel作为一种工具，在正确的位置进行测试，以测试新想法并使开发人员在其应用程序中使用它，以便他们可以向委员会提供反馈。

This is really important for a few reasons: the committee wants to be confident that the changes they make are what the community wants (consistent, intuitive, effective). Implementing an unspecified idea in the browser is slow (C++ in the browser vs. JavaScript in Babel), costly, and requires users to use a flag in the browser versus changing their Babel config file.

这确实很重要，原因有几个：委员会希望确信他们所做的更改是社区想要的(一致，直观，有效)。 在浏览器中实现未指定的想法很慢(浏览器中的C ++与Babel中JavaScript)，成本高昂，并且要求用户在浏览器中使用标志而不是更改其Babel配置文件。

Since Babel is so ubiquitous, there is a good chance that real usage will occur. This will make the proposal much better off than if it was just implemented without any vetting from the developer community at large.

由于Babel非常普及，因此很有可能会发生实际使用。 这将使该提案比仅在没有开发者社区的任何审查的情况下实施才更好。

And it is not just useful in production. Our online REPL is useful for people learning JavaScript itself, and allows them to test things out.

它不仅在生产中有用。 我们的在线REPL对于学习JavaScript本身的人们很有用，并允许他们进行测试。

I think Babel is in a great position to be an educational tool for programmers so they can continue to learn how JavaScript works. Through contributing to the project itself, they’ll learn many other concepts such as ASTs, compilers, language specification, and more.

我认为Babel可以成为程序员的教育工具，因此他们可以继续学习JavaScript的工作方式。 通过为项目本身做贡献，他们将学习许多其他概念，例如AST，编译器，语言规范等。

I’m really excited about the future of the project and can’t wait to see where the team can go. Please join and help us!

我对这个项目的未来感到非常兴奋，迫不及待地想知道团队的前进方向。 请加入并帮助我们！

我的故事 (My story)

Those are some of the reasons I get excited to work on this project each day, especially as a maintainer. Most of the current maintainers, including myself, didn’t create the project but joined a year after — and it’s still mindblowing to think where I started.

这就是我每天为从事此项目而感到兴奋的一些原因，尤其是作为维护者。 当前的大多数维护者，包括我自己，都没有创建该项目，而是在一年后加入了该项目，现在想着我从哪里开始仍然令人费解 。

As for me, I recognized a need and an interesting project. I slowly and consistently got more involved, and now I’ve been able to get my employer, Behance, to sponsor half my time on Babel.

对于我来说，我认识到一个需要和一个有趣的项目。 我一直持续地参与进来，现在我已经能够让我的雇主Behance赞助一半的Babel时间。

Sometimes “maintaining” just means fixing bugs, answering questions on our Slack or Twitter, or writing a changelog (it’s really up to each of us). But recently, I’ve decreased my focus on making bug fixes and features. Instead, I’ve been putting some time into thinking about more high level issues like: what’s the future of this project? How do we grow our community in terms of the number of maintainers versus of the number of users? How can we sustain the project in terms of funding? Where do we fit in the JavaScript ecosystem as a whole (education, TC39, tooling)? And is there a role for us to play in helping new people join in open source (RGSoC and GSoC)?

有时，“维护”仅意味着修复错误，在Slack或Twitter上回答问题或编写变更日志(这实际上取决于我们每个人)。 但是最近，我减少了对错误修复和功能的关注。 相反，我花了一些时间思考一些更高级的问题，例如：该项目的未来是什么？ 在维护者数量与用户数量方面，我们如何发展社区？ 我们如何才能在资金方面维持该项目？ 我们在整个JavaScript生态系统中适合什么地方(教育， TC39和工具)？ 在帮助新人们加入开源( RGSoC和GSoC )方面，我们可以扮演角色吗？

Because of these questions, what I’m most excited about with this release isn’t necessarily the particulars in the feature set (which are many: initial implementations of new proposals like the Pipeline Operator (a |> b), a new TypeScript preset with help from the TS team, and .babelrc.js files).

由于这些问题，我对该版本最兴奋的不一定是功能集中的细节(很多：新建议的初始实现，例如管道操作符(a |> b) ， 新的TypeScript预设)在TS小组的帮助下以及.babelrc.js文件)。

Rather, I’m excited about what all those features represent: a year’s worth of hard work trying not to break everything, balancing users’ expectations (why is the build so slow/code output so large, why is the code not spec-compliant enough, why doesn’t this work without configuration, why isn’t there an option for x), and sustaining a solid team of mostly volunteers.

相反，我对所有这些功能代表什么感到很兴奋：一年的辛苦工作试图不破坏所有内容，平衡用户的期望(为什么构建如此缓慢/代码输出如此之大，为什么代码不符合规范？足够了，为什么没有配置就无法工作，为什么x)没有选项，并维持一支由志愿者组成的强大团队。

And I know our industry has a huge focus on “major releases,” hyped features, and stars, but that’s just one day that fades. I’d like to suggest we continue thinking about what it takes to be consistent in pushing the ecosystem forward in a healthy fashion.

而且我知道我们的行业非常关注“主要版本”，大肆宣传的功能和明星，但这只是一天而已。 我想建议我们继续考虑以健康的方式推动生态系统保持一致所需要的条件。

This could simply mean thinking about the mental and emotional burden of maintainer-ship. It could mean thinking about how to provide mentorship, expectation management, work/life balance advice, and other resources to people wanting to get involved, instead of just encouraging developers to expect immediate, free help.

这可能只是意味着要考虑维护者的精神和情感负担。 这可能意味着思考如何为希望参与其中的人们提供指导，期望管理，工作/生活平衡建议以及其他资源，而不仅仅是鼓励开发人员期望获得直接，免费的帮助。

进入变更日志 (Diving into the changelog)

Well, I hope you enjoy the long changelog ?. If you’re interested in helping us out, please let us know and we’d be glad to talk more.

好吧，希望您喜欢冗长的变更日志？ 如果您有兴趣帮助我们，请告诉我们，我们很乐意谈论更多。

We started a new videos page, since people wanted to learn more about how Babel works and contribute back. This page contains videos of conference talks on Babel and related concepts from team members and people in the community.

我们开始了一个新的视频页面 ，因为人们想了解更多有关Babel如何工作并做出贡献的信息。 本页包含团队成员和社区中有关Babel的会议演讲视频以及相关概念。

We also created a new team page! We will be updating this page in the future with more information about what people work on and why they are involved. For such a large project, there are many ways to get involved and help out.

我们还创建了一个新的团队页面 ！ 将来，我们将在此页面上进行更新，以提供有关人们从事的工作以及参与其中的原因的更多信息。 对于如此大的项目，有很多参与和帮助的方法。

Here are some highlights and quick facts:

以下是一些重点和快速事实：

• Babel turned 3 years old on September 28, 2017!

  Babel于2017年9月28日满3岁！

• Daniel moved babel/babylon and babel/babel-preset-env into the main Babel monorepo, babel/babel. This includes all Git history, labels, and issues.

  丹尼尔(Daniel) 将 babel/babylon和babel/babel-preset-env移至主要的Babel monorepo babel / babel中 。 这包括所有Git历史记录，标签和问题。

• We received a $1k/month donation from Facebook Open Source!

  我们收到了来自Facebook Open Source的每月1000美元的捐款 ！

• This the highest monthly donation we have gotten since the start (next highest is $100/month).这是自开始以来我们获得的最高每月捐款(第二高是每月100美元)。
• In the meantime, we will use our funds to meet in person and to send people to TC39 meetings. These meetings are every 2 months around the world.同时，我们将使用我们的资金进行面对面交流，并派人参加TC39会议。 这些会议每2个月在全球举行一次。
• If a company wants to specifically sponsor something, we can create separate issues to track. This was difficult before, because we had to pay out of pocket or find a conference to speak at during the same week to help cover expenses.如果一家公司想专门赞助某件事，我们可以创建单独的问题进行跟踪。 以前很难做到这一点，因为我们不得不在同一周内自掏腰包，或找一个会议要讲话以帮助支付费用。

您将如何提供帮助 (How you can help)

If your company would like to give back by supporting a fundamental part of JavaScript development and its future, consider donating to our Open Collective. You can also donate developer time to help maintain the project.

如果您的公司想通过支持JavaScript开发的基本部分及其未来来回报自己，请考虑向我们的Open Collective捐款。 您还可以捐赠开发人员时间来帮助维护项目。

1：帮助维护项目(开发人员的工作时间) (1: Help maintain the project (developer time at work))

Engineer: There's a thing in SQL Server Enterprise blocking usCompany: Let's set up a call next week with them an ongoing discussion to resolve it next quarterEngineer: There's a thing we need in babel, can I spent 2 days with a PR for itCompany: lol no it's their job https://t.co/icgaoJ0dTe

— Shiya (@ShiyaLuo)

工程师：SQL Server Enterprise中有件事阻止了我们公司：下周让我们与他们进行电话讨论正在进行的讨论，以在下个季度解决该问题工程师：我们需要babel的东西，我可以为它花2天的PR吗公司：大声笑不，这是他们的工作https://t.co/icgaoJ0dTe

-诗雅(@ShiyaLuo)

November 16, 2017

2017年11月16日

The best thing for Babel is finding people who are committed to helping out with the project, given the massive amount of work and responsibility it requires. Again, I never felt ready to be a maintainer, but somehow stumbled upon it. But I’m just one person, and our team is just a few people.

对于Babel而言，最好的事情是，找到需要致力于帮助该项目的人员，因为它需要大量的工作和责任。 再说一次， 我从未感到自己准备成为一名维护者，但不知何故偶然发现了它。 但是我只是一个人，我们的团队只有几个人。

2：帮助资金发展 (2: Help fund development)

Company: "We'd like to use SQL Server Enterprise"MS: "That'll be a quarter million dollars + $20K/month"Company: "Ok!"...Company: "We'd like to use Babel"Babel: "Ok! npm i babel --save"Company: "Cool"Babel: "Would you like to help contribute financially?"Company: "lol no"

— Adam Rackis (@AdamRackis)

公司：“我们想使用SQL Server Enterprise” MS：“这将是25万美元+每月2万美元”公司：“好！” ...公司：“我们想使用Babel” Babel：“好！npm i babel --save”公司：“酷” Babel：“您想帮助财务上的贡献吗？”公司：“大声笑”

-亚当·拉基斯(@AdamRackis)

November 16, 2017

2017年11月16日

We definitely want to be able to fund people on the team so they can work full-time. Logan, in particular, left his job a while ago and is using our current funds to work on Babel part time.

我们绝对希望能够为团队中的人员提供资金，以便他们可以全职工作。 特别是洛根(Logan)离开了他的工作一段时间，现在正使用我们目前的资金从事兼职工作。

3以其他方式做出贡献？ (3 Contribute in other ways ?)

For example, Angus made us an official song!

例如， 安格斯(Angus)使我们成为官方歌曲 ！

升级中 (Upgrading)

We will also be working on an upgrade tool that will help rewrite your package.json/.babelrc files and more. Ideally, this means it would modify any necessary version number changes, package renames, and config changes.

我们还将开发一种升级工具，该工具将帮助重写package.json / .babelrc文件等。 理想情况下，这意味着它将修改所有必要的版本号更改，程序包重命名和配置更改。

Please reach out to help and to post issues when trying to update. This is a great opportunity to get involved and help the ecosystem update!

尝试更新时，请与我们联系以寻求帮助并发布问题。 这是参与并帮助生态系统更新的绝佳机会！

上一篇文章的摘要 (Summary of the previous post)

• Dropped Node 0.10/0.12/5 support.放弃对节点的支持0.10 / 0.12 / 5。

• Updated TC39 proposals

  更新的TC39提案

• Numeric Separator: 1_000

  数字分隔符： 1_000

• Optional Chaining Operator: a?.b

  可选的链接运算符： a?.b

• import.meta (parseble)

  import.meta (可解析)

• Optional Catch Binding: try { a } catch {}

  可选的捕获绑定： try { a } catch {}

• BigInt (parseble): 2n

  BigInt(parseble)： 2n

• Split export extensions into export-default-from and export-ns-form

  将导出扩展拆分为export-default-from和export-ns-form

• .babelrc.js support (a config using JavaScript instead of JSON)

  .babelrc.js支持(使用JavaScript而不是JSON的配置)

• Added a new Typescript Preset and separated the React/Flow presets添加了新的Typescript预设并分离了React / Flow预设

• Added JSX Fragment Support and various Flow updates

  添加了JSX Fragment支持和各种Flow更新

• Removed the internal babel-runtime dependency for smaller size

  删除了内部babel-runtime依赖以减小大小

最新更新的TC39提案 (Newly updated TC39 proposals)

• Pipeline Operator: a |> b

  管道运算符： a |> b

• Throw Expressions: () => throw 'hi'

  抛出表达式： () => throw 'hi'

• Nullish Coalescing Operator: a ?? b

  空位合并运算符： a ?? b a ?? b

不建议使用的年度预设(例如babel-preset-es20xx) (Deprecated yearly presets (e.g. babel-preset-es20xx))

TL;DR: use babel-preset-env.

TL; DR：使用babel-preset-env 。

What’s better than you having to decide which Babel preset to use? Having it done for you, automatically!

有什么比您必须决定使用哪个Babel预设更好的呢？ 为您自动完成！

Even though the amount of work that goes into maintaining the lists of data is humongous — again, why we need help — it solves multiple issues. It makes sure users are up to date with the spec. It means less configuration/package confusion. It means an easier upgrade path. And it means fewer issues about what is what.

即使维护数据列表所需的工作量巨大，这又是我们需要帮助的原因，但它可以解决多个问题。 这样可以确保用户了解最新的规范。 这意味着更少的配置/软件包混乱。 这意味着更简单的升级途径。 这意味着什么是更少的问题。

babel-preset-env is actually a pretty old preset that replaces every other syntax preset that you will need (es2015, es2016, es2017, es20xx, latest, and so on).

babel-preset-env实际上是一个相当旧的预设，它将替换您将需要的所有其他语法预设(es2015，es2016，es2017，es20xx，最新等)。

It compiles the latest yearly release of JavaScript (whatever is in Stage 4) which replaces all the old presets. But it also has the ability to compile according to target environments you specify: it can handle development mode, like the latest version of a browser, or multiple builds, like a version for IE. It even has another version for evergreen browsers.

它编译了JavaScript的最新年度版本(第4阶段中的所有版本)，该版本替换了所有旧的预设。 但它也具有根据您指定的目标环境进行编译的能力：它可以处理开发模式(例如浏览器的最新版本)或多种构建(例如IE版本)。 它甚至为常绿浏览器提供了另一个版本。

不删除舞台预设(babel-preset-stage-x) (Not removing the Stage presets (babel-preset-stage-x))

Frustration level if we remove the Stage presets in Babel? (in favor explicitly requiring proposal plugins since they aren't JavaScript yet)

— Henry Zhu (@left_pad)

如果我们删除Babel中的舞台预设，会感到沮丧吗？ (建议明确要求投标插件，因为它们还不是JavaScript)

-朱Henry(@left_pad)

June 9, 2017

2017年6月9日

We can always keep it up to date, and maybe we just need to determine a better system than what the current presets are.

我们可以始终保持最新状态，也许我们只需要确定一个比当前预设更好的系统即可。

Right now, stage presets are just a list of plugins that we manually update after each TC39 meeting. To make this manageable, we need to allow major version bumps for these “unstable” packages. This is partly because the community will re-create these packages anyway. So we might as well do it from an official package, and then have the ability to provide better messaging and so on.

现在，舞台预设只是我们在每次TC39会议之后手动更新的插件列表。 为了使其易于管理，我们需要为这些“不稳定”的软件包提供主要版本。 这部分是因为社区无论如何都会重新创建这些软件包。 因此，我们不妨从官方程序包中完成此操作，然后再提供更好的消息传递等功能。

重命名：作用域包( @babel/x ) (Renames: Scoped Packages (@babel/x))

Here is a poll I put out almost a year ago:

这是我差不多一年前发布的一项民意调查：

Thoughts on @babeljs using npm scoped packages for 7.0?

— Henry Zhu (@left_pad)

关于@babeljs使用7.0的npm范围软件包的想法？

-朱Henry(@left_pad)

January 18, 2017

一月18，2017

Back then, not a lot of projects used scoped packages, so most people didn’t even know they existed. You might have had to pay for an npm org account back then, whereas now it is free (and supports non-scoped packages, too).

那时，并没有很多项目使用范围包，因此大多数人甚至都不知道它们的存在。 那时您可能需要支付npm org帐户的费用，而现在它是免费的(并且也支持非作用域的程序包)。

The issues with searching for scoped packages are solved, and download counts work. The only stumbling block left is that some 3rd party registries still don’t support scoped packages. But I think we are at a point where it seems pretty unreasonable to wait on that.

搜索作用域包的问题已解决，下载计数正常。 剩下的唯一绊脚石是某些第三方注册表仍不支持作用域软件包。 但是我认为我们正处于等待这一点似乎是不合理的。

Here’s why we prefer scoped packages:

这就是为什么我们更喜欢作用域软件包：

• Naming is difficult: we won’t have to check if someone else decided to use our naming convention for their own plugin命名很困难：我们不必检查其他人是否决定对自己的插件使用我们的命名约定
• We have similar issues with package squatting我们在包裹蹲坐方面也有类似的问题

• Sometimes people create babel-preset-20xx or some other package because it’s funny. We have to make an issue and email to ask for it back.

  有时人们会创建babel-preset-20xx或其他软件包，因为这很有趣。 我们必须提出问题并发送电子邮件要求它。

• People have a legit package, but it happens to be the same name as what we wanted to call it.人们有一个合法的包裹，但是它恰好与我们想要的名字相同。
• People see that a new proposal is merging (like optional chaining or pipeline operator) and decide to fork and publish a version of it under the same name. Then, when we publish, it tell us the package was already published ?. So I have to find their email and email both them and npm support to get the package back and republish.人们看到一个新的提案正在合并(例如可选的链接或管道运算符)，并决定以相同的名称分叉并发布其版本。 然后，当我们发布时，它告诉我们该软件包已经发布？。 因此，我必须找到他们的电子邮件，并向他们发送电子邮件和npm支持，以取回软件包并重新发布。

• What is an “official” package and what is a user/community package with the same name? We get issue reports of people using misnamed or unofficial packages because they assumed it was part of Babel. One example of this was a report that babel-env was rewriting their .babelrc file. It took them a while to realize it wasn't babel-preset-env.

  什么是“官方”程序包，什么是具有相同名称的用户/社区程序包？ 我们收到有关使用错误名称或非官方软件包的人员的问题报告，因为他们认为该软件包属于Babel。 例如，有报告称babel-env正在重写其.babelrc文件。 他们花了一段时间才意识到这不是babel-preset-env 。

So, it seems pretty clear that we should use scoped packages, and, if anything, we should have done it much earlier ?!

因此，很明显我们应该使用作用域包，并且，如果有的话，我们应该更早完成它！

Examples of the scoped name change:

作用域名称更改的示例：

• babel-cli -> @babel/cli

  babel-cli > @babel/cli

• babel-core -> @babel/core

  babel-core @babel/core > @babel/core

• babel-preset-env -> @babel/preset-env

  babel-preset-env > @babel/preset-env

重命名： -proposal- (Renames: -proposal-)

Any proposals will be named with -proposal- now to signify that they aren't officially in JavaScript yet.

现在，所有提案都将以-proposal-命名，以表示它们尚未正式使用JavaScript。

So @babel/plugin-transform-class-properties becomes @babel/plugin-proposal-class-properties, and we would name it back once it gets into Stage 4.

因此， @babel/plugin-transform-class-properties变为@babel/plugin-proposal-class-properties ，一旦进入阶段4，我们便将其重新命名。

重命名：从插件名称中删除年份 (Renames: Drop the year from the plugin name)

Previous plugins had the year in the name, but it doesn’t seem to be necessary now.

以前的插件的名称中包含年份，但现在似乎没有必要。

So @babel/plugin-transform-es2015-classes becomes @babel/plugin-transform-classes.

因此， @babel/plugin-transform-es2015-classes变为@babel/plugin-transform-classes 。

Since years were only used for es3/es2015, we didn’t change anything from es2016 or es2017. However, we are deprecating those presets in favor of preset-env, and, for the template literal revision, we just added it to the template literal transform for simplicity.

由于年份仅用于es3 / es2015，因此从es2016或es2017起我们没有进行任何更改。 但是，我们不赞成使用这些预置，而推荐使用preset-env，并且对于模板文字修订版，为了简化起见，我们仅将其添加到模板文字转换中。

对等依赖性和集成 (Peer dependencies and integrations)

We are introducing a peer dependencies on @babel/core for all the plugins (@babel/plugin-class-properties), presets (@babel/preset-env), and top level packages (@babel/cli, babel-loader).

我们为所有插件( @babel/plugin-class-properties )，预设( @babel/preset-env )和顶级包( @babel/cli ， babel-loader )在@babel/core上引入对等依赖性。

peerDependencies are dependencies expected to be used by your code, as opposed to dependencies only used as an implementation detail. — Stijn de Witt via StackOverflow.

peerDependencies是代码期望使用的依赖项，与仅用作实现细节的依赖项相反。 — Stijn de Witt通过StackOverflow 。

babel-loader already had a peerDependency on babel-core, so this just changes it to @babel/core. This change prevents people from trying to install these packages on the wrong version of Babel.

babel-loader在babel-core上已经具有peerDependency ，因此将其更改为@babel/core 。 此更改可防止人们尝试在错误版本的Babel上安装这些软件包。

For tools that already have a peerDependency on babel-core and aren't ready for a major bump (since changing the peer dependency is a breaking change), we have published a new version of babel-core to bridge the changes over with the new version babel-core@7.0.0-bridge.0. For more information, check out this issue.

对于已经在babel-core上具有peerDependency并且还没有准备好迎接重大peerDependency工具(因为更改peer依赖项是一项重大更改)，我们发布了新版本的babel-core来将更改与新版本联系起来版本babel-core@7.0.0-bridge.0 。 有关更多信息，请查看此问题 。

Similarly, packages like gulp-babel, rollup-plugin-babel, and so on all used to have babel-core as a dependency. Now these will just have a peerDependency on @babel/core. Because of this, these packages don’t have to bump major versions when the @babel/core API hasn't changed.

类似地，诸如gulp-babel ， rollup-plugin-babel类的软件包以前都具有babel-core作为依赖项。 现在这些将在@babel/core上具有一个peerDependency 。 因此，在@babel/core API @babel/core的情况下，这些软件包不必更改主要版本。

＃5224 ：独立发布实验软件包 (#5224: independent publishing of experimental packages)

I mention this in The State of Babel in the Versioning section. Here’s the Github Issue.

我在Versioning部分的Babel状态中提到了这一点。 这是Github问题 。

You might remember that after Babel 6, Babel became a set of npm packages with its own ecosystem of custom presets and plugins.

您可能还记得，Babel 6之后，Babel变成了一组具有自己的自定义预设和插件生态系统的npm软件包。

Since then, however, we have always used a “fixed/synchronized” versioning system (so that no package is on v7.0 or above). When we do a new release, such as v6.23.0 , only packages that have updated code in the source are published with the new version. The rest of the packages are left as is. This mostly works in practice because we use ^ in our packages.

但是从那时起，我们一直使用“固定/同步”版本控制系统(因此v7.0或更高版本中没有软件包)。 当我们进行新发行时，例如v6.23.0 ，只有在源代码中具有更新代码的软件包才会与新版本一起发布。 其余的包则保持原样。 这在实践中通常可行，因为我们在包中使用了^ 。

Unfortunately, this kind of system requires a major version to be released for all packages once a single package needs it. This either means that we make a lot small breaking changes (unnecessary), or we batch lots of breaking changes into a single release. Instead, we want to differentiate between the experimental packages (Stage 0, and so on) and everything else (es2015).

不幸的是，这种系统要求在单个软件包需要它的所有软件包时都发布一个主要版本。 这意味着我们做了许多小的重大更改(不必要)，或者我们将许多重大更改批处理到一个发行版中。 相反，我们想区分实验包(阶段0，依此类推)和其他所有包(es2015)。

Because of this, we intend to make major version bumps to any experimental proposal plugins when the spec changes, rather than waiting to update all of Babel. So anything that is < Stage 4 would be open to breaking changes in the form of major version bumps. The same applies to the Stage presets themselves (if we don’t drop them entirely).

因此，我们打算在规格更改时使任何实验性建议插件的主要版本都得到改进，而不是等待更新所有Babel。 因此，任何低于第4阶段的内容都可以接受主要版本颠簸形式的重大更改。 舞台预设本身也是如此(如果我们不完全删除它们)。

This goes along with our decision to require TC39 proposal plugins to use the -proposal- name. If the spec changes, we will do a major version bump to the plugin and the preset it belongs to (as opposed to just making a patch version which may break for people). Then, we will need to deprecate the old versions and setup an infrastructure which will automatically update people so that they’re up to date on what the spec will become (and so they don't get stuck on something. We haven’t been so lucky with decorators.).

这与我们决定要求TC39提案插件使用-proposal-名称的决定一致。 如果规格发生变化，我们将对插件及其所属的预设进行主要版本修改(与仅制作可能会破坏人们的补丁版本相反)。 然后，我们将需要弃用旧版本，并设置一个可以自动更新人员的基础架构，以便他们可以及时了解规范的最新信息(这样他们就不会陷入困境。我们尚未非常幸运。)

.babelrc的env选项不会被弃用！ (The env option in .babelrc is not being deprecated!)

Unlike in the last post, we just fixed the merging behavior to be more consistent.

与上一篇文章不同，我们只是将合并行为固定为更加一致 。

The configuration in env is given higher priority than root config items. And instead of the weird approach of just using both, plugins and presets now merge based on their identity, so you can do this:

env的配置具有比root配置项更高的优先级。 现在，插件和预设不再基于仅使用两者的怪异方法，而是根据它们的身份进行合并，因此您可以执行以下操作：

{presets: [['env', { modules: false}],],env: {test: {presets: ['env'],}},
}

with BABEL_ENV=test . It would replace the root env config with the one from test, which has no options.

使用BABEL_ENV=test 。 它将用来自test的根env config替换根env config，它没有选项。

支持class A extends Array (最早的警告) (Support class A extends Array (oldest caveat))

Babel will automatically wrap any native built-ins like Array, Error, and HTMLElement so that doing this just works when compiling classes.

Babel将自动包装任何本机内置组件，例如Array ， Error和HTMLElement以便在编译类时执行此操作。

速度 (Speed)

• Many fixes from bmeurer on the v8 team!

  v8团队的bmeurer 修复了许多问题！

• 60% faster via the web-tooling-benchmark https://twitter.com/left_pad/status/927554660508028929

  通过网络工具基准 https://twitter.com/left_pad/status/927554660508028929将速度提高60％

预设环境： "useBuiltins": "usage" (preset-env: "useBuiltins": "usage")

babel-preset-env introduced the idea of compiling syntax to different targets. It also introduced, via the useBuiltIns option, the ability to only add polyfills that the targets don't support.

babel-preset-env引入了将语法编译到不同目标的想法。 它还通过useBuiltIns选项引入了仅添加目标不支持的useBuiltIns的功能。

So with this option, something like:

因此，使用此选项，类似于：

import "babel-polyfill";

can turn into

可以变成

import "core-js/modules/es7.string.pad-start";
import "core-js/modules/es7.string.pad-end";
// ...

if the target environment happens to support polyfills other than padStart or padEnd.

如果目标环境恰好支持padStart或padEnd以外的padEnd 。

But in order to make that even better, we should only import polyfills that are “used” in the codebase itself. Why import padStart if it is not even used in the code?

但是为了使它更好，我们只应导入在代码库本身中“使用”的polyfill。 如果代码中甚至没有使用padStart为什么padStart导入呢？

"useBuiltins": "usage" is our first attempt to tackle that idea. It performs an import at the top of each file, but only adds the import if it finds it used in the code. This approach means that we can import the minimum amount of polyfills necessary for the app (and only if the target environment doesn't support it).

"useBuiltins": "usage"是我们解决该想法的首次尝试。 它在每个文件的顶部执行导入，但是仅在发现在代码中使用过时才添加导入。 这种方法意味着我们可以导入应用程序所需的最少数量的polyfill(并且仅在目标环境不支持它的情况下)。

So if you use Promise in your code, it will import it at the top of the file (if your target doesn't support it). Bundlers will dedupe the file if it is the same, so this approach won't cause multiple polyfills to be imported.

因此，如果您在代码中使用Promise ，它将在文件顶部导入(如果目标不支持)。 如果文件相同，捆绑程序将对文件进行重复数据删除，因此这种方法不会导致导入多个polyfill。

import "core-js/modules/es6.promise";
var a = new Promise();import "core-js/modules/es7.array.includes";
[].includes
a.includes

With type inference we can know if an instance method like .includes is for an array or not. Having a false positive is ok until that logic is better, since it is still better than importing the whole polyfill like before.

通过类型推断，我们可以知道像.includes这样的实例方法是否适用于数组。 在此逻辑更好之前，可以使用误报，因为它仍然比以前导入整个polyfill更好。

其他更新 (Misc updates)

• babel-template is faster and easier to use

  babel-template更快，更容易使用

• regenerator was released under the MIT License — it’s the dependency used to compile generators/async

  regenerator是根据MIT许可证发布的 -它是用于编译generator / async的依赖项

• “lazy” option to the modules-commonjs plugin via #6952

  通过＃6952为modules-commonjs插件提供“懒惰”选项

• You can now use envName: "something" in .babelrc or pass via cli babel --envName=something instead of having to use process.env.BABEL_ENV or process.env.NODE_ENV

  现在，您可以在.babelrc中使用envName: "something"或通过cli babel --envName=something传递，而不必使用process.env.BABEL_ENV或process.env.NODE_ENV

• ["transform-for-of", { "assumeArray": true }] to make all for-of loops output as regular arrays

  ["transform-for-of", { "assumeArray": true }]使所有for-of循环输出为常规数组

• Exclude transform-typeof-symbol in loose mode for preset-env #6831

  对于预设环境，请在宽松模式下排除transform-typeof-symbol 。 ＃6831

• Landed PR for better error messages with syntax errors

  登陆PR以获得更好的带有语法错误的错误消息

发布前的待办事项 (To-dos Before Release)

• Handle .babelrc lookup (want this done before first RC release)

  处理 .babelrc 查找 (希望在第一个RC版本发布之前完成此操作)

• “overrides” support: different config based on glob pattern

  “覆盖”支持 ：基于全局模式的不同配置

• Caching and invalidation logic in babel-core.babel-core中的缓存和失效逻辑。
• Better story around external helpers.关于外部帮助者的更好的故事。
• Either implement or have a plan in place for versioning and handling polyfills independently from helpers, so we aren’t explicitly tied to core-js 2 or 3. People may have things that depend on one or the other, and won’t want to load both a lot of the time.实施或制定计划以独立于帮助程序来版本化和处理polyfill，因此我们没有明确地绑定到core-js 2或3。人们可能会有彼此依赖的事物，并且不想很多时候都加载。

• Either a working decorator implementation, or functional legacy implementation, with clear path to land current spec behavior during 7.x’s lifetime.

  可以使用的装饰器实现或功能性的传统实现，都有明确的途径可以在7.x的生存期内降低当前规范的行为。

谢谢 (Thanks)

Shoutout to our team of volunteers:

向我们的志愿者团队大声疾呼：

Logan has been really pushing hard to fix a lot of our core issues regarding configs and more. He’s the one doing all of that hard work.

Logan一直在努力解决与配置等相关的许多核心问题。 他是所有辛勤工作的人。

Brian has been taking over maintenance of a lot of preset-env work and whatever else I was doing before ?

Brian已经接管了许多预设环境的维护工作，而我之前在做什么呢？

Daniel has always stepped in when we need the help, whether it be maintaining babel-loader or helping move the babylon/babel-preset-env repo’s over. And same with Nicolo, Sven, Artem, and Diogo who have stepped up in the last year to help out.

Daniel总是在需要帮助时介入，无论是维护babel-loader还是帮助移动Babylon / Babel Preset-env存储库。 与Nicolo ， Sven ， Artem和Diogo一样 ，他们在去年加紧帮助。

I’m really looking forward to a release (I’m tired too — it’s almost been a year ?). But I also don’t want to rush anything just because. There’s been a lot of ups and downs throughout this release, but I’ve certainly learned a lot and I’m sure the rest of the team has as well.

我真的很期待发布(我也很累-已经快一年了？)。 但是我也不想因为某事而仓促。 在整个发行版中有很多跌宕起伏，但是我当然学到了很多东西，并且我相信团队中的其他成员也是如此。

And if I’ve learned anything at all this year, I should really heed this advice rather than just write about it.

而且，如果我今年什么都没学到，我真的应该听从这个建议，而不是仅仅写些建议。

"Before you go maintaining anything else, maintain your own body first" - Mom ?

— Henry Zhu (@left_pad)

“妈妈，在进行其他任何事情之前，请先保持自己的身体”-妈妈？

-朱Henry(@left_pad)

December 22, 2017

2017年12月22日

Also thanks to Mariko for the light push to actually finish this post (2 months in the making)

同时还要感谢丸子(Mariko)的轻率 推动，以实际完成此职位( 撰写过程需要2个月)

翻译自: https://www.freecodecamp.org/news/were-nearing-the-7-0-babel-release-here-s-all-the-cool-stuff-we-ve-been-doing-8c1ade684039/

babel 7.0.0-0