Categories
程式開發

Node.js 14 正式发布:V8引擎升级,新增异步本地存储API


Node.js 14 正式发布:V8引擎升级,新增异步本地存储API 1

Node.js 14版本于近日正式发布, 此版本包含的亮点如下:

  • 对诊断功能的改进
  • 升级v8引擎
  • 新增实验性的异步本地存储API
  • 强化流API
  • 移除实验性模块中的警告
  • 移除一部分早期版本中废弃的API

本文最初发布于 MediumNodejs 专栏,经原作者授权由InfoQ中文站翻译并分享

Node.js 14取代Node.js 13成为了我们的当前(current)版本。根据发布时间表,Node.js 14将是未来6个月的当前版本,然后在2020年10月升级为稳定版本(LTS)。 像往常一样,企业用户应该等到10月份Node.js 升级为LTS之后,再升级其生产环境中的Node.js版本。 不过,现在是使用Node.js 14测试应用和尝试新功能的最佳时机。

提醒一下,Node.js 12和Node.js 10的稳定版本将分别持续维护到2022年4月和2021年4月(点击查看更多LTS策略)。

点击https://nodejs.org/en/download/current/下载新版本,马上开始学习吧!

在我们开始深入介绍新版本的功能之前,需要提醒一点,那就是新版本中添加的功能会很快被添加到当前稳定版本中去,这就意味着我们在不升级主版本的情况下,也可以在当前稳定版本的小版本更新中使用这些新功能。因此借这个机会我们向大家重点介绍下Node.js 14版本中的一些内容,即使这些内容中可能有些部分已经在之前的版本中存在了。

诊断报告变成稳定功能

在Node.js 14中诊断报告将是一个稳定的功能(在Node.js 12中是试验性的功能)。在推进和建立可用、易用的Node.js诊断功能的工作进程中,这是非常重要的一步。其中大部分工作是由Node.js诊断工作组推进的。

诊断报告功能使你在生成报告的时候,既可以根据需要生成,也可以通过事件触发生成。对诊断报告的信息分析可以帮助你诊断各种生产环境问题,包括崩溃、性能慢、内存泄露、CPU 使用率高、未捕获的异常等。点击链接可以了解到更多关于诊断报告功能的信息。作为一个稳定的特性,启用诊断报告所需的命令行选项将减少一个,并且用户在生产环境中可以很容易启用它。

V8 升级到 V8 8.1

与往常一样,新版本的 V8 JavaScript 引擎带来了性能调整和改进,同时也使Node.js保持了在语言和运行时方面持续改进的一致性。V8的升级还给我们带来了一个好玩的命名,V8的版本8(“ V8的 V8”)。

新的JavaScript功能主要包括:

  • 可选链——MDN
  • Nullish合并——MDN
  • Intl.DisplayNames ——MDN
  • 为 Intl.DateTimeFormat 启用 calendar 和 numberingSystem 选项——MDN

了解V8中新功能的更多信息,请查看Node.js V8博客:https://v8.dev/blog

实验性异步本地存储API

该项目一直在致力于帮助管理多个版本之间异步调用上下文的API。实验性Async Hooks API 已在早期的版本中引入了。Async Hook 的关键用例之一是异步本地存储(也称为连续本地存储)。已经有许多npm模块提供了API来满足这种需求,但是这些年来,在 Node.js 核心之外维护这些功能一直很棘手;并且在这个项目上社区已经达成共识,认为由Node.js提供统一的API会更合理,因此14.x 版本带来了实验性的Async Local storage API(也在13.10中添加了该API)。我们正在寻求社区来尝试这个API,并向我们反馈有关抽象模型、API接口、用例覆盖范围、功能稳定性、命名、文档等方面的信息,这样我们就可以在以后的版本中将其变成稳定功能。给我们提供反馈的最佳方法是在诊断仓库的问题区)创建一个问题,并命名为“AsyncLocalStorage API的经验报告”。

在Node.js的流实现中,此版本中提供了一些标记为SemVer major(译者注:SemVer major表示的是大版本号不兼容)的更改。这些更改旨在提高Streams API的一致性,以消除歧义并简化Node.js核心各个部分的行为。例如,http.OutgoingMessage与stream.Writable类似,而net.Socket 的行为和stream.Duplex完全一样。一个显著的变化是autoDestroy选项现在默认设置为 true,使流在结束后始终调用_destroy。尽管我们认为这些SemVer major更改对大多数程序不会有影响,因为它们只更改了一些边缘的场景,但如果你严重依赖Stream,最好在Node.js 14还是当前版本时进行测试,以便为未来的发布做好准备。 Node.js 14将会在2020年10月成为 LTS。

实验性 Web Assembly 系统接口

用Web Assembly编写的 Node.js包为某些使用场景带来了更好的性能和跨平台支持的机会。 为了支持这些场景,14.x版本中包含了Web Assembly系统接口(WASI)的实验性实现。虽然WASI对Node.js v14来说并不是新事物,但值得注意的是它在简化原生模块的体验上非常有潜力。你可以在 API 文档中了解有关它的更多信息:https://nodejs.org/api/wasi.html。

移除实验模块警告

其实在Node.js 13中,我们就已经移除了实验模块警告,不再需要使用 -experimental-modules标志来处理,但是如果在Node.js中使用EcmaScript Modules功能,Node.js 13中仍然会发出实验功能警告:ESM模块导入属于试验性功能。

从 Node.js 14 开始,在Node.js中使用ESM时不再会出现此警告。虽然Node.js 中的 ESM 实现仍处于试验阶段。根据我们的稳定性指数:“该功能不受语义版本控制规则的约束。向后兼容的更改或删除可能会在将来的任何版本中发生。”在生产环境中用户应谨慎使用该功能。

请记住,Node.js中ESM的实现和你所熟悉的并不一样。大多数转译工作流都支持的一些功能是Node.js ESM实现不支持的,例如:可选的文件扩展名或者JSON模块。来自转译环境的模块很可能需要一定程度的重构才能在Node.js中使用。值得一提的是,我们的许多设计决策都是基于两个主要目标做出的,即规范合规性和 Web 兼容性。我们相信,当前的实现为编写ESM模块提供了一个可以长期使用的模型,为走向通用JavaScript的目标铺平了道路。请在文档中阅读更多内容。

虽然当前Node.js中的ESM实现仍处于试验阶段,但我们相信,推进Node.js中ESM功能到“稳定”状态是近在咫尺的。消除警告是朝这个方向迈出的重要一步。

新的编译器和平台最低要求

Node.js为很多平台提供了预构建二进制文件。针对每个主版本,都会对最小工具链做适当的评估和提高。

为了支持包认证功能,我们在这次发布时将所有macOS的二进制文件转到了macOS 10.15(Catalina)下用Xcode 11编译了。由于二进制文件仍在编译中,以达到支持相应编译目标的发行要求,我们预计不会对较老版本的macOS 的 Node.js 用户产生负面影响。针对Node.js 14,我们将最低的macOS支持版本提高到了macOS 10.13(High Sierra)。

在基于 Linux 的平台上,对于 Node.js 14,最低 GCC 版本仍为 GCC 6,但是我们计划为某些使用 GCC 8 的平台构建并发布二进制文件。

针对停止维护的Windows系统版本,Node.js 14将不会为其发布版本。

有关更多详细信息,请参见Node.js BUILDING.md

行动呼吁

在进入 “current” 阶段的 6 个月中,Node.js 14将接受大量贡献到Node.js中的新特性,因此在接下来的6个月中,此发行版本非常适合进行功能尝试、项目测试以及升级Node.js到最新版本的兼容性测试,同时,请给我们提供反馈,帮助该发行版在10月顺利过渡到 LTS。

感谢!

我们想借此机会对所有促成此版本发布的贡献者和 Node.js 合作者表示非常感谢。我们还要感谢 Node.js 构建工作组 确保我们拥有创建和测试发行版的基础架构,并对 Node.js 14 的工具链进行必要的升级。

你可以点击这里查看v14.0.0版本的完整功能列表。

本博客由 Michael Dawson 和 Bethany Griggs 撰写,同时Node.js 社区委员会和 Node.js 技术指导委员会也对内容做了贡献。

原文链接:

Node.js version 14 available now