我们很高兴地宣布 Electron Forge v6.0.0 现已发布！这是 Forge 自 2018 年以来的第一个主要版本，并将项目从 electron-userland 迁移到 Github 上的主要 electron 组织。

请继续阅读，了解有哪些新功能以及您的应用程序如何采用 Electron Forge！

什么是 Electron Forge？​

Electron Forge 是一个用于打包和分发 Electron 应用程序的工具。它将 Electron 的构建工具生态系统统一为一个可扩展的接口，以便任何人都可以立即开始制作 Electron 应用。

主要功能包括

• 📦 应用程序打包和代码签名
• 🚚 在 Windows、macOS 和 Linux 上的可定制安装程序（DMG、deb、MSI、PKG、AppX 等）
• ☁️ 针对云提供商（GitHub、S3、Bitbucket 等）的自动化发布流程
• ⚡️ 易于使用的 webpack 和 TypeScript 模板
• ⚙️ 支持原生 Node.js 模块
• 🔌 可扩展的 JavaScript 插件 API

v6 有哪些新功能？​

完全重写​

从 v1 到 v5，Electron Forge 基于现在已停产的 electron-compile 项目。Forge 6 是该项目的一次彻底重写，采用了新的模块化架构，可以进行扩展以满足任何 Electron 应用程序的需求。

在过去几年中，Forge v6.0.0-beta 已经实现了与 v5 的功能对等，并且代码变动已大幅减缓，使得该工具已准备好被广泛采用。

官方支持​

历史上，Electron 的维护者对构建工具一直持开放态度，将任务留给了各种社区包。然而，随着 Electron 项目的成熟，新 Electron 开发人员越来越难以理解他们需要哪些工具来构建和分发他们的应用程序。

为了帮助 Electron 开发者在分发过程中得到指导，我们决定将 Forge 作为 Electron 官方的、功能完备的构建流程。

在过去一年里，我们一直在缓慢地将 Forge 集成到官方 Electron 文档中，并且最近已将 Forge 从其旧的存放位置 electron-userland/electron-forge 迁移到了 electron/forge 仓库。现在，我们终于准备好向广大用户发布 Electron Forge 了！

入门​

初始化一个新的 Forge 项目​

可以使用 create-electron-app CLI 脚本来搭建一个新的 Electron Forge 项目。

yarn create electron-app my-app --template=webpack
cd my-app
yarn start

npm init electron-app@latest my-app -- --template=webpack
cd my-app
npm start

该脚本将在 my-app 文件夹中创建一个 Electron 项目，其中包含完整的 JavaScript 打包和预配置的构建流程。

更多信息，请参阅 Forge 文档中的入门指南。

导入现有项目​

Electron Forge CLI 还包含一个用于现有 Electron 项目的导入命令。

cd my-app
yarn add --dev @electron-forge/cli
yarn electron-forge import

cd my-app
npm install --save-dev @electron-forge/cli
npm exec --package=@electron-forge/cli -c "electron-forge import"

当您使用 import 命令时，Electron Forge 将添加一些核心依赖项并创建一个新的 forge.config.js 配置文件。如果您有任何现有的构建工具（例如 Electron Packager、Electron Builder 或 Forge 5），它将尝试迁移尽可能多的设置。您的一些现有配置可能需要手动迁移。

有关手动迁移的详细信息，请参阅 Forge 的 导入文档。如果您需要帮助，请加入我们的 Discord 服务器！

为什么要切换到 Forge？​

如果您已经有用于打包和发布 Electron 应用程序的工具，采用 Electron Forge 所带来的好处仍然可能超过初始的转换成本。

我们认为使用 Forge 有两大好处

1. Forge 在 Electron 支持新功能后会立即获得应用程序构建的新功能。在这种情况下，您无需自行配置新的工具支持，也无需等待其他包最终实现支持后再进行升级。最近的例子包括 macOS 通用二进制文件 和 ASAR 完整性检查。

2. Forge 的多包架构使其易于理解和扩展。由于 Forge 由许多具有清晰职责的小型包组成，因此更容易跟踪代码流。此外，Forge 的可扩展 API 设计意味着您可以编写自己的附加构建逻辑，并与提供的配置选项分开，以适应高级用例。有关编写自定义 Forge 插件、构建器和发布者的更多详细信息，请参阅文档的 扩展 Electron Forge 部分。

破坏性变更​

Forge 6 在测试阶段花费了很长时间，其发布节奏逐渐放缓。然而，我们在 2022 年下半年加快了开发速度，并利用了最近几次发布来推送一些最后的重大更改，以准备 v6.0.0 稳定版的发布。

如果您是 Electron Forge 6 的测试用户，请参阅 v6.0.0 的 GitHub 发布说明，了解最近测试版（>=6.0.0-beta.65）中进行的重大更改列表。

完整的更改和提交列表可以在仓库的 CHANGELOG.md 中找到。

提交您的反馈！​

告诉我们您的需求！Electron Forge 团队一直致力于改进项目，以更好地满足用户的需求。

您可以提交功能请求、发布 问题，或只是告诉我们您的反馈，来帮助我们改进 Electron Forge！您也可以加入我们的 官方 Electron Discord 服务器，其中有一个专门用于 Electron Forge 讨论的频道。

如果您想对 https://electronforge.cn 上的 Forge 文档提供任何反馈，我们有一个 GitBook 实例，它与 electron-forge/electron-forge-docs 仓库同步。

上个月，Electron 的维护者团队在加拿大温哥华会面，讨论了项目在 2023 年及以后的发展方向。在为期四天的会议中，核心维护者和受邀的贡献者们讨论了新举措、维护痛点以及项目的整体健康状况。

展望未来，团队仍将全力以赴地发布定期和快速的 Chromium 升级，修复 bug，并为所有人提供更安全、更高效的 Electron。我们还有一些令人兴奋的项目正在进行中，并希望与社区分享！

革命性的新 API​

Electron 项目中需要达成共识的主要 API 提案，会通过“征求意见”（RFC）流程，由我们的 API 工作组的成员进行审查。

今年，我们推动了两项可能为 Electron 应用解锁新维度能力的重大提案。这些提案仍是高度实验性的，但以下是我们对即将到来的内容的抢先预览！

新的原生插件增强（C API）​

该提案概述了一个新的 Electron C API 层，它将允许应用程序开发人员编写自己的原生 Node 插件，这些插件可以与 Electron 的内部资源进行交互，类似于 Node 自带的 Node-API。有关拟议新 API 的更多信息 可以在这里找到。

示例：使用 Chromium 资源为应用程序增添动力​

许多 Electron 应用程序维护自己的分支，以直接与 Chromium 内部进行交互，而这些交互通过标准的（未修改的）Electron 是无法实现的。通过在 C API 层公开这些资源，这些代码可以作为原生模块与 Electron 一起存在，从而可能减轻应用程序开发者的维护负担。

公开 Chromium 的 UI 层（Views API）​

在底层，Chrome 用户界面（UI）的非网站部分（如工具栏、标签页或按钮）是使用一个名为 Views 的框架构建的。Views API 提案将该框架的一部分作为 JavaScript 类引入 Electron，最终目标是允许开发人员为其 Electron 应用程序创建非 Web UI 元素。这将避免应用程序必须拼凑 Web 内容。

使这套新 API 成熟的基础工作正在进行中。以下是我们可以在不久的将来看到的一些首批成果。

示例：使用 WebContentsView 重构窗口模型​

我们计划的第一个更改是向 Electron 的 API 表面公开 Chrome 的 WebContentsView，它将是我们现有 BrowserView API 的后继者（尽管名称如此，BrowserView API 是与 Chromium Views 无关的 Electron 特定代码）。通过公开 WebContentsView，我们将拥有一个可重用的 View 对象，它可以显示 Web 内容，从而为使 BrowserWindow 类成为纯 JavaScript 并消除更多代码复杂性打开了大门。

虽然这个更改没有为应用开发者提供太多新功能，但它是一个大型重构，消除了大量的底层代码，简化了 Chromium 升级，并降低了主要版本之间出现新 bug 的风险。

如果您是 Electron 应用开发者，并且正在使用 BrowserViews：请放心，我们没有忘记您！我们计划将现有的 BrowserView 类变成 WebContentsView 的一个包装器，为您向较新的 API 过渡提供缓冲。

参见：electron/electron#35658

示例：使用 ScrollView 实现可滚动 Web 内容​

我们来自 Stack 的朋友一直在推动一项将 Chromium ScrollView 组件公开到 Electron API 的倡议。通过这个新的 API，任何子 View 组件都可以实现水平或垂直滚动。

虽然这个新 API 只实现了单一的小功能，但团队的最终目标是构建一套工具性的 View 组件，可以作为工具包来构建更复杂的非 HTML 界面。

如何参与​

您是对这两个 API 提案感兴趣的 Electron 应用开发者吗？虽然我们还没有准备好接收额外的 RFC，但请继续关注未来更多详情！

Electron Forge v6 稳定版发布​

自框架问世以来，Electron 的构建工具生态系统在很大程度上是社区驱动的，并由许多小型单功能包组成（例如 electron-winstaller、electron-packager、electron-notarize、electron-osx-sign）。虽然这些工具运行良好，但用户要拼凑一个有效的构建管道是很令人生畏的。

为了帮助为 Electron 开发人员构建更友好的体验，我们构建了 Electron Forge，这是一个一体化解决方案，将所有这些现有工具组合到一个统一的界面中。尽管 Forge 自 2017 年以来一直在开发中，但该项目在过去几年中一直处于休眠状态。然而，鉴于社区对 Electron 构建工具状态的反馈，我们一直在努力发布下一代 Forge 的稳定主要版本。

Electron Forge 6 提供了对 TypeScript 和 Webpack 的一流支持，以及一个可扩展的 API，允许开发者创建自己的插件和安装程序。

敬请期待：即将发布公告​

如果您有兴趣使用 Forge 构建项目，或者使用 Forge 的可扩展第三方 API 构建模板或插件，请在本月晚些时候关注我们关于 Forge v6 稳定版发布的官方公告！

下一步是什么？​

除上述内容外，团队还一直在考虑一系列探索性项目，以改善 Electron 对应用程序开发人员和最终用户的体验。更新器工具、API 审查流程和增强文档是我们正在尝试的其他内容。我们希望在不久的将来有更多消息与大家分享！

Electron 21.0.0 已发布！ 它包括升级到 Chromium 106、V8 10.6 和 Node.js 16.16.0。 阅读下文了解更多详情！

Electron 团队很高兴地宣布 Electron 21.0.0 的发布！您可以使用 npm 通过 npm install electron@latest 进行安装，或从我们的 发布网站 下载。继续阅读以获取有关此版本的详细信息。

如果您有任何反馈，请在 Twitter 上告诉我们，或加入我们的社区 Discord！错误和功能请求可以在 Electron 的 问题跟踪器 中报告。

重要变更​

技术栈变更​

• Chromium 106
  • Chrome 106 中的新功能
  • Chrome 105 中的新功能
  • DevTools 106 中的新功能
  • DevTools 105 中的新功能
• Node.js 16.16.0
  • Node 16.16.0 博客文章
• V8 10.6

新特性​

• 添加了 webFrameMain.origin。#35534
• 添加了新的 WebContents.ipc 和 WebFrameMain.ipc API。#35231
• 添加了对面板式行为的支持。 窗口可以浮动在全屏应用程序之上。#34388
• 添加了对 macOS 应用程序来自 APNs 的推送通知的支持。#33574

破坏性与 API 变更​

以下是 Electron 21 中引入的重大变更。

V8 内存笼已启用​

Electron 21 启用了 V8 沙盒指针，遵循 Chrome 在 Chrome 103 中做出相同决定。这会对原生模块产生一些影响。此功能具有性能和安全优势，但也对原生模块施加了一些新的限制，例如使用指向外部（“堆外”）内存的 ArrayBuffers。有关更多信息，请参阅 这篇博文。 #34724

重构了 webContents.printToPDF​

重构了 webContents.printToPDF 以与 Chromium 的无头实现保持一致。 有关更多信息，请参阅#33654。

有关这些和未来更改的更多信息，请访问计划中的重大更改页面。

停止支持 18.x.y​

根据项目 支持策略，Electron 18.x.y 已停止支持。鼓励开发人员和应用程序升级到新版 Electron。

下一步计划​

短期内，您可以预期团队将继续专注于跟进构成 Electron 的主要组件（包括 Chromium、Node 和 V8）的开发。

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

有关未来变更的更多信息，请参阅计划中的破坏性变更页面。

Electron 20.0.0 现已发布！此版本升级到了 Chromium 104、V8 10.4 和 Node.js 16.15.0。请阅读下文了解更多详情！

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

重要变更​

新特性​

• 在 Windows 上增加了沉浸式暗黑模式。#34549
• 增加了对类似面板行为的支持。窗口可以浮动在全屏应用程序之上。#34665
• 更新了 Windows 控件覆盖按钮，使其在 Windows 11 上的外观和感觉更原生。#34888
• 除非指定了 nodeIntegration: true 或 sandbox: false，否则渲染器现在默认是沙盒化的。#35125
• 在使用 nan 构建原生模块时增加了安全保障。#35160

技术栈变更​

• Chromium 104
  • Chrome 104 新特性
  • Chrome 103 新特性
  • DevTools 新特性
• Node.js 16.15.0
  • Node 16.15.0 博客文章
• V8 10.4

破坏性与 API 变更​

以下是 Electron 20 中引入的重大更改。有关这些更改和未来更改的更多信息，请访问 计划的重大更改 页面。

默认更改：不带 nodeIntegration: true 的渲染器默认处于沙盒模式​

以前，指定了预加载脚本的渲染器默认不处于沙盒模式。这意味着默认情况下，预加载脚本可以访问 Node.js。在 Electron 20 中，此默认设置已更改。从 Electron 20 开始，渲染器将默认处于沙盒模式，除非指定了 nodeIntegration: true 或 sandbox: false。

如果您的预加载脚本不依赖于 Node，则无需任何操作。如果您的预加载脚本确实依赖于 Node，那么要么重构它们以从渲染器中移除 Node 的使用，要么为相关渲染器明确指定 sandbox: false。

已修复：nan 原生模块中的意外崩溃​

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

1. V8 头文件现在默认使用 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 21 及更高版本将启用 V8 内存笼，这对一些原生模块有影响。

在 Electron 21 中，我们将启用 V8 沙盒指针，遵循 Chrome 在 Chrome 103 中做出相同决定。这会对原生模块产生一些影响。此外，我们之前在 Electron 14 中启用了相关技术 指针压缩。当时我们没有怎么谈论它，但指针压缩对 V8 的最大堆大小有影响。

这两种技术在启用后，在安全性、性能和内存使用方面都有显著的好处。然而，启用它们也有一些缺点。

启用沙盒指针的主要缺点是 **不再允许指向外部（“堆外”）内存的 ArrayBuffers**。这意味着依赖于 V8 中此功能的原生模块将需要重构才能在 Electron 20 及更高版本中继续工作。

启用指针压缩的主要缺点是 **V8 堆的最大大小限制为 4GB**。这其中的确切细节有点复杂—例如，ArrayBuffers 与 V8 堆的其余部分分开计算，但它们有 自己的限制。

Electron 升级工作组 认为 指针压缩和 V8 内存隔离区的优势大于劣势。主要有三个原因：

1. 它使 Electron 更接近 Chromium。Electron 在 V8 配置等复杂内部细节上与 Chromium 差异越小，我们意外引入 bug 或安全漏洞的可能性就越小。Chromium 的安全团队非常强大，我们希望确保我们利用他们的工作。此外，如果一个 bug 只影响 Chromium 中未使用的配置，那么修复它可能不是 Chromium 团队的优先事项。
2. 性能更好。 指针压缩可将 V8 堆大小减少高达 40%，并将 CPU 和 GC 性能提高 5%-10%。对于绝大多数不会遇到 4GB 堆大小限制且不使用需要外部缓冲区的原生模块的 Electron 应用程序来说，这些是显著的性能提升。
3. 更安全。一些 Electron 应用程序运行不受信任的 JavaScript（希望遵循我们的 安全建议！），对于这些应用程序，启用 V8 内存隔离区可以保护它们免受大量棘手的 V8 漏洞的侵害。

最后，对于确实需要更大堆大小的应用程序，存在变通方法。例如，可以随应用程序包含一个 Node.js 副本，该副本是禁用指针压缩构建的，并将内存密集型工作移至子进程。尽管有些复杂，但如果您决定为您的特定用例选择不同的权衡，也可以构建一个自定义的 Electron 版本，禁用指针压缩。最后，在不久的将来，wasm64 将允许在 Web 和 Electron 中构建的 WebAssembly 应用程序使用超过 4GB 的内存。

常见问题解答​

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

尝试使用 ArrayBuffer 包装外部内存将在 Electron 20+ 中导致运行时崩溃。

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

如何衡量我的应用程序使用了多少 V8 堆内存，以便知道我是否接近 4GB 限制？​

在渲染器进程中，您可以使用 performance.memory.usedJSHeapSize，它将以字节为单位返回 V8 堆使用量。在主进程中，您可以使用 process.memoryUsage().heapUsed，这与前者是可比的。

什么是 V8 内存笼？​

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

有一种相当常见的 V8 漏洞利用方式，大致如下：

1. 在 V8 的 JIT 引擎中找到一个 bug。JIT 引擎分析代码，以便能够省略缓慢的运行时类型检查并生成快速的机器代码。有时逻辑错误会导致分析错误，省略了实际需要的类型检查—例如，它认为 x 是一个字符串，但实际上它是一个对象。
2. 利用这种混淆来覆盖 V8 堆中的某些内存位，例如 ArrayBuffer 开始位置的指针。
3. 现在您拥有一个指向任意位置的 ArrayBuffer，因此您可以读取和写入进程中的任何内存，即使是 V8 通常无法访问的内存。

V8 内存隔离区是一种旨在从根本上阻止此类攻击的技术。实现这一点的方法是 *不在 V8 堆中存储任何指针*。相反，所有指向 V8 堆内部其他内存的引用都存储为相对于某个保留区域开头的偏移量。然后，即使攻击者设法损坏 ArrayBuffer 的基地址，例如通过利用 V8 中的类型混淆错误，他们最多也只能在内存隔离区内读取和写入内存，而这些内存他们很可能已经可以访问了。关于 V8 内存隔离区如何工作，还有更多内容可供阅读，因此我在这里不再详细介绍—最好的阅读起点可能是 Chromium 团队的 高层设计文档。

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

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

为了使这一点更具体，这里有一个使用外部 ArrayBuffer 的 N-API 模块示例

// Create some externally-allocated buffer.
// |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 通过 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 构造函数选项 skipTaskbar 在 Linux 上已不再支持。 变更于 #33226

移除了 WebPreferences.preloadURL​

WebPreferences 中半公开的 preloadURL 属性已被移除。有关如何替换此 API 的详细信息，请参阅 此处。应使用 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 正在更改其主要的 S3 存储桶，您可能需要更新您的构建脚本

发生了什么？

Electron 的大量构建产物都上传到了一个名为 gh-contractor-zcbenz 的 S3 存储桶中。作为自 2020 年开始的持续基础设施/所有权迁移的一部分，我们将把所有使用 gh-contractor-zcbenz 的内容从 S3 的旧位置迁移到一个新的存储系统，托管在 https://artifacts.electronjs.org。我们大多数资产使用的路径前缀也有轻微变化。示例如下：

之前： https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/dist/v17.0.0/node.lib 之后： https://artifacts.electronjs.org/headers/dist/v17.0.0/node.lib

这里重要的是 **主机名** 发生了变化，并且 /atom-shell **前缀** 也发生了变化。另一个例子，这次是关于调试符号

之前： https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/symbols/path/to/symbol.pdb 之后： https://artifacts.electronjs.org/symbols/path/to/symbol.pdb

同样，主机名发生了变化，并且 /atom-shell 前缀也被更改了。

这可能会如何影响您？

任何使用标准构建工具（如 electron-rebuild、electron-packager 或 @electron/get）的人都不需要做任何事情。这应该占大多数人。

对于任何直接引用 S3 存储桶的人，您必须更新您的引用，使其指向新的主机名并更新路径。

现有的数据怎么样？

gh-contractor-zcbenz 存储桶中存在的大部分数据已被克隆到新的存储系统中。这意味着所有调试符号和所有头文件都已复制。如果您依赖于该存储桶中未复制的任何数据，请在 electron/electron 中提出问题并告知我们。

当前的 gh-contractor-zcbenz S3 存储桶不会被主动删除。但是，我们不能保证该存储桶将保留多长时间。我们 **强烈** 建议尽快更新以指向新的存储桶。

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

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

重要变更​

Electron 发布节奏变更​

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

此外，Electron 的支持版本已从最新的三个版本更改为最新的四个版本，直到 2022 年 5 月。有关 Electron 版本控制的更详细信息，请参阅 我们的版本控制文档。2022 年 5 月之后，我们将恢复支持最新的三个版本。

技术栈变更​

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

亮点功能​

• 添加了 ses.setCodeCachePath() API 用于设置代码缓存目录。#33286
• 移除了 window.open 的旧 BrowserWindowProxy 实现。这也移除了 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 的更多详细信息，请参阅 文档。在 #29405 中移除。

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

根据项目 支持策略，Electron 14.x.y 已停止支持。鼓励开发人员和应用程序升级到新版 Electron。

作为 Electron 15，我们将支持版本从最新的三个版本更改为最新的四个版本，直到 2022 年 5 月的 Electron 19。在 Electron 19 之后，我们将恢复支持最新的三个版本。此版本支持更改是我们新发布节奏的一部分。有关完整详细信息，请参阅 我们的博文。

下一步计划​

短期内，您可以预期团队将继续专注于跟上构成 Electron 的主要组件（包括 Chromium、Node 和 V8）的开发。虽然我们很谨慎，不会承诺发布日期，但我们的计划是大约每 2 个月发布新版 Electron，其中包含这些组件的新版本。

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

有关未来变更的更多信息，请参阅计划中的破坏性变更页面。

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

什么是 Google Summer of Code？​

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

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

我该如何报名？​

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

要被选为 Google Summer of Code 的 Electron 贡献者，您需要提交申请。申请将于 **2022 年 4 月 4 日** 开始，并于 **2022 年 4 月 19 日** 结束。您可以在 此处 关注 Google：Summer of Code 申请指南的更新。

想申请吗？首先，请查看我们准备的 五个项目构想草案。所有列出的构想当前都对提案开放。我们也乐于接受不在提议项目列表中的新构想。

您的申请应包括：

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

此处提供了关于提交 Electron 申请内容的详细指南。

您还可以阅读官方 GSoC 学生/贡献者指南，以获取准备提案的重要提示。

如果您想讨论项目提案或有任何问题，欢迎来我们的 #gsoc-general Discord 频道！

参考资料​

• Electron 提案指南
• Electron GitHub
• 项目想法文档
• Google Summer of Code 学生/贡献者指南

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

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

重要变更​

Electron 发布节奏变更​

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

此外，Electron 的支持版本已从最新的三个版本更改为最新的四个版本，直到 2022 年 5 月。有关 Electron 版本控制的更详细信息，请参阅 我们的版本控制文档。2022 年 5 月之后，我们将恢复支持最新的三个版本。

技术栈变更​

• Chromium 98
  • Chrome 98 新增功能
• Node.js 16.13.0
  • Node 16.13.0 博客文章
• V8 9.8

亮点功能​

• 添加了 webContents.getMediaSourceId()，可与 getUserMedia 一起使用，为 WebContents 获取流。 #31204
• 弃用 webContents.getPrinters() 并引入 webContents.getPrintersAsync()。 #31023
• desktopCapturer.getSources 现在仅在主进程中可用。 #30720

请参阅 17.0.0 发布说明 以获取新功能和更改的完整列表。

破坏性变更​

以下是 Electron 17 中引入的重大更改。有关这些更改和未来更改的更多信息，请访问 计划的重大更改 页面。

渲染器中的 desktopCapturer.getSources​

desktopCapturer.getSources API 现在仅在主进程中可用。此更改是为了提高 Electron 应用程序的默认安全性。

API 更改​

Electron 17 中没有 API 更改。

移除/弃用的变更​

• 已从渲染器中移除 desktopCapturer.getSources API 的使用。有关如何在应用程序中替换此 API 的详细信息，请参阅 此处。

13.x.y 版本支持结束​

根据项目 支持策略，Electron 13.x.y 已停止支持。鼓励开发人员和应用程序升级到新版 Electron。

作为 Electron 15，我们将支持版本从最新的三个版本更改为最新的四个版本，直到 2022 年 5 月的 Electron 19。在 Electron 19 之后，我们将恢复支持最新的三个版本。此版本支持更改是我们新发布节奏的一部分。有关完整详细信息，请参阅 我们的博文。

下一步计划​

短期内，您可以预期团队将继续专注于跟上构成 Electron 的主要组件（包括 Chromium、Node 和 V8）的开发。虽然我们很谨慎，不会承诺发布日期，但我们的计划是大约每 2 个月发布新版 Electron，其中包含这些组件的新版本。

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

有关未来变更的更多信息，请参阅计划中的破坏性变更页面。