Electron 20.0.0 已发布！ 它包括升级到 Chromium 104, V8 10.4, 和 Node.js 16.15.0。 请阅读下文了解更多详情！

Electron 团队很高兴发布了 Electron 20.0.0！ 您可以通过 npm install electron@latest 进行安装，或者从我们的 发布网站 下载它。 继续阅读有关此版本的详细信息，并请分享您的任何反馈！

重要变化​

新特性​

• 在 Windows 上添加了沉浸式暗黑模式。 #34549
• 添加支持类似面板的行为。 窗口可以浮动在全屏应用上。 #34665
• 更新了 Windows 控件覆盖按钮，使其在 Windows 11 上的外观和感觉更加原生。 #34888
• 现在开始，渲染器在默认情况下会被沙盒化，除非指定了 nodeIntegration: true 或 sandbox: false。 #35125
• 添加了使用 nan 构建原生模块时的保护措施。 #35160

Stack Changes​

• Chromium 104
  • Chrome 104 新特性
  • Chrome 103 新特性
  • DevTools 中的新增功能
• Node.js 16.15.0
  • Node 16.15.0 博文
• V8 10.4

破坏性 & API 更改​

以下是 Electron 20 中引入的破坏性变化。 有关这些和未来变化的更多信息可在 计划的突破性变化 页面找到。

V8 Memory Cage 已启用​

Electron 20 启用 V8 沙盒指针，继Chrome 决定在 Chrome 103 做同样的事情。 这对原生模块有一定的影响。 此功能具有性能和安全优势，但也对 native modules, 施加了一些新的限制，例如，使用指向外部 ("off-heap") 内存的 ArrayBuffers。 更多信息请查看 博客文章。

默认值被更改：默认情况下，渲染器不为 nodeIntegration: true 将进行沙盒处理​

之前, 指定预加载脚本的渲染器默认不启用沙盒。 这意味着默认情况下，预加载脚本可以访问Node.js。 在 Electron 20中，此默认值将被更改。 从Electron 20开始，渲染器 默认情况下会被沙盒化，除非指定了 nodeIntegration: true 或 sandbox: false 。

如果预加载脚本不依赖于 Node，则无需执行任何操作。 如果 preload 脚本依赖于 Node，请重构代码，或从渲染器中删除 Node 用法 ，或者显式指定相关渲染器 sandbox: false 。

修复：nan原生模块自发崩溃的问题​

在 Electron 20 中，我们更改了两个与原生模块相关的项目：

1. V8 headers 现在默认使用 c++17 。 这个标志已添加到 electron-rebuild 了。
2. 我们修复了一个问题，即一个缺失的 include 导致依赖于 nan 的原生模块自发崩溃。

为了获得最大的稳定性，我们建议在重新构建原生模块时使用 node-gyp >= 8.4.0 和 electron-rebuild >= 3.2.9，特别是依赖于nan的模块。 有关更多信息，请参阅 electron #35160 和 node-gyp #2497 。

已删除：Linux 上的 .skipTaskbar​

在 X11上, skipTaskbar 向 X11 窗口管理器发送一条 _NET_WM_STATE_SKIP_TASKBAR 消息。 Wayland 没有与其一致的功能，并且已知的 变通办法具有不可接受的理由（如，在 GNOME 中 Window.is_skip_taskbar 需要不安全模式），因此 Electron 无法在 Linux 上支持此功能。

终止对 17.x.y 的支持​

根据项目的支持政策，Electron 17.x.y 已经达到了支持的终点。 我们鼓励开发者和应用程序升级到更新的 Electron 版本。

下一步做什么​

在短期内，你可以期待我们的团队继续专注于跟上构成 Electron 的主要组件的发展，包括 Chromium、Node 和 V8。 虽然我们谨慎地不对发布日期做出承诺，但我们的计划是大约每2个月发布一次带有新版本组件的主要版本的 Electron。

您可以在此处找到 Electron的公开时间表。

有关这些和未来变化的更多信息可在 计划的突破性变化 页面找到。

Electron 20及更高版本将启用 V8 内存隔离区，这将对一些原生模块产生影响。

在Electron 20中，我们将启用 V8沙盒指针， Electron中，Chrome 决定在Chrome 103中执行相同的操作。 这对原生模块有一定的影响。 此外，我们曾在 Electron 14 中启用了 指针压缩 相关技术。 我们当时没有对此进行过多地讨论，但指针压缩对V8最大堆大小有影响。

这两种技术一旦启用，将对安全、性能和内存使用大有裨益。 但是，启用它们也有一些缺点。

启用沙盒指针的主要缺点是，不再允许进行指向外部 ("off-heap") 内存 的数组缓冲区的操作。 这意味着在V8中依赖于此功能的原生模块将需要重构才能在Electron 20及更高版本中继续工作。

启用指针压缩的主要缺点是， V8堆的最大大小限制为4GB。 这方面的确切细节有点复杂 - 例如，ArrayBuffers与V8堆的其余部分分开计数，但存在一些 自己的限制。

Electron 升级团队 认为，启用指针压缩和V8内存隔离区的好处超过了缺点。 这样做主要有三个原因：

1. 它使Electron更接近近Chromium。 Electron在复杂的内部细节（如V8配置）中与Chromium的分歧越小，我们就越不可能意外引入错误或安全漏洞。 Chromium的安全团队非常优秀，我们要确保我们能够更多的用到他们的工作成果。 此外，如果一个错误只影响Chromium中未使用的配置，那么修复它不太可能是Chromium团队的首要任务。
2. 它表现得更好。 指针压缩可将 V8 堆大小减小至40%，使CPU 和GC性能提高5%-10%。 对于绝大多数不会碰到4GB堆大小限制并且不使用需要外部缓冲区的本机模块的Electron应用程序，这些都是显着的性能优势。
3. 它更安全。 一些Electron应用程序运行不受信任的JavaScript（希望遵循我们的 安全建议！），对于这些应用程序，启用V8内存笼可以保护它们免受大量令人讨厌的V8漏洞的影响。

最后，对于确实需要更多堆大小的应用，有一些解决方法。 例如，可以在应用（在禁用指针压缩的情况下生成）中包含 Node.js 的副本，并将占用大量内存的工作移动到子进程。 虽然有些复杂，但如果您决定要为特定用例进行不同的权衡，也可以构建禁用指针压缩的Electron的自定义版本。 最后，在不久的将来， wasm64 将允许在Web和Electron中使用WebAssembly构建的应用程序使用超过4GB的内存。

常见问题 (FAQ)​

如何知道我的应用是否受到此更改的影响？​

尝试使用ArrayBuffer包装外部存储器将在Electron 20 +的运行时崩溃。

如果你没有在应用中使用任何原生 Node 模块，那么你是安全的 - 目前没有办法从纯 JS 触发此崩溃。 此更改仅影响原生 Node 模块，这些模块在 V8 堆之外分配内存（例如，使用 malloc 或 new），然后使用 ArrayBuffer 包装外部内存。 这是一个相当罕见的用例，但有些模块确实使用这种技术，并且这些模块需要重构才能与Electron 20 +兼容。

如何测量我的应用正在使用多少 V8 堆内存，以了解我的应用是否接近 4GB 限制？​

在渲染器进程中，您可以使用 performance.memory.usedJSHeapSize，这将返回 V8 堆使用情况（以字节为单位）。 在主过程中，您可以使用 process.memoryUsage().heapUsed，这是可比较的。

什么是 V8 内存隔离区？​

一些文档将其称为“V8沙盒”，但该术语很容易与Chromium中发生的 其他类型的沙盒 混淆，因此我将坚持使用术语“内存隔离区”。

有一种相当常见的V8漏洞利用，如下所示：

1. 在 V8 的 JIT 引擎中查找错误。 JIT 引擎分析代码，以便能够省略慢速运行时类型检查并生成快速的机器代码。 有时，逻辑错误意味着它搞错了这个分析，并省略了它实际需要的类型检查——比如说，它认为x是一个字符串，但实际上它是一个对象。
2. 滥用这种混淆来覆盖 V8 堆中的一些内存，例如，指向 ArrayBuffer 开头的指针。
3. 现在你有一个 ArrayBuffer，它指向你喜欢的任何位置，所以你可以在过程中读取和写入 任何 内存，甚至是 V8 通常无法访问的内存。

V8 内存隔离区是一种旨在明确防止此类攻击的技术。 实现此目的的方法是 不在 V8 堆存储任何指针。 相反，对 V8 堆内其他内存的所有引用都存储为从某个保留区域的开头开始的偏移量。 然后，即使攻击者设法破坏了ArrayBuffer的基址，例如通过利用V8中的类型混淆错误，他们能做的最糟糕的事情就是在笼子里读取和写入内存，他们可能已经这样做了。 关于V8内存隔离区的工作原理还有很多可供阅读的内容，所以我不会在这里进一步详细介绍 - 开始阅读的最佳位置可能是Chromium团队 高级设计文档。

我想重构一个Node原生模块来支持Electron 20+。 我该怎么做？​

有两种方法可以重构原生模块以使其与 V8 内存隔离区兼容。 第一种方法是 ** 外部创建的缓冲区复制到 V8 内存笼中，然后再将它们传递给 JavaScript。 这通常是一个简单的重构，但是当缓冲区很大时，它可能会很慢。 另一种方法是 使用 V8 的内存分配器** 来分配你打算最终传递给 JavaScript 的内存。 这有点复杂，但可以避免复制，这意味着大型缓冲区的性能更好。

为了更具体地说明这一点，下面是一个使用外部数组缓冲区的示例 N-API 模块：

// 创建一些外部分配的缓冲区。
// |create_external_resource| allocates memory via malloc().
size_t length = 0;
void* data = create_external_resource(&length);
// Wrap it in a Buffer--will fail if the memory cage is enabled!
napi_value result;
napi_create_external_buffer(
    env, length, data,
    finalize_external_resource, NULL, &result);

启用内存保护机制时，这将崩溃，因为数据是在保护机制外部分配的。 重构以将数据复制到隔离区中，我们得到：

size_t length = 0;
void* data = create_external_resource(&length);
// Create a new Buffer by copying the data into V8-allocated memory
napi_value result;
void* copied_data = NULL;
napi_create_buffer_copy(env, length, data, &copied_data, &result);
// If you need to access the new copy, |copied_data| is a pointer
// to it!

这会将数据复制到 V8 内存保持架内新分配的内存区域中。 （可选）N-API 还可以提供指向新复制数据的指针，以防您需要在事后修改或引用它。

重构以使用 V8 的内存分配器稍微复杂一些，因为它需要修改 create_external_resource 函数以使用 V8 分配的内存，而不是使用 malloc。 这可能或多或少是可行的，具体取决于您是否控制 create_external_resource的定义。 这个想法是首先使用 V8 创建缓冲区，例如使用 napi_create_buffer，然后将资源初始化到 V8 分配的内存中。 在资源生存期内，必须保留对 Buffer 对象的 napi_ref ，否则 V8 可能会对 Buffer 进行垃圾回收，并可能导致释放后使用错误。

Electron 19.0.0 已发布！ 它包括升级到 Chromium 102, V8 10.2, 和 Node.js 16.14.2。 请阅读下文了解更多详情！

Electron 团队很高兴发布了 Electron 19.0.0！ 您可以通过 npm install electron@latest 进行安装，或者从我们的 发布网站 下载它。 继续阅读有关此版本的详细信息，并请分享您的任何反馈！

重要变化​

Electron 发布时间变更​

该项目正在恢复其支持最新三个主要版本的早期政策。 查看我们的版本文档 以了解更多关于 Electron 版本控制和支持的详细信息。 暂时有四个主要版本，以帮助用户适应从 Electron 15 开始的新版本发布节奏。 您可以在此处阅读 完整详细信息。

更改栈​

• Chromium 102
  • Chrome 102 新特性
  • Chrome 101 新特性
• Node.js 16.14.2
  • Node 16.14.2 博文
• V8 10.2

破坏性 & API 更改​

以下是 Electron 19 中引入的破坏性变化。 有关这些和未来变化的更多信息可在 计划的破坏性变化 页面找到。

在 Linux 上不受支持： .skipTaskbar​

BrowserWindow constructor 选项 skipTaskbar 在 Linux 上不再支持。 在 #33226 中更改

已移除 WebPreferences.preloadURL​

半文档化的 preloadURL 属性已从 Web 首选项中删除。 #33228. 使用 WebPreferences.preload 代替。

终止对 15.x.y 和 16.x.y 的支持​

Electron 14.x.y 和 15.x.y 都已终止支持。 该博客文章 使 Electron 恢复到其支持最新三个主要版本的 早期政策 。 鼓励开发人员和应用程序升级到较新版本的 Electron。

下一步做什么​

在短期内，您可以期望该团队继续专注于跟上构成 Electron 的主要组件的开发，包括 Chromium，Node 和 V8。 虽然我们谨慎地不对发布日期做出承诺，但我们的计划是大约每2个月发布一次带有新版本组件的主要版本的 Electron。

您可以在此处找到 Electron 的公开时间表。

有关这些和未来变化的更多信息可在 计划的破坏性变化 页面找到。

Electron is changing its primary S3 bucket, you may need to update your build scripts

What is happening?

A significant amount of Electron's build artifacts are uploaded to an S3 bucket called gh-contractor-zcbenz. As part of ongoing infrastructure/ownership migrations that started way back in 2020, we will be changing everything that used gh-contractor-zcbenz from its old home in S3 to a new storage system hosted at https://artifacts.electronjs.org. The path prefix that most of our assets use is changing slightly as well. Examples are included below:

Before: https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/dist/v17.0.0/node.lib
After: https://artifacts.electronjs.org/headers/dist/v17.0.0/node.lib

The important things here are the Hostname changed and the /atom-shell prefix changed. Another example, this time for debug symbols:

Before: https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/symbols/path/to/symbol.pdb
After: https://artifacts.electronjs.org/symbols/path/to/symbol.pdb

Again, the hostname changed and the /atom-shell prefix was changed.

How might this impact you?

Anyone using standard build tooling such as electron-rebuild, electron-packager or @electron/get won't have to do anything. This should be the majority of people.

For anyone directly referencing the S3 bucket, you must update your reference to point at the hostname and update the path as well.

What about existing data?

Most data that existed on the gh-contractor-zcbenz bucket has been cloned into the new storage system. This means all debug symbols and all headers have been copied. If you relied on some data in that bucket that hasn't been copied over please raise an issue in electron/electron and let us know.

The current gh-contractor-zcbenz S3 bucket will not be actively deleted. However, we can't guarantee how long that bucket will be left alive. We strongly recommend updating to target the new bucket as soon as possible.

Electron 18.0.0 已发布！ 它包括升级到 Chromium 100, V8 10.0, 和 Node.js 16.13.2。 请阅读下文了解更多详情！

Electron 团队很高兴发布了 Electron 18.0.0.0！ 您可以通过 npm install electron@latest 进行安装，或者从我们的 发布网站 下载它。 继续阅读有关此版本的详细信息，并请分享您的任何反馈！

值得注意的变化​

Electron 发布时间变更​

从 Electron 15 开始，Electron 将每 8 周发布一个新的主要稳定版本。 您可以在此处阅读 完整详细信息。

此外，Electron 将会改变支持的版本，从最新的三个版本改为最新的四个版本，直到 2022 年 5 月。 关于 Electron 版本的更多详细信息，请看我们的 版本管理文档 2022 年 5 月以后，我们将回到支持最新的三个版本。

Stack 更改​

• Chromium 100
  • Chrome 100 新特性
• Node.js 16.13.2
  • Node 16.13.2 博文
• V8 10.0

主要特性​

• 增加 ses.setCodeCachePath() API，用于设置代码缓存目录。 #33286
• 移除了基于旧的 BrowserWindowProxy 的 window.open 实现。 这也删除了 webPreferences 中的 nativeWindowOpen 选项。 #29405
• 在 WebContents 中增加了 'focus' 和 'blur' 事件。 #25873
• 在 MacOS 上添加了替换菜单角色：showSubstitutions``toggleSmartQuotes``toggleSmartDashes``toggleTextReplacement #32024
• 在 app.requestSingleInstanceLock() 流中增加了 first-instance-ack 事件，以便用户就可以将一些数据从第二个实例传回给第一个实例。 #31460
• 在 setBackgroundColor 中增加了更多颜色的支持。 #33364

有关新功能和变更的完整列表，请参阅 18.0.0 发布通知 。

破坏性 & API 更改​

以下是 Electron 18 中引入的突破性变化。 有关这些和未来变化的更多信息可在 计划的突破性变化 页面找到。

已移除： nativeWindowOpen​

在 Electron 15之前， window.open 默认使用 BrowserWindowProxy。 这意味着 window.open('about:blank') 无法打开可同步编写脚本的子窗口，以及有其他不兼容之处。 自 Electron 15 起, nativeWindowOpen 将默认启用。

有关更多详细信息，请参阅 Electron 中的 window.open 文档。 删除此功能的 PR: #29405

终止对 14.x.y 的支持​

根据项目的支持政策，Electron 14.x.y 已经达到了支持的终点。 我们鼓励开发者和应用程序升级到更新的 Electron版本。

从 Electron 15 开始，我们已经将支持的版本从最新的三个版本改为最新的四个版本，直到 2022 年 5 月的 Electron 19。 在 Electron 19 之后，我们将回归到支持最新的三个版本。 此版本支持变化是我们新的节奏变化的一部分。 请参阅 我们的博客文章 ，了解的完整详细信息。

接下来​

在短期内，你可以期待我们的团队继续专注于跟上构成 Electron 的主要组件的发展，包括 Chromium、Node 和 V8。 尽管我们很谨慎，不对发布日期作出承诺，但我们的计划是大约每两个月发布一次 Electron 的主要版本和这些组件的新版本。

您可以在此处找到 Electron的公开时间表。

有关这些和未来变化的更多信息可在 计划的突破性变化 页面找到。

Electron 团队很高兴地宣布，今年我们将首次参加 Google 代码之夏（Summer of Code）！

什么是 Google 代码之夏?​

Google Summer of Code（GSoC）是一项年度指导计划，将开源软件项目与潜在贡献者联系起来。 以前只对学生开放，任何18岁及以上的人现在都可以注册GSoC。

有关更多信息，请查看 Summer of Code 主页。

我该如何参加？​

您有兴趣与Electron合作吗？ 如果您是新手或初学者开源贡献者，我们欢迎您申请！

为了被选为Google Summer of Code的电子贡献者，您需要提交申请。 申请将于2022年4月4日 开放，并于2022年4月19日结束。 您可以在此处关注 Google 代码之夏应用程序指南的更新。

想要申请吗？ 首先，查看我们准备的 五个项目创意草案 。 所有列出的想法目前都开放供提案。 我们也愿意接受不在拟议项目清单上的新想法。

您的申请应包括：

• 您的提案，这是一份书面文件，详细描述了您计划在夏季实现的目标。
• 您作为开发者的背景。 如果您有简历，请附上一份副本，否则请告诉我们您过去的经验，重点是相关的技术经验。

A detailed guide of what to submit as part of your Electron application is here.

您还可以通读 官方 GSoC 学生/贡献者指南 ，了解有关准备提案的重要提示。

如果您想讨论项目提案或有疑问，请移步我们的 #gsoc-general Discord 频道！

引用​

• Electron 提案指南
• Electron GitHub
• 项目构想文件
• Google 代码之夏学生/贡献者指南

Electron 17.0.0 已发布！ 它包括升级到 Chromium 98, V8 9.8, 和 Node.js 16.13.0。 请阅读下文了解更多详情！

Electron 团队很高兴发布了 Electron 17.0.0.0！ 您可以通过 npm install electron@later 进行安装，或者从我们的 发布网站 下载它。 继续阅读有关此版本的详细信息，并请分享您的任何反馈！

Notable Changes​

Electron 发布时间变更​

As of Electron 15, Electron will release a new major stable version every 8 weeks. 您可以在此处阅读 完整详细信息。

Additionally, Electron has changed supported versions from latest three versions to latest four versions until May 2022. See our versioning document for more detailed information about versioning in Electron. After May 2022, we will return to supporting latest three versions.

Stack Changes​

• Chromium 98
  • New in Chrome 98
• Node.js 16.13.0
  • Node 16.13.0 blog post
• V8 9.8

Highlighted Features​

• Added webContents.getMediaSourceId(), can be used with getUserMedia to get a stream for a WebContents. #31204
• Deprecates webContents.getPrinters() and introduces webContents.getPrintersAsync(). #31023
• desktopCapturer.getSources is now only available in the main process. #30720

See the 17.0.0 release notes for a full list of new features and changes.

重大更改​

Below are breaking changes introduced in Electron 17. 有关这些和未来变化的更多信息可在 计划的突破性变化 页面找到。

desktopCapturer.getSources in the renderer​

The desktopCapturer.getSources API is now only available in the main process. This has been changed in order to improve the default security of Electron apps.

API 更改​

There were no API changes in Electron 17.

Removed/Deprecated Changes​

• Usage of the desktopCapturer.getSources API in the renderer has been removed. See here for details on how to replace this API in your app.

终止对 13.x.y 的支持​

Electron 13.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.

As of Electron 15, we have changed supported versions from latest three versions to latest four versions until May 2022 with Electron 19. 在 Electron 19 之后，我们将回归到支持最新的三个版本。 此版本支持变化是我们新的节奏变化的一部分。 请参阅 我们的博客文章 ，了解的完整详细信息。

What's Next​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is to release new major versions of Electron with new versions of those components approximately every 2 months.

您可以在此处找到 Electron的公开时间表。

有关这些和未来变化的更多信息可在 计划的突破性变化 页面找到。

Spectron 将于 2022 年 2 月 1 日弃用。

Beginning in February 2022, Spectron will be officially deprecated by the Electron team.

Why Deprecate Spectron?​

While Spectron has consistently put out new releases for each new version of Electron, the project has had very little maintenance and improvements for well over a year, and currently has no full-time maintainers. With the remote module moving outside of Electron core and into an external module in Electron 14, Spectron will require a major rewrite to continue working reliably.

After reviewing several available options for Spectron's continued maintenance, the Electron team has decided to deprecate Spectron in 2022.

Deprecation Timeline​

The following is our planned deprecation timeline:

• November 2021 - January 2022: The Electron team will continue to accept pull requests from the community.
• January 2022: A final version of announcement warning about Spectron's deprecation will be released.
• February 1, 2022: Spectron's repo will be marked as "archived". No more pull requests will be accepted.

Following February 1st, 2022, Electron will continue to leave the Spectron repo up indefinitely, so that others are welcome to fork or use the existing code for their projects. We hope this will help provide a longer transition to any projects that may still depend on Spectron.

Alternatives to Spectron​

如果您当前在项目中使用 Spectron，并希望迁移到替代测试解决方案，您可以在此处阅读我们的 自动化测试指南。

我们目前有其他几种推荐替代Spectron的办法，包括Playwright和WebDriverIO。 Official tutorials for each option can be found in our Automated Testing documentation.

What's Next​

We here on the Electron team appreciate you using Spectron and Electron. 我们理解，你们中的许多人都依赖 Spectron 来测试您的应用程序，我们希望让这种过渡尽可能轻松。 感谢您选择Electron！

Electron 16.0.0 已发布！ 它包括升级到 Chromium 96, V8 9.6, 和 Node.js 16.9.1。 请阅读下文了解更多详情！

Electron 团队很高兴发布了 Electron 16.0.0.0！ 您可以通过 npm install electron@later 进行安装，或者从我们的 发布网站 下载它。 继续阅读有关此版本的详细信息，并请分享您的任何反馈！

Notable Changes​

Electron 发布时间变更​

As of Electron 15, Electron will release a new major stable version every 8 weeks. 您可以在此处阅读 完整详细信息。

Additionally, Electron has changed supported versions from latest three versions to latest four versions until May 2022. See our versioning document for more detailed information about versioning in Electron. After May 2022, we will return to supporting latest three versions.

Stack Changes​

• Chromium 96
  • New in Chrome 96
• Node.js 16.9.1
  • Node 16.9.1 blog post
• V8 9.6
  • V8 9.6 blog post

Highlighted Features​

• Now supports the WebHID API. #30213
• Add data parameter to app.requestSingleInstanceLock to share data between instances. #30891
• Pass securityOrigin to media permissions request handler. #31357
• Add commandLine.removeSwitch. #30933

See the 16.0.0 release notes for a full list of new features and changes.

重大更改​

Below are breaking changes introduced in Electron 16. 有关这些和未来变化的更多信息可在 计划的突破性变化 页面找到。

Building Native Modules​

If your project uses node-gyp to build native modules, you may need to call it with --force-process-config depending on your project's setup and your Electron version. More information about this change can be found at #2497.

Behavior Changed: crashReporter implementation switched to Crashpad on Linux​

The underlying implementation of the crashReporter API on Linux has changed from Breakpad to Crashpad, bringing it in line with Windows and Mac. As a result of this, child processes are now automatically monitored, and calling process.crashReporter.start in Node child processes is no longer needed (and is not advisable, as it will start a second instance of the Crashpad reporter).

There are also some subtle changes to how annotations will be reported on Linux, including that long values will no longer be split between annotations appended with __1, __2 and so on, and instead will be truncated at the (new, longer) annotation value limit.

API 更改​

There were no API changes in Electron 16.

Removed/Deprecated Changes​

• Usage of the desktopCapturer.getSources API in the renderer has been deprecated and will be removed. This change improves the default security of Electron apps. See here for details on how to replace this API in your app.

End of Support for 12.x.y​

Electron 12.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.

As of Electron 15, we have changed supported versions from latest three versions to latest four versions until May 2022 with Electron 19. 在 Electron 19 之后，我们将回归到支持最新的三个版本。 此版本支持变化是我们新的节奏变化的一部分。 请参阅 我们的博客文章 ，了解的完整详细信息。

What's Next​

In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8. Although we are careful not to make promises about release dates, our plan is to release new major versions of Electron with new versions of those components approximately every 2 months.

您可以在此处找到 Electron的公开时间表。

有关这些和未来变化的更多信息可在 计划的突破性变化 页面找到。

The Electron project will pause for the month of December 2021, then return to full speed in January 2022.

via GIPHY

What will be the same in December​

1. Zero-day and other major security-related releases will be published as necessary. Security incidents should be reported via SECURITY.md.
2. Code of Conduct reports and moderation will continue.

What will be different in December​

1. No new Beta or Stable releases in December. No Nightly releases for the last two weeks of December.
2. With few exceptions, no pull request reviews or merges.
3. No issue tracker updates on any repositories.
4. No Discord debugging help from maintainers.
5. No social media content updates.

Why is this happening?​

In short, while maintainers are happy and engaged with the project, THE WORLD IS TIRED. December is a quiet month for most companies, so we want to give our maintainers a chance to recharge. We encourage other projects to consider similar measures.

Should I be worried about the future of Electron?​

否. We are able to take this step because the project is in good shape. Everyone is looking forward to 2022, and we expect good things to come!