作者 | Michael Dawson
点击查看视频
Node.js 技术委员会主席 Michael Dawson 受邀来到 D2 Node.js （Serverless）专场为大家分享话题：Node.js 与未来。以下是他的分享内容的中文版，英文原版请看视频。
我是一个非常活跃的社区成员，我是 Node.js Collaborator，技术指导委员会成员，也是社区委员会的成员，并活跃在好几个工作组，我还是 OpenJS 基金会的活跃成员。同时也是 OpenJS 基金会跨项目理事会的投票成员，并已被选为 2020-2021 年度的 OpenJS 社区董事。你可以通过 Twitter（@mhdawson1）或 LinkedIn（https://www.linkedin.com/in/michael-dawson-6051282 ）联系我。
下面是这次的议程，首先，我要谈谈我们如何跟踪 Node.js 接下来会发生什么？我会说说我对正在发生的事情的看法。如果你愿意的话，你也可以做一些贡献。然后我们会讨论一下 Node.js 的发布计划，谈谈有趣的新功能。还有一些战略举措，我们团队正在深入研究的内容，或者是 Node.js 工作组正在做的事情。最后，我们会提到关于 OpenJS 基金会的新内容，以及你可以如何参与。
Node.js 有路线图吗？
首先，非常有趣但是重要的事是，Node.js 没有正式的路线图。所以没有一个公司赞助商在决定会发生什么。这是非常去中心化的，事情都是由社区中活跃贡献的志士来驱动的。当然，这其中有很多合作，但是功能都是在完善之后就顺势进入下一次发布，而不是我们有一个预先计划和预先定义的功能集，然后推动这些功能将使其发布。但这并不意味着我们没有规划未来的愿景和正在发生的事情。我会介绍这些正在推动不同的特性、事情发展的团队。所以想要了解有趣的方面上的事情，或者你如何跟上或弄清楚发生了什么，你自己下一步可以做什么，有很多非常好的方法。
第一个是版本发行，我们等下会详细说说这个部分。这个项目组在 Twitter 上非常活跃，Twitter 上有很多人谈论这个项目正在发生什么。如果你 Follow 了我和技术指导委员会的其他人和一些贡献者的讨论，会对重要的事情有形成相当好的感觉。你现在也可以用 GitHub Notification，不过在 Node.js 组织中有 187 个仓库，在 pkgjs 组织中有13个。Node.js 项目是非常专注于透明的，几乎所有的讨论都发生在 GitHub 上。如果我休假两三天，回来之后会有三四百个有关讨论的通知。所以要保持跟踪这些讨论是很繁杂的工作。但你确实可以看到正在发生的一切。一种更专注的方式是，如果你对特定的主题或领域感兴趣，参与这些工作组和团队的定期会议。你可以从 Node.js 的日历中查看这些会议时间。例如，你对诊断，发布，构建，或者 Web 服务器感兴趣，了解当前正在发生的事情的最好的方式就是加入团队，参与进来，加入会议。如果没有机会的话，会议实际上是直播的，你可以看他们的现场直播或之后在 YouTube 看录像。
另一种很好的关注 Node.js 的方式来就是关注长期的战略性行动，我们已经有一些战略问题定义，等会我们将讨论这些。最后，显然不是所有工作都与 JavaScript 有关，这些也会影响 Node.js，因为 Node.js 本身也是 JavaScript 生态的一部分。因此，关注 OpenJS 基金会正在发生的事情也是了解未来整体发展方向的一种很好的方式。
版本发行
所以首先，发布是一个很好的方式来理解接下来是什么。所以让我们稍微了解一下 Node.js 版本发行的工作流。我们有 4 种发行类型：
第一种，金丝雀版本。基本上是 Node.js 加上最新的 V8，但是说真的，我们不希望任何人使用这些版本，只是用来在 V8 中尝试一些非常具体的东西，它可以帮助我们确保我们不会被 V8 的一些更新惊吓到。
第二种，每日版本，这些每日版本会因为各种原因发行。但最有用的是用来尝试 Master 分支上一些新的功能等等。
第三种，Current 版本。我们每六个月做一次大版本发行，其中的偶数 Current 版本将被升级为 LTS 版本，也就是第四种，长期支持版本。
因此，每 12 个月，我们会发布一个新的长期支持版本，他们会得到 30 个月的支持和 12 个月的积极特性支持，这些版本我们不断地推进更新。除此之外，这些版本还有 18 个月的维护支持，其中主要是安全发布和重要的东西。
这是发布在 GitHub Node.js Release 仓库的主要版本的时间表：
你可以看到我们目前实际上有三个 LTS，10，12，和 14，还有一个 Current 版本，也就是15。我们可以看到明年 4 月，Node.js 将会发布下一个 Current 版本。然后 6 个月后，Current 版本将成为下一个 LTS，因为它是一个偶数版本。通过这个计划表，我们可以看到这些版本发行是非常可预测的。
如果你去看 https://github.com/node.js/release 并查看对应的 Issue，通常会有一个 Issue 标题中有对应的版本号，所以在这种情况下，我们可以看到 12，10，14，15。
然后在那里会看到一张表格，上面列出了计划发布的内容和对应发布版本的志愿者。有时我们不会走得很激进。所以，你知道，下一个 15 版本计划在 12 月 22 日发布，我们没有任何这之外的计划。你可以从那里得到最新的信息。所以希望大家能理解这个发布过程，这个过程是非常可预测的。这是一个很好的方法来了解将要发生的变化。
事实上，如果你看一下发行日志或者我们将要进入每个流程的主要变化。特别是在现在的 Current 版本中。你也可以看到下一个主要版本中会出现什么。所以这是了解发生了什么的好方法。
有趣的功能
现在让我们来谈谈有趣的新功能。我发现人们通常认为大版本看起来很无聊，这些大版本中的特性看起来都像是好久之前就已经出现过的特性。比如刚刚说到的 LTS 版本或者是 Current 版本。值得一提的是，有趣的特性通常都在 Server Minor 版本中发布，然后这些特性才会被提交到 LTS 和 Current 版本中去。所以当我们有一个新的 Major 版本更新，这些新的功能大部分是旧新闻。Major 版本中东西主要是几个重要更新项目，虽然我们很努力地把这些变更的影响降到最低，所以他们不一定会很有趣。
虽然说是技术上的突破，但我们真的不希望因为更新与变更影响很多人。非常重要的一点，在10月份，当我们过渡到 LTS 版本之后，这将是你第一次可以在一个长期支持版本中使用这些功能。因此，尽管该功能在该版本中不是新的，但它可能是你第一次能将其用于生产环境的版本。
一个非常好的例子是 ECMAScript Module。Node.js 13.2 是第一次我们宣布支持 ECMAScript Module。你可以注意到，在那个发布的时候，它不是一个 Major 版本，它实际上只是一个发布时间点。事实上，这些变更才刚刚在 Master 分支上被取消了实验性特性标记。这很可能已经在 Node.js v15 中发布了，但它不会被限制在 Major 版本上。这个取消“实验性功能”标记只是一个小变动。所以这就是为什么我们有很多新功能和有趣的功能，但它们不一定是在那些 Semver Major 更新上的。
ECMAScript Modules
也许你们中的许多人已经熟悉 ES6 和 ECMAScript Modules。但 Node.js 已经使用 CommonJS 非常长一段时间了。在某一时间点上，浏览器和标准组织意识到，我们需要有一个 JavaScript 的模块系统。他们定义了一些东西，不幸的是，这取决于你如何看待它，这个标准定义对于 Node.js 来说，提出了非常大的挑战。
比如我们通过 module.exports 导出一个函数，然后通过 require 来获取 exports。但是 ES import 改变了非常多基础的定义，比如 CommonJS 中导入是同步的，ES6 中导入是异步的。这些事情给 Node.js 带来非常大的挑战性。这就是为什么我们花了大量的时间给 Node.js 实现这个特性。我们有一个很棒的模块工作组，有很多非常有才华的人，他们在这方面工作，我们花了很多时间去调整实现，改进工程工效，一个很好的例子是，你现在可以在你的 package.json 中定义 type 为 module，然后项目内后缀为 .js 文件就会被 Node.js 认为是 ES6 Module。这之前也是有很多人抱怨缺失的特性。就在几个星期前，11月18日，这个 PR 标记 ECMAScript Module 为稳定特性并合并入 Master。在你看到这个内容的时候，它可能也已经在 Node.js v15 发布了。
不得不说的是，ES Module 肯定是花了很长的时间，但这是一个很好的新功能，人们可以开始学习和使用，希望它会得到更多的吸引力。
Unhandled Rejection
这是另一个很长的时间来改变的特性。我们已经有一些废弃提醒，像下面这样，如果有未经处理的 Promise 异常没有处理，基本上，没有可以处理这个异常的地方了，那么会有一个提示来提醒你你有一个未处理的异常，这些提示可能会在未来的某个时候变成抛出一个错误。
这个有很多讨论，因为这对最终用户来说是一个潜在的破坏性变化。我们做了一系列的工作，以最大限度地减少影响，我稍后会讨论这一点。在 Node.js v15 之前，你实际上会得到一个警告，并且可能你的应用程序处于未知状态，但它会继续运行。今天，在默认情况下，你会得到这个未处理的 Promise 错误，Node.js 进程将退出。我们也相信大多数用户相信这是正确的，因为我们做了一个调查，这就是我们得到的反馈，这是更好的行为。因为你会发现，如果你不这样做，如果你有异常未处理，应用程序可能会处在一个不是你期望的状态。
我们当然理解生产环境的应用程序要升级到 v15 或以上，但是还没开始处理这个问题。你可以很容易地通过使用 Node 的命令行参数 --unhandled-rejections=warn 返回到旧的行为。当然，更好的情况是你应该回到你的代码里，找到你没有捕获那些异常。
ICU
ICU 是 Unicode 国际化组件（International Components for Unicode），给 Node.js 提供了 Unicode 与国际化支持。v14.x 是 Node.js 第一次默认携带了 Full ICU 数据的 LTS 版本。所以如果我们看一下这段代码使用了 JavaScript Intl API 来格式化日期。
在 14.x 之前，即使你要求了特定的语言，例如俄语、中文，在任何情况下，你仍然会得到他们的英文格式，因为 Node.js 默认不携带国际化数据，你必须单独加载这些国际化的数据。在 v14.x 中，这些国际化数据已经打包进了 Node.js 二进制文件，你可以得到正确的结果，我认为这非常有帮助。
诊断报告
当我们发现客户在生产中出现问题时，诊断报告是非常有帮助的。这是一个客户能够快速提供案发现场的方式。而诊断报告是一种可读性良好的 JSON 格式报告，它有很多有趣关键的信息。客户可以快速浏览它，确认没有敏感信息，或者对它进行脱敏，然后再把报告发给你。它具有关键信息，如命令行参数，进程信息，垃圾回收与堆内存的信息，组件版本，调用栈，环境变量。所有能给你一个解决问题有利开端的信息。
同样的，v14.x 是你第一次可以在 LTS 版本稳定中使用这个特性。
实际上，就在几个月前，我收到了一位客户的报告。其中包括一份诊断报告，我先阅读报告，弄清楚发生了什么，验证我的想法是否正确，然后在这些完成后返回给客户我的结论，这就是报告起作用的方式。如果没有诊断报告的话，我就做不到这些。我们可能会需要花费更多的时间和精力。你可以通过几行命令来启用诊断报告，这在常见的问题上是很有帮助的，比如未捕获的异常，信号，致命错误等。典型的情况是你可以通过一个信号生成报告，你也可以以编程方式来在你的应用中启用它，比如 process.report.writeReport()。
AsyncLocalStorage
AsyncLocalStorage 对于一些操作，比如跨流程的事务跟踪很重要。但实际上，即使你正在进行跨流程操作，你也需要能够在整个事务中你自己的流程内保持状态。你想在这些异步调用中维护状态，在其他有线程模型的语言如 Java 中，你可以使用 TreahdLocal 来很容易做到这一点。但在 Node.js 和其它基于异步的语言中不是这样，因为 Node.js 是同步的，很难在异步上下文中维护此状态。这就是 AysncLocalStorage 想要达到的，不过它仍然是一个实验性的功能。
但如果我们注意这个代码，这里有运行在同一个 AysncLocalStorage 的两个实例。在这个例子中，我们已经创建了一个 AysncLocalStorage，在这里的最下面我们想为每一个异步流传入上下文。它模拟了一个 Web 服务器，并将 URL 存储在上下文中。然后经过一段时间，也就是模拟一些延迟，再同步的去调用，我们得到那个 URL 并打印。
以及从输出中显示的是，我启动了异步流。并且即使我使用相同的 asyncLocal1 对象，每次我得到的 store 都是特定于此 AsyncLocalStorage 的。在这种情况下，我会得到 store1 或 store2，取决于实际与该特定 store 相关联的异步流。在这种情况下，异步流以何种顺序运行并不重要，你会得到与异步流正确关联的那个。我认为这对 APM 来说真的很重要，这是我们正在努力解决的问题。
下一步是使得它成为非实验性的，同时得到一些不错的反馈。
AbortController
AbortController 主要是为了能对一些长时运行的、基于 Promise 的 API 进行取消和中断。它还处于我们还在进行实验的阶段。我们引入中断控制器是因为这样我们就可以开始将它和一些 Node.js 的 API 进行结合。你可以在文档中阅读更多关于它的信息。
QUIC
可能还需要几年才能使用 QUIC，但我们提供了一个编译选项，你可以启用这个选项编译你自己的 Node.js，你就可以开始实验性地尝试使用 QUIC。这可能是 HTTP3 和未来的 HTTP 实现的基础。所以，如果你想进行一些尝试，比如说未来甚至是更远，这是一件你值得尝试的好事。
战略举措与委员会
在 Node.js 项目中一共有两套战略举措，一套在技术指导委员会执行，一套在社区委员会中执行：
技术指导委员会会主动增加更多基于 Promise 的核心 API。我们已经在这上面工作了很多年了。基本上是在不同的 API 中引入一些基于 Promise 的 API。我们会持续尝试并使保持最新 V8 引擎版本，当前这仍然在不断进行，这样就能不断地引入 JavaScript 中的新语言特性。在 V8 中实现这些新特性我们基本不需要做什么工作，但我们确保这些特性会尽快地在 Node.js 中更新。
另外，张秋怡也正在攻克启动性能。众所周知 Node.js 的成功，其中一个很大的原因是它体积小，启动速度快以及性能优异。她正在努力确保我们能在已经很不错的启动性能这点上继续做出提升，这是相当好。
构建资源，我们试图帮助我们的构建团队获得更多能够提供帮助的人。我们依赖于像 GYP 这样的东西，谷歌不会再提供支持，所以我们想在这方面做一些改变。
在社区中同样有一些战略举措，比如从像 i18n 帮助我们进行国际化和网站文本的翻译，也包括一些 Node.js 的文档。
我们还提供了导师项目，现在实际上是相当关注度的。我们正试图找到能够与我们某些团队工作组匹配的人，并帮助他们快速融入组织。我们有负责人在改善使用例子，比如你通常想用 Node.js 做的例子与事情，比如关于如何开始。你可以看看代码和相关消息，我们目前也在尝试网站重新设计，你可以在“我们如何迁移到下一代网站”中查看细节。
所以这些都是战略举措，它是一种使得我们的团队与工作组获得平衡的方式。有时只是通过 Github 进行工作，另外团队和工作组有一些重叠，但不一定与那些战略问题一一对应。
工作组
实际上，有相当多数量的优秀团队和工作团队，由于人数太多我没法一一介绍，但我会强调其中的几个，我觉得很有趣的，像 N-API，诊断，未来十年计划，包维护和 Web 服务器框架。
N-API
N-API 是一个允许你以一种方式构建原生扩展（Add-ons）的 API，我们保证了 abi-stable，这样你就不必在你升级到 Node.js 新版本时重新编译 Addon 模块。在使用 N-API 之前，构建你自己的 Addon，他们被直接链接到 V8 API，这是 Node.js 本身的一部分。幸运或者不幸的是，这方面 API 正在快速迭代，API 正在不断演进，这意味着很多事情。我们在 Node.js 内部强制使得每次使用不同版本的 Node.js，你要重新编译这些 Addon。用来确保 Addon 是针对当前的 V8 API 工作的，因为自上一个版本以来，它很可能发生了变化。如果你想提供预构建的二进制文件，这确实带来了一些不同的困难，因为必须让最终用户在他们安装你提供的模块时，安装编译器以及相关工具，这是一个挑战。
我想说很多广泛使用的插件都有使用预构建二进制的 API，但是对于每个 Node.js LTS 都必须有一个不同的 API，那么这就成了一个很大的管理问题。需要针对不同的 Node.js 构建一个统一的 API，然后针对这些不同的 Node.js 版本运行。
我再次感谢吴成忠（昭朗）对 Node.js N-API 和其他部分的贡献，他一直是一个非常积极的贡献者，并帮助推动我们前进，这真的很棒。
在过去的一段时间，N-API 团队一直致力于 Node.js 核心和 node-addon-api 的工作。Node 核心提供了基于 C 的 API。这是我们去提供 ABI 稳定的 Node.js 和 ABI 稳定所需的 API。而 node-addon-api 提供了封装了这些 C API 的 C++ 的 API。基本上它只是个语法糖，让 N-API 使用更加容易。我们一直致力于这两个工作。
我们已经添加了诸如 ThreadSafe Functions，Date Objects，BigInts，Detached ArrayBuffers，其中一个重点是，上下文敏感和 Workers。Worker 使 Node.js 具备启动和停止新 JavaScript 执行环境的能力，更重要的是停止这个执行环境。这就是说，如果你在 Worker 中使用了 Addon，当关闭时，你希望它们能被正确清理掉。如果有多线程运行你的 Addon，每个线程都具有各自的上下文，这样它们就不会互相影响，所以很多工作都围绕着这些展开。
除此外还有一些在构建方面的工作，之前提到的预编译二进制。所以一些团队成员也在帮助补充 node-gyp，node-pre-gyp 和预编译使这些流程在 Node.js 下好使。
我们知道这将是长期的过程，大概三四年前，我们启动这项工作，只知道这将需要很长的迁移过程，但是我们今年已经看到 node-addon-api 的下载量趋向三百万次下载/周。真是非常高兴看到这样的结果。
诊断
诊断很重要。对我而言，因为我们需要支持客户，因此需要好的诊断工具，所以我们一直是诊断工作组的积极成员。Gireesh 与我们合作落地了诊断报告。回过头看，我认为这是一件很非常重要的事情。当然诊断工作组还做了很多其他好事情，最近，我们也重点关注诊断的最佳实践，我们想要写下来并记录以下方面的最佳实践，处理诸如内存泄漏，进程崩溃，性能等通用性问题，我们为此进行了许多头脑风暴并记录在 DeepDive 文档中。现在我们要写成文档，那样我们可以放到诊断网站上，Node.js 网站就可以帮助用户完成这些工作。
还有如之前提到的 AsyncLocalStorage，那是诊断工作组所做的另外一件事。就在最近，Qard 一直在研究 Diagnostic Channel，提供 monkey-patch 模块的另一种方法。APM 之类的需要获取数据，而模块和 Node.js 需要提供数据，可无需 Monkey Patching。或诸如 Async Hooks 之类的方法，后面会谈到 Async Hooks。简言之，这是个数据流，如果你感兴趣你可以注册并监听。
如果你关注 Node.js 社区和诊断有一段时间了，你可能想知道，Async Hooks 怎么样了，它们已经实验了很长时间了。的确，它们可能会一直这样保持下去。因为经过讨论，我们还没那么满意目前来说需要保证稳定的 API 模型。我们担心它会暴露出一些我们不希望人们去依赖的内部结构。所以，我们一直在进行 AsyncLocalStorage 之类的工作。这是最近一次诊断峰会上提出的，也许我们可以构建其他一些我们愿意公开的 API，并使其稳定地构建在 Async Hooks 之上。
AsyncLocalStorage，DiagnosticChannel，这些就是我们试图提供给人们所需要的数据的方法，而不是通过 Async Hooks。而 Node 内部来使用 Async Hooks 去实现，这是可以的。对于 Node.js 而言，更多的是内部事务，而不是希望外部用户使用的 API。
Next-10 未来十年计划
Next-10 团队正在研究项目的战略方向。我知道我们说过，还没有路线图。但这并不意味着我们不在乎未来，弄清楚我们需要做什么以满足我们所有的用户。
实际上，那个团队的目标是回顾弄清楚在最初的十年是什么使 Node.js 如此成功，弄明白我们应该专注于什么，在未来十年一样成功，甚至更成功。在这种讨论中，我们首先会说“这项技术如何？或者那个技术？是不是我们需要的？Typescript 如何适应？WebAssembly 如何适应？”，经常来来回回。我们需要一些原则，所以我们有专注过这些原则。
第一，有哪些技术价值我们相信能反映项目的信念，然后我们定义出那些技术价值。这样当我们进行权衡时，我们至少有一些信息，让我们能平衡事物。从来没有黑白，从来没有一个胜过另一个。这给我们一个好框架去思考，就重要性而言，去影响这些特性的价值，我们应该如何解决冲突之类的问题。
第二，我们看的是支持者。就像我们将要成功一样，我们需要考虑的是谁？需要谁去做？还有谁要使它成功？是直接终端用户，还是使用应用的人士，应用运维工程师，Node.js 应用工程师，应用程序开发者，库/包的作者，核心维护者，还是有大量投资的组织？许多大型组织会选择较少的技术进行投资，因此考虑他们的需求也很重要。我们一直在集思广益，这些有什么需求？然后我们实际上想到了，在不同支持者中需求有很多的重叠。我们正在努力解决需求，并希望将为我们提供基础以弄清楚项目中与技术相关的事情是什么，我们应该做些什么来推进。
这还在初期，还是一种想法。当我们能吸引更多的想法和更多的人参与其中，我认为会有更好的答案。所以我期待有更多的参与者。
包维护
这个工作小组的重点是找出在软件包生态系统中所面临的一些挑战并帮助软件包的维护者和使用者以最有效的方式协作。我们一直努力的一件事是最佳实践，并已经推广了一套我们支持的最佳做法，我们认为维护人员应该遵循的好方法（当然得他们愿意）。
如果你正在寻找建议又不想自己搞定，这里有很多最佳做法。这包含很多事情，比如许可，版本控制，测试，还有正在努力编撰的像行为准则、发布实践等等草稿。
我之前提到了消费者和维护者协作时，其中经常可能存在沟通鸿沟。维护者可能会创建一个模块只是为了好玩。然后就有了一项业务开始依赖这个模块，用于关键信息的处理。所以我们在这方面做的一件事，等会会更详细地讨论，叫做为支持信息元数据包。
我们希望维护者可以把这些元信息添加到 package.json，让消费者快速了解到维护者在支持意图上的响应速度。比如说明你是否提供支持，如果你提供，那么人们就期望在 package.json 中其他更多的支持信息。
第一个部分是支持目标计划，基本上是说，我打算支持什么版本。这些字段描述了支持意图，比如我打算支持所有 LTS 版本。
另外就是反馈。如果作为一名消费者，我有一个问题，并报告一个问题，我应该对得到帮助有什么样的期望？这可以是什么都没有。“嘿，作为维护者，我甚至不会有时间允许做任何协助，就像只是为了好玩”。或者当你找到我的时候，我实际上可以有提供一个有偿的支持，你知道，如果你签订了支持合同，这里是你可以得到的联系人。所以这基本上，就是一个关于你应该期望能够得到多少帮助的预期。
最后，这里提供了一个链接，你可以从这里知道我们的项目已经有了什么样的支持，以及如何支持这个项目的信息。你知道我们希望的是，这将提供一种方式，或者让消费者理解。
目前有很多工具正在开发中，可以提供数据查阅，查看所有的依赖关系，找出有隔阂的点。
我认为这对于一家公司或消费者，懂得去管理风险是非常重要的。如果你希望投资于你正在使用的关键模块的话，那就更棒了，如果他们没有足够的支持，你可以弄清楚你可以怎么提供支持。
我们开发了 @pkgjs/support 来帮助许多维护者将支持信息添加到他们的模块中。开始使用非常简单，它现在主要的事情就是为维护者验证编写的元信息，因此，它将帮助你验证并确保你以正确的格式编写了支持元信息。
我们也一直在研究跨包依赖测试。如果你维护了一个模块，被很多其他模块依赖，那么每次你做一个改变，你可能会影响那些模块。在我们 Node.js 项目中使用的基础上，我们开发了 CITGM，也就是 Canary In The Gold Mine，金矿中的金丝雀。我们正在寻找帮助模块维护者的方法，测试这些依赖模块。它实际上是和 Node.js 项目中的 CITGM 有很大的不同，因为我们有 CI，它让我们运行在一堆不同的 Node.js 版本，平台等等，但对于模块维护者来说，情况并非如此。
所以我们采取的方法是在这些依赖的项目中运行，并使用它们的基础设施，这可能是我们可以大规模部署以及得到实际测试的唯一方法。
最后，我们也一直在研究如何帮助那些想要获得额外资源的项目，比如引导更多的人成为额外的维护者。我们的 Triage 团队在这方面投入了许多。他们为模块维护者提供帮助，表达流程和程序之类的东西，所以我们可以帮助想在这一点上做的更好的维护者们。而这也帮助 Node.js 项目引入了 Triage 角色来帮助 Node.js 的维护中最缺失的一块工作，这些工作通常不是一大堆 PR，而是管理 Node.js 项目中大量的 Issue。
Web 服务器框架
这个工作组在谈论未来的 HTTP。现在还是非常早期的阶段。在 undici 中，我们正在实验一种新的 HTTP API。因此，如果你对此感兴趣，这是非常值得参与其中的伟大团队。
OpenJS 基金会
在过去的一年里，我们已经有一些重要的项目，如 Electron，amp，Fastify 取得了一些成功。我们还启动了协作网络，这是对于 OpenJS 来说一个很好的策略，支持不一定是基于一个项目，还可以是 JavaScript 生态系统很重要的领域，并支持需要在这些领域的讨论和对话。如果你认为有一个特定的领域，社区应该在 OpenJS 基金会下讨论，这是一个很好的方式。
近期也推出了有很大进展的认证项目，最近它也被翻译成了中文，感谢阿里巴巴的 Node.js 基础团队的朱凯迪（死月）帮助翻译。目前认证项目已经上线，已经提供了非常多的语言版本。
结语
对于 Node.js 的未来，我总是喜欢说，这取决于你。正如我们之前说过的，它不是由一家公司来控制的，非常多的贡献者都产生了巨大的影响。那么你为什么不在 GitHub 和我们见面，和我们一起决定 Node.js 的未来？
所以非常感谢你看完了我的内容，我非常欢迎大家通过下面的一些渠道向我问题，和我讨论。非常感谢，下次再见。
关注「Alibaba F2E」
回复 「PPT」一键获取大会完整PPT
