Skip to main content

Babel的状态

· 44 min read
Henry Zhu

以前的问题：Babel 路线图 #4130, 6.0 #2168

如果其他都不行的话，请看看社区部分。

🌐 Please check out the Community section if nothing else.

也作为 小坂真理子 2016 年的 网络降临日历 发布过！

一些历史​

🌐 Some History

Sebastian 在2014年9月创建了“6to5”。有趣的是，他做这个项目只是为了满足自己对理解编程语言及其工作原理的好奇心。你可能会以为项目的创建者已经完全懂得编译器的运作，并且精通 JavaScript……但你错了！看看他的文章，读一读他精彩的经历：~2015 年回顾。

6to5正是做了这件事：轻松地把ES6代码转换成ES5代码。当6to5如Not Born to Die中提到的那样变成Babel时，它成了一个平台：一整套用于创建下一代JavaScript工具的工具。不再只是将ES6编译成ES5，它还让开发者可以在它的基础上构建自己的工具。

以下是我们的一些里程碑：

🌐 Here are some of our milestones:

  • 在 5.0.0 中，Babel 通过引入 stages 与 TC39 流程 更加对齐，增加了 .babelrc 配置选项，并创建了用于自定义转换的插件系统。
  • 在 6.0.0 版本中，Babel 变得模块化（当时这是一个相当有争议的想法）。这是一个巨大的变化，引入了选择性功能（没有默认设置）以及 Presets 和插件选项的概念。
    • 正如他在文章中提到的，Sebastian 在 2015 年 7 月加入了 Facebook，并在公司的时间里参与了 Babel 6 的整个开发。
  • 6.3.13 Sebastian 把我们的 monorepo 构建/发布工具抽取成了现在的 Lerna。有趣的是，James 重写了三次，我得审核所有的内容。
    • 大约在这时候，塞巴斯蒂安和詹姆斯都对 Babel 感到厌倦了，然后有几个贡献者站了出来。
    • 我们在找方向和处理不断涌入的漏洞/请求时很挣扎，但我们还是完成了很多工作！
  • 6.13.0 最终添加了 预设选项。
  • 6.14.0 添加了一个 latest-preset，可以跟上每年的 JavaScript 规范更新。
  • 6.16.0 允许更改解析器或代码生成器。
  • 在八月份，我们发布了Babili，一个基于Babel的压缩工具。
  • 在九月，我们发布了 babel-preset-env 的第一个版本（详情请继续阅读）。
  • 在 Phabricator 上待了一年后，我们完全是因为 @danez 和他令人惊叹（但未被充分认可）的工作，才回到了 GitHub issues。

如果你在使用 Babel，请通过向我们的用户页面提交一个PR告诉我们！

现在 babel-core 每月下载量超过 500 万次，总下载量接近 6000 万次，并且被像 Facebook、Netflix、Airbnb 这样的大公司以及 React、Yarn 这样的其他开源项目使用。

🌐 Now babel-core is downloaded over 5 million times per month and almost 60 million times total and used at huge companies like Facebook/Netflix/Airbnb and other OSS projects like React/Yarn.

感谢大家一直以来的支持！我们希望继续作为 JavaScript 工具链的基础：编译、代码检查、压缩、代码修改工具、代码覆盖率等等。

🌐 Thanks everyone for your continued support! We want to continue acting as the foundation of the JavaScript toolchain: compilation, linting, minification, codemods, code coverage, etc.

当前状态​

🌐 Current Status

如果你有兴趣帮忙，请查看下面链接的问题吧！

🌐 If you're interested in helping out please check out the issues linked below!

从第 0 阶段开始维护 TC39 每个提案 的 Babel 插件​

🌐 Maintaining Babel plugins for each proposal in TC39 starting from Stage 0

TC39 代表 Ecma 国际标准协会第 39 技术委员会：它就是制定 JavaScript 的那个委员会。

Babel 使用 TC39 的阶段概念 来对其实验插件进行分类。用户应该能够轻松使用一些功能，即使它们还没有在浏览器中完全实现 TC39 流程的第 4 阶段 。

🌐 Babel uses TC39's concept of stages to categorize its experimental plugins. Users should be able to easily use features before they are all implemented in browsers in stage 4 of the TC39 process.

考虑到它在生态系统中的位置，Babel 在整个过程里是非常关键的：对开发者来说，更新一个 .babelrc 文件要比修改浏览器标志容易得多，写一个 Babel 插件也比在浏览器中原生实现这个功能快得多。这就是 Babel 的核心。

🌐 Babel is fundamental in the process given its place in the ecosystem: it is significantly easier for a developer to update a .babelrc file than a browser flag and much faster to write a Babel plugin than to implement the feature natively in the browser. This is the core of Babel.

但提案过程涉及大量迭代：提案可能在语法上发生变化，甚至可能被放弃。由于 TC39 每两个月开会一次，插件应该至少在每次阶段变化时更新一次，这样用户才能保持同步。

🌐 But the proposals process involves significant iteration: proposals can change in syntax or even get dropped. Because TC39 meets every 2 months, plugins should be updated as least as often as each change in stage so that users can be in sync.

对提案负责人和委员会的早期反馈非常有价值，虽然建议谨慎使用阶段0/1/2的特性。 虽然像 Facebook 这样的公司会利用这些特性，但他们已经创建了 codemods 来方便修改。

没有足够的时间或资源去维护每个插件，尤其是在有规范更新的时候。

🌐 There isn't enough time or resources to maintain each plugin, especially when there are spec updates.

  • 有些转换已经过时了，比如装饰器。Logan 不得不为 Babel 6 移植之前的规范 babel-plugin-transform-decorators-legacy，而我们还没有人能根据更新的规范重写它。
  • babel/babel#3473 - 异步迭代提案 之所以拖了这么久才合并，是因为我们一直没时间去审核它。等它合并的时候，它已经从第二阶段进到了第三阶段。

接下来我们要处理的是：

🌐 Next we're going to be working with:

相关问题：

🌐 Relevant Issues:

想了解 TC39 的更多信息，看看 thefeedbackloop.xyz 吧！

维护其他生态系统插件：JSX/Flow​

🌐 Maintaining other ecosystem plugins: JSX/Flow

Babel 对 React 和 Flow 生态系统来说非常重要，我们也与 Facebook 的相关团队紧密合作。

🌐 Babel is vital to the React and Flow ecosystems, and we work closely with the relevant teams at Facebook.

相关问题标签：

🌐 Relevant Issue Labels:

babel-preset-env（Babel 的“自动加前缀器”）​

🌐 babel-preset-env ("autoprefixer" for Babel)

JavaScript 的编译是一个不断变化的目标：规范每年都会更新，浏览器厂商也在不断跟进更新，而且用户可能会停止支持早期的浏览器。乍一看，好像没有一个固定的目标让我们把 JavaScript 编译成什么样子。

🌐 JavaScript compilation is a moving target: There are yearly updates to the spec, browser vendors are constantly updating to that spec, and users may drop support for earlier browsers. At first glance, there doesn't seem to be a fixed target for what we should compile our JavaScript down to.

compat-table 会不断更新，并且用于这个预设。

这就是 babel-preset-env 派上用场的地方：它是一个 Babel 预设，会根据提供的环境自动确定要使用的 Babel 插件。

🌐 This is where babel-preset-env comes in: it's a Babel preset that automatically determines the correct Babel plugins to use based on the provided environments.

它的目标是使用简单且输出高效：你只需要关注你的目标环境，就能充分利用本地代码。预设会为你决定所需的插件。

🌐 Its goal is both simplicity in use and efficiency in output: you only need to worry about your target environments to be able to take advantage of native code. The preset decides for you the required plugins.

一些示例配置​

🌐 Some example configs

通过 browserslist 针对 Chrome 55 及其他浏览器的最近两个版本

🌐 Targeting Chrome 55 + last 2 versions of other browsers via browserslist

JavaScript
{
  "presets": [
    ["env", {
      "targets": {
        "chrome": 55,
        "browsers": ["last 2 versions"]
      }
    }]
  ]
}

针对当前的 Node.js 版本（使用 process.versions.node）

🌐 Targeting the current Node.js version (uses process.versions.node)

JavaScript
{
  "presets": [
    ["env", {
      "targets": {
        "node": "current"
      }
    }]
  ]
}

Chrome 55 useBuiltIns + webpack 2

JavaScript
{
  "presets": [
    ["env", {
      "targets": {
        "chrome": 55
      },
      "modules": false,
      "useBuiltIns": true
    }]
  ]
}

在

JavaScript
import "babel-polyfill";

输出（根据环境不同而不同）

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

相关问题：

🌐 Relevant Issues:

通过 babel-eslint 进行代码检查​

🌐 Linting via babel-eslint

example of eslint

ESLint 直到语言新特性达到提案流程的第 4 阶段才会支持它们。出于这个原因，我们维护了 babel-eslint（一个自定义 ESLint 解析器），这样你就可以继续检查带有实验性语法的 JavaScript。

🌐 ESLint doesn't support new language features until they reach Stage 4 of the proposals process. For this reason we maintain babel-eslint (a custom ESLint parser) so you can continue to lint JavaScript with experimental syntax.

这个项目是最难做的项目之一：因为它只是 Babel 和 ESLint 之间的一个兼容层，所以当任一项目更新时，本身就需要不断更新，而且由于 monkey-patching 的存在，出现意外更改的风险也很高。像 babel/babel-eslint#243 或 babel/babel-eslint#267 这样的问题真的挺令人沮丧的。

🌐 This project was one of the hardest projects to work on: because it is just a compatibility layer between Babel and ESLint there is inherently a constant need for updates when either projects update and a high risk of unexpected changes due to monkey-patching. It was unfortunate to get issues like babel/babel-eslint#243 or babel/babel-eslint#267.

为此，我们希望通过改进 ESLint 的作用域和遍历互操作性来减轻这个项目的维护负担。甚至可能会很有趣，如果能够使用 babel API 来编写 ESLint 规则，反过来也行？

🌐 To that end, we'd like to lessen the maintenance burden of this project by improving our scope and traversal interop with ESLint. It might even be interesting to be able to write ESLint rules using babel APIs or vice versa?

相关问题：

🌐 Relevant Issues:

压缩​

🌐 Minification

Babili 是我们新的 Babel 驱动压缩工具，让你在针对最新浏览器的同时生成压缩代码。

在

JavaScript
class Mangler {
  constructor(program) {
    this.program = program;
  }
}
new Mangler();

出

JavaScript
// ES2015 code -> Babili -> Minified ES2015 Code
class a{constructor(b){this.program=b}}new a;

查看我们的博客文章了解更多信息。

🌐 Check out our blog post for more info.

由于它是最近才发布的，我们正在寻找一些新的贡献者！对于那些想找一个新项目帮忙的人来说，还有很多小漏洞和可以改进的地方！

🌐 Since it was recently released, we're looking for some new contributors! There's a lot of small bugs and things that could be improved for those looking for a new project to help out with!

代码修改 / 重构 / eslint --fix​

🌐 Codemods / Refactoring / eslint --fix

codemod 是一种辅助工具代码修改；就像一个高级的查找和替换。

🌐 A codemod is a tool-assisted code modification; a fancy find-and-replace.

如果你想把 merge({}) 改成 Object.assign({})（以后可能还想改 object rest），你可能会用正则替换。但你不想去改代码里其他同样叫 merge 的地方，比如导入/导出、字符串、注释或者局部变量。为了安全起见，你需要用更强大的方法，只改你想改的那部分代码。

🌐 If you wanted to change merge({}) to Object.assign({}) (and maybe later object rest) you might do a regex replace. But you don't want to replace the other parts of the code that also might be called merge such as imports/exports, strings, comments, and local variables. To do it safely you'll want something more powerful that only changes the specific code you need.

虽然 Babel 已经可以把代码转换成其他代码，但作为编译器它并不怎么关心输入代码的样式。在用 Babel 的默认选项做代码修改后，git diff 看起来真的很乱。

🌐 Although Babel already handles transforming code into other code, it doesn't really care about the styling of the input code as a compiler. After using Babel with its default options to do a codemod, git diff looks really messy.

来看看 Recast：一个在保持未修改代码格式的同时，也能美化打印任何新的 AST 节点的工具。

🌐 Enter Recast: a tool that preserves the formatting of unmodified code while also pretty-printing any new AST nodes.

recast

在上面的截图中，左上角的窗格是输入代码，右下角的窗格是在运行 Babel 插件后的输出代码。在这种情况下，它会尽可能保留输入代码的空白。

通过在选项中传入 Recast，Babel 可以驱动 codemods 的未来。

🌐 By passing in Recast in the options, Babel can power the future of codemods.

.babelrc

JavaScript
{
  "parserOpts": {
    "parser": "recast"
  },
  "generatorOpts": {
    "generator": "recast"
  }
}

在源代码上运行相关的 Babel 转换并覆盖它：

🌐 Run the relevant Babel transform(s) on the source code and overwrite it:

Shell
babel src -d src

这个功能刚刚实现，所以我们期待让它更易于使用，并看看它能够带来的变化。更多信息请查看 6.16.0 博客文章！

🌐 This feature was just made possible so we're looking forward to making it easier to use and seeing the transformations it can enable. Check out the 6.16.0 blog post for more info!

其他相关项目：JSCodeshift、js-codemod、Lebab。

🌐 Other relevant projects: JSCodeshift, js-codemod, Lebab.

相关问题：

🌐 Relevant Issues:

代码覆盖率 / 插装​

🌐 Code Coverage / Instrumentation

我们想要支持像 nyc 和 babel-plugin-istanbul 这样的工具。

🌐 We want to support tools like nyc and babel-plugin-istanbul.

插件生态​

🌐 Plugin Ecosystem

多亏了我们充满活力的社区，新的插件不断被创造出来：无论是写你的 css in jsx 的新方法，还是 重写你的测试。

🌐 Thanks to our vibrant community, new plugins are constantly being created: whether it be a new way to write your css in jsx or rewire your tests.

目前在 npm 上有超过 1200 个 babel 插件。

我们进行了些有趣的讨论，关于我们如何发展和支持插件生态系统。我们可以尝试关注所有的仓库，但这显然太难应付了。

🌐 We've had some interesting discussions on how we can grow and support the plugin ecosystem. We could try to watch all the repos but that is obviously overwhelming.

创建一些机器人来自动化一些任务可能会很有趣：为 babel-plugins 创建特定的 Babel 插件/ESLint 规则，编写代码修改工具以更新 API 改动，并将插件集成到我们的冒烟测试中。

🌐 It might be interesting to create some bots to automate a few tasks: create specific Babel plugins/ESLint rules for babel-plugins, write codemods to update API changes, and integrate plugins into our smoke test.

  • 我们应该为新的/有用的插件创建一个新闻通讯吗？
  • 我们怎么教人们了解插件以及如何编写插件？
  • 我们怎么能让 ASTExplorer 变得更好呢？

文档（就是这个网站！）​

🌐 Documentation (this website!)

去年的文档贡献确实有些不足。

🌐 Docs contributions have definitely been lacking in the last year.

不过，最近我们做了很多很棒的事情：

🌐 However just recently we've done a lot of awesome stuff:

  • @Daniel15 一直在维护我们在 REPL 中使用的 babel-standalone，而且当有新版本发布时，他还做了一些自动化处理。
  • @maxiloc 通过 #977 使用 Algolia 添加了搜索功能

我们还新增了合作伙伴：

🌐 We've also added new collaborators:

  • @STRML：通过 #875 在所有 GitHub 页面上添加了 Discourse
  • @xtuc：添加了从 Babel 仓库读取 README 的支持，这样我们就不用通过 #990 同步两份文档了
  • @fredericmarx：通过 #998 为代码片段添加了复制到剪贴板按钮的支持
  • @seedofjoy：通过 #1003 为 REPL 添加了调整大小的功能

一些想法

🌐 Some Ideas

  • 所有插件都应该有示例。也可以嵌入 RunKit 或 REPL。
  • 用常见错误更新常见问题
  • API 文档 / 让 babel-handbook 更好

相关问题：

🌐 Relevant Issues:

未来​

🌐 The Future

注意：下面的内容都可以更改或删掉。有些可能已经在进行中，其他只是一些需要好好讨论或有人支持的建议。

优先顺序应该根据社区的需求来决定，而不是因为“拥有会很好”。

插件 API 变更​

🌐 Plugin API Changes

关于插件/预设如何按顺序交互有很多混淆。这导致配置中出现错误和问题，用户不得不以非直观的方式将插件放在其他插件的前面或后面。

🌐 There is a lot of confusion around how plugins/presets interact regarding ordering. This results in bugs and issues with the config which require users to place plugins before/after others in a non-intuitive way.

我们目前正在讨论可能减少混淆的 API 更改。不过，由于这是对 Babel 核心的根本性更改，可能需要一段时间才能找到最佳方案。

🌐 We’re currently discussing API changes that could reduce the confusion. However, since this is a fundamental change to the core of Babel, it might take a while to figure out the best approach.

版本控制​

🌐 Versioning

自从 Babel 6 以来，我们通过 Lerna 使用了“固定”版本模式。这让我们可以在同一版本下同时发布多个包（如果那个包有改动的话）。这样很好，因为你不需要为每个包手动设置版本，所有东西都会一起更新。唯一可能出错的情况是当某个包做了重大改动时：那时候每个包的主版本也都会跟着升级。

🌐 Since Babel 6 we've used a "fixed" mode of versioning via Lerna. This is what allows us to release multiple packages at the same time all under the same version (if that package changes). This is nice because you don't have to manually set a version for each package but everything moves together. The only time this could cause an error is when one on the packages makes a breaking change: then every package also will bump major versions.

这在 babel/notes 中有更多解释，但我们仍然需要想出项目的最佳行动计划。

🌐 This is explained more in babel/notes but we still need to figure out the best plan of action for the project.

当我们需要把 Stage 0 规范更新到 Stage 1，并且这会导致解析器的不兼容变更时，会发生什么？我们是直接提高主版本号，等着把一些改动一起合并，还是想办法通过多个插件版本来实现？

🌐 What happens when we need to update a Stage 0 spec to Stage 1 and it's a breaking change to the parser? Are we just going to bump the major version, wait to batch some changes up, or figure out how to do it via multiple versions of plugins?

讨论问题

改变对 X 阶段预设的看法​

🌐 Changing the Mindset Around Stage X Presets

相关问题：

🌐 Relevant Issues:

速度​

🌐 Speed

性能是一种特性！有时其他事情可能更优先（修复漏洞、符合规范等），但它在几个不同方面仍然很重要。

🌐 Performance is a feature! Other things can be more of a priority at times (bug fixes, spec compliancy, etc) but it's still important in a few different aspects.

  • 我们如何减少安装的大小/时间，尤其是对于包含多个包的项目？（这可以通过 yarn 帮助）
  • 我们怎么能解析得更快？
  • 我们怎么才能做出更快的插件（并单独测量它们的速度）？
  • 我们怎么能更快地生成转换后的代码？
  • 我们如何生成在浏览器中运行快速的代码 (https://fhinkel.github.io/six-speed/)？

如果你阅读编译后的输出并发现问题，就报告它并寻求帮助来制作一个 PR！

🌐 If you to read the compiled output and see issues, then report it and ask for help in making a PR!

以前的问题：

🌐 Previous Issues:

可能支持 TypeScript 吗？​

🌐 Possible TypeScript Support?

也许 Babel 可以学会理解 TypeScript 语法（就像我们处理 Flow 那样）？我们可以加一个插件来去掉 TypeScript 类型，以便更好地互通。

🌐 Maybe Babel could learn to understand TypeScript syntax (like we do with Flow)? We could add a plugin to strip TypeScript types for better interop.

这意味着需要解析 TypeScript 特定的语法并把它去掉。不过 TypeScript 确实有非类型语法，所以像 enum 这样的东西我们可能还得再讨论一下。

🌐 This would mean parsing TypeScript specific syntax and stripping it out. However TypeScript does have non-type syntax, so for things like enum we will would have to discuss more.

使用类型信息吗？​

🌐 Use Type Information?

与像 Flow/TypeScript 这样的类型系统集成以进行优化。这只是意味着 Babel 应该能够通过这些工具知道一个标识符 arr 实际上是不是 Array。

🌐 Integrate with a type system such as Flow/TypeScript to make optimizations. This just means that Babel should be able to gain the knowledge through those tools that an identifier arr is actually an Array or not.

实际上有几个插件可以进行类型检查：babel-plugin-typecheck 和 babel-plugin-tcomb

获取依赖图 / 操作多文件?​

🌐 Taking in a Dependency Graph / Operate Multi-file?

这样我们就可以更好地和其他工具比如 Webpack 集成。这会允许跨文件转换或者整个代码库的优化。这样做的主要原因是为了压缩器（例如能够根据检查整个应用的使用情况来移除属性），或者比如说提供缺失/无效导入导出的错误提示。

🌐 Then we could integrate with other tools like Webpack better. This would allow cross file transformations or whole codebase optimizations. The main reason for this would be for the minifier (being able to remove properties based on checking the usage across the whole application) or for example providing errors for missing/invalid import/exports.

解析器错误​

🌐 Parser Errors

像《为人类设计的编译器错误》（http://elm-lang.org/blog/compiler-errors-for-humans）那样，让解析器提供更好的错误信息。

🌐 Better error messages from the parser like in Compiler Errors for Humans.

显然我们都想看到有用的错误信息！

我们可以更好地推断/猜测用户意图，以防止模糊的错误。遇到这种情况的时候，告诉我们吧！

🌐 We can do better inference/guessing on user intention to prevent vague errors. Let us know in what cases that happens!

相关问题：

🌐 Relevant Issues:

babel-init​

基本上就是一种像 create-react-app 那样更容易设置 Babel 的方法。

🌐 Basically a way to set up Babel more easily like create-react-app does.

  • 从零开始设置一个 .babelrc，用问题来提示

可能的想法：

🌐 Possible Idea:

  • 询问目标环境（浏览器、Node）并传给 babel-preset-env
  • 询问实验功能（添加特定插件）
  • 更新 babel npm 包以再次执行某些操作：让它成为默认/可选/有主见的 babel，就像 Babel 5 曾经那样。它可以默认使用 env 并输出 latest 2 browsers（无需任何配置）。

相关问题：

🌐 Relevant Issues:

运行 tc39/test262​

🌐 Run tc39/test262

test262 测试与不断更新的 ECMAScript 草案标准（可以在 tc39.github.io/ecma262 查到）的符合性，以及任何 Stage 3 或更高阶段的 TC39 提案。它由 Tom Care (@tcare) 维护，并且 ECMAScript 社区的许多人也做出了重要贡献。

对 Babel 运行官方规范测试可以确保我们遵守规范，或者至少知道什么时候不遵守。我们需要弄清楚如何对那些我们不能编译的内容（proxy、TCO 等）进行过滤，并设置一个简单的方法来检查失败的测试，以及为它们提交问题和 PR。

🌐 Running the official spec tests against Babel can make sure we comply to the spec or at least know when we don't. We'll want to figure out how to do filtering on things we can't compile (proxy, TCO, etc) and set up an easy way to check failing tests and file issues and PRs for them.

相关问题：

🌐 Relevant Issues:

冒烟/集成测试​

🌐 Smoke/Integration Tests

最好能有一个反向的 Greenkeeper，或者在 Babel 的 master 分支上运行测试，这样我们就可以在发布之前发现任何重大回归（node 有 citgm 项目 用来做这个）。理论上，我们希望拿使用 Babel 的最大开源项目来跑它们的测试。

🌐 It would be useful to either have a reverse Greenkeeper or to run tests with master branch of Babel so that we can catch any major regressions before any release (node has the citgm project for this). In theory we would want to take the biggest open source projects that use Babel and run their tests.

motiz88/babel-smoke-tests 是一个不错的起点！如果已经有类似的东西，那就更好了！

程序分析​

🌐 Program Analysis

Alan Shreve 有一次很棒的演讲，叫做 “理想化提交日志：通过程序切片简化代码”，这启发了 @kentcdodds 尝试通过 slice-js 在 JavaScript 中实现它。

🌐 There was a great talk by Alan Shreve called "Idealized Commit Logs: Code Simplification via Program Slicing" which inspired @kentcdodds to try it out in JavaScript via slice-js.

大致的意思是，我们有很多工具来帮助我们写代码，但没有很多工具来帮助我们理解或阅读代码。你可以把代码切片看作是一种针对性的死代码消除。

🌐 The general idea is that we have a lot of tools to help us write code but not a lot for helping us understand/read code. You can think of code-slicing as a form of targeted dead-code elimination.

slice-js

程序切片基本上就是从源代码中去掉那些在你运行的测试用例中不会用到的代码。如果有很多 if 语句和循环在你的使用场景下没有运行，它们就不会出现在程序切片里。

🌐 A program slice basically cuts away from the source code the code that isn't used for a test case that you run. If there are lots of if statements and loops that aren't run during your usecase then it won't show up in the program slice.

  • 语义（AST 感知）搜索工具？

类似于 graspjs，我觉得如果可以对输入为 AST 的内容进行查找替换会很有趣。这样我们就能创建其他分析工具：比如找到代码中所有的 IIFE、方法被调用的次数，甚至统计我们代码库中有多少个类。

🌐 Similar to graspjs, I think it would be interesting to be able to do a find-replace with the input being an AST. It would allow us to create other analysis tools: the ability to find all IIFE's in our code, the number of times a method is called, or even how many Classes we have in our codebase.

babel --settings​

这个命令会打印出所有信息（即使出错也会打印）。它还会包括每个插件运行所需时间的性能指标。

🌐 This command would print out all info (also when erroring). It would also include performance metrics on how long each plugin takes.

解析器统一​

🌐 Parser Unity

关于解析器/AST 统一性的问题，也有一些讨论，见 TheLarkInn/js-parser-discussions 和之前的 ESTree。

🌐 There have also been some discussions around parser/AST unity, in TheLarkInn/js-parser-discussions and previously with ESTree.

不幸的是，从 Babel 6 开始，我们已经“分叉”了，在 我们的 AST 和 ESTree 之间有一些差异。Babel 的目标是支持阶段 x 特性，而其他解析器可能只想支持阶段 4 特性。关于规范遵从性、性能、阶段 x 特性、错误信息、可扩展性、版本发布等，我们可能会有不同的优先级。但对我们来说，开放接受可能带来更好互操作性和更好社区的破坏性变更仍然很重要。

🌐 Unfortunately with Babel 6, we have "forked" and have a few differences in our AST than ESTree. Babel aims to support stage x features while other parsers may only want to support stage 4 features. We all might prioritize certain things more than others regarding spec compliancy, performance, stage x features, error messages, extensibility, releases, etc. However it's important for us to be open to breaking changes that may lead to better interop and a better community.

Sweet.js 互操作?​

🌐 Sweet.js Interop?

之前的问题 issue。也许我们可以想办法让互操作更好一些？

🌐 Previous issue. Maybe we can just figure out how to have better interop instead?

Node.js 支持​

🌐 Node.js Support

我们应该根据 Node.js 版本的 EOL 来停止支持吗？一般来说，我们应该等多久才做这个？

🌐 Should we drop support according to the EOL of Node.js versions? How long should we wait to do this in general?

  • 我们还想继续支持那些还没有更新的用户吗？
  • 有些转换/PR会被这个阻挡，因为一些工具也不再支持旧版本了。
  • 许多其他像 ESLint 这样的构建时项目已经这么做了。
  • 我们是仅为了这个做一个大版本，还是顺便规划其他改动？
  • 讨论问题

Babel 5 到 6 的过渡 / 升级路径​

🌐 Babel 5 to 6 transition / Upgrade Paths

Babel 6 对社区来说真的很难升级。最初的发布有点仓促。虽然我们确实有一个 6.0 发布文章，紧接着还有一个 安装指南，甚至还有一个 工具（现在已弃用） 来帮助过渡，但用户仍然很难理解这些变化。

🌐 Babel 6 was really difficult for the community to upgrade to. The initial release was a bit rushed. Although we did have a 6.0 release post, a setup guide soon after, a even a tool (now deprecated) to help with the transition it was still difficult for users to understand the changes.

仍然有相当多的 Babel 5 用户 我们不想让他们掉队。我们可以做些什么来帮助他们升级？未来我们需要采取哪些步骤，以确保同样的事情不会发生在 Babel 7 上？是否有其他项目/社区我们应该联系并提供帮助？

🌐 There are still a good amount of users on Babel 5 that we don't want to leave behind. What can we do to help them upgrade? What steps do we need to take in the future to make sure the same thing doesn't happen with a Babel 7? Are there other projects/communities we should be reaching out to and helping?

相关问题：

🌐 Relevant Issues:

还有什么？​

🌐 What else?

还有什么之前没提到的吗？请给我们发一条推特@babeljs、在我们的Slack上发消息（加入链接 https://slack.babeljs.io/）、评论这篇帖子，或者在我们的仓库里创建一个讨论问题！

🌐 Anything else not already brought up here? Please send us a tweet @babeljs, a message on our slack (join at https://slack.babeljs.io/, comment on this post, or create an discussion issue in our repo!)

有没有一些项目或社区我们应该更多地合作？我们怎样才能让贡献的体验更友好？我们能做些什么让开发过程更加透明？

🌐 Are there projects or communities we should partner with more? How can we make the contributing experience more welcome? What can we do to make the development process more transparent?

社区​

🌐 Community

旧问题：

🌐 Old Issues:

你可能会认为，随着一个项目被越来越多人使用，会有更多人来帮忙。但像大多数没有公司支持的开源项目一样，维护和可持续性一直是个问题；有人会感到疲惫、转向其他有趣的项目，或者忙于工作/家庭等等。

🌐 You might think that as a project gets more widely used that more people show up to help out. But like most OSS projects that aren't backed by a company, there is a constant issue with maintenance and sustainability; people get burned out, move on to other cool projects, or get busy with work/family/etc.

正如詹姆斯在《亲爱的 JavaScript》(https://medium.com/@thejameskyle/dear-javascript-7e14ffcae36c) 中描述的，目前 Babel 团队相当小。

🌐 Like James describes in Dear JavaScript, the current Babel team is pretty small.

Babel 不是一家公司，也不是 Facebook 的一个特别团队，或者由公司资助的开源项目。它是一个由社区推动的项目，目前主要靠几个人维持，我们希望它能继续发展壮大。

所以如果你有兴趣为你使用的工具做出贡献，我们希望这可能就是那个工具！

🌐 So if you're interested in contributing to a tool you use, we're hoping this could be the one!

我应该关注或参与哪些问题？​

🌐 What issues should I look at or contribute to?

我们很多项目都有 beginner-friendly 和 help-wanted 标签。你也可以看看 discussion。

🌐 Many of our projects have both beginner-friendly and help-wanted labels. You can also check out discussion.

团队​

🌐 Team

我们的核心团队是：

🌐 Our core team is:

而且就在过去的三个月里，合作伙伴更多了：

🌐 And just in the last 3 months a lot more collaborators:

Babili 核心团队：

🌐 Babili core team:

如上所述，我们有很多网站合作伙伴：

🌐 As mentioned above we have a lot of website collaborators:

不活跃但仍然是一个资源：

🌐 Inactive but still a resource:

我怎么联系团队？​

🌐 How can I contact the team?

GitHub​

对于错误报告/拉取请求，你可以查看我们的仓库。

🌐 For bug reports/PRs you can check our repositories.

Twitter​

你可以在推特上 ping 我们 @babeljs ——或者单独提到我们。

🌐 You can ping us on Twitter with @babeljs - or mention us individually.

我自己加入Twitter是为了能够和用户交流并提供帮助。能够发布新功能和更新日志真的很有用，也可以帮助我们获得反馈！

🌐 I myself joined Twitter to be able to talk with users and help out. Being able to post new features and changelogs is really useful and can help give us feedback!

Slack​

我们那边有一个相对活跃的社区！

🌐 We have a relatively active community on there!

你会发现有很多很棒的社区成员愿意提供帮助，比如 Jordan Harband, @ljharb、Jessica Franco, @Jessidhia、Jimmy Jia, @taion、Denis Pushkarev, @zloirock 等等！

🌐 You'll find a lot of awesome community members willing to help such as Jordan Harband, @ljharb, Jessica Franco, @Jessidhia, Jimmy Jia, @taion, Denis Pushkarev, @zloirock and more!

如果你只是有问题，可以加入#discussion；如果你想帮忙或旁听，可以查看#development。

🌐 If you just have questions join #discussion and if you want to help or listen in check out #development.

如果没有必要，我们尽量不私下讨论：我自己通常会把我正在处理的问题或PR贴出来，让大家评论和讨论。

🌐 We try not to discuss in private if there's no need to: I myself usually post the issues/PRs I'm working on for people to review and talk about.

其他​

🌐 Other

我们还能通过什么方式与社区互动呢？我们应该去组织聚会、参加会议，还是举办黑客松？

🌐 How else can we interact with the community? Should we go and start meetups, go to conferences, or manage hackathons?

我们怎样才能让 Babel 可持续发展？我们应该建立一个 Open Collective 还是寻找一个基金会？我们应该雇一个 项目经理 吗？

🌐 How can we make Babel sustainable? Should we setup a Open Collective or seek a foundation? Should we pay for a project manager?

告诉我们你的想法吧！你希望从Babel得到什么？

🌐 Let us know your thoughts! What do you want out of Babel?

发现错字或问题？请提交 PR 或在 babel/babel.github.io#1014 上评论

如果有什么的话，我们想让你知道，我们很多人最初加入 Babel 是为了学习 JavaScript，而不是因为我们已经会了来帮忙。就我个人而言，我对编译器一无所知，在找到这个项目时，我才刚学会 ES6。我是因为一点点好奇心和很多人的鼓励才来到这里的。我希望能把这种精神继续下去，也希望我们都能一起成功。

🌐 If anything we want to let you know that many of us got our start with Babel in order to learn JavaScript rather than helping because we already knew it. Personally, I knew nothing about compilers and had just learned what ES6 was when I found the project. I got here because of a tiny bit of curiosity and some encouragement from a lot of people. I want to carry that forward and hope that we can all succeed together.

非常感谢你的阅读！

🌐 Thanks so much for reading!

Henry Zhu (@hzoo) (@left_pad)

感谢太多的人提供的审阅和想法：@DrewML, @mrjoelkemp, @kentcdodds, @existentialism, @jdalton, @gaearon, @nolanlawson, @jayphelps, @montogeek, @TheLarkInn, @jasonLaster, @benjamn, @addyosmani, @Daniel15, @loganfsmyth, @gr2m, @mathiasbynens, @chicoxyzzy, @bvaughn, @bcoe。