我们很高兴地宣布 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 插件、maker 和发布者的更多详细信息，请参见文档的 扩展 Electron Forge 部分。

重大更改​

Forge 6 在 beta 阶段花费了很长时间，其发布节奏逐渐放缓。 但是，我们在 2022 年下半年加快了开发速度，并使用最近的几个版本在 v6.0.0 稳定版发布之前推送了一些最终的重大更改。

如果您是 Electron Forge 6 beta 用户，请参见 v6.0.0 GitHub 版本说明，以获取在最近的 beta 版本（>=6.0.0-beta.65）中所做的重大更改的列表。

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

提交您的反馈！​

告诉我们您需要什么！ Electron Forge 团队一直在努力构建项目，以更好地满足其用户的需求。

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

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

上个月，Electron 的维护者小组在加拿大温哥华会面，讨论了该项目 2023 年及以后的方向。 在会议室的四天中，核心维护者和受邀的协作者讨论了新计划、维护难点和总体项目健康状况。

展望未来，该团队仍将全力致力于发布定期和快速的 Chromium 升级、修复错误并使 Electron 对每个人都更加安全和高效。 我们还在进行一些令人兴奋的项目，我们很乐意与社区分享！

变革性的新 API​

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

今年，我们推进了两项主要提案，这些提案有可能为 Electron 应用程序释放新的功能维度。 这些提案具有高度实验性，但这是对未来发展的先睹为快！

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

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

示例：使用 Chromium 资源增强应用程序​

许多 Electron 应用程序维护自己的 fork，以直接与 Chromium 内部组件交互，否则这些内部组件将无法通过 vanilla（未修改）Electron 访问。 通过在 C API 层中公开这些资源，此代码可以改为作为原生模块与 Electron 一起存在，从而可能减轻应用程序开发人员的维护负担。

公开 Chromium 的 UI 层（Views API）​

在底层，Chrome 用户界面（UI）的非网站部分（例如工具栏、选项卡或按钮）是使用名为 Views 的框架构建的。 Views API 提案将此框架的部分内容作为 Electron 中的 JavaScript 类引入，最终目的是允许开发人员创建非 Web UI 元素到他们的 Electron 应用程序。 这将防止应用程序必须拼凑 Web 内容。

使这组新 API 成为可能的基础工作目前正在进行中。 这是您在不久的将来可以期望看到的一些首批内容。

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

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

尽管此更改并未向应用程序开发人员提供许多新功能，但它是一个大型重构，可以消除底层的许多代码，从而简化 Chromium 升级并降低主要版本之间出现新错误的风险。

如果您是在应用程序中使用 BrowserViews 的 Electron 开发人员：请不要担心，我们没有忘记您！ 我们计划使现有的 BrowserView 类成为 WebContentsView 的 shim，以便在您过渡到较新的 API 时提供一个缓冲区。

请参阅：electron/electron#35658

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

我们在 Stack 的朋友一直在推动将 Chromium ScrollView 组件公开到 Electron 的 API。 借助此新 API，可以水平或垂直滚动任何子 View 组件。

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

参与方式​

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

Electron Forge v6 稳定版发布​

自从 Electron 框架诞生以来，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
• 增加了对来自 APNs 的 macOS 应用程序的推送通知的支持。 #33574

重大更改 & API 更改​

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

V8 内存笼已启用​

Electron 21 启用了 V8 沙盒指针，这遵循了 Chrome 在 Chrome 103 中也这样做 的决定。 这对原生模块有一些影响。 此功能具有性能和安全优势，但也对原生模块施加了一些新的限制，例如使用指向外部（“堆外”）内存的 ArrayBuffer。 请参阅 此博客文章 以获取更多信息。 #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 的渲染器默认情况下是沙盒化的​

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

如果您的 preload 脚本不依赖于 Node，则无需执行任何操作。 如果您的 preload 脚本确实依赖于 Node，请重构它们以从渲染器中删除 Node 使用，或者为相关渲染器显式指定 sandbox: false。

已修复：nan 原生模块中的自发崩溃​

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

1. V8 标头现在默认使用 c++17。 此标志已添加到 electron-rebuild 中。
2. 我们修复了一个问题，即缺少包含会导致依赖于 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 中，我们将启用 Electron 中的 V8 沙盒指针，这遵循了 Chrome 在 Chrome 103 中也这样做 的决定。 这对原生模块有一些影响。 此外，我们之前在 Electron 14 中启用了一项相关技术，指针压缩。 我们当时没有过多讨论它，但是指针压缩对 V8 堆的最大大小有影响。

当启用时，这两种技术对安全性、性能和内存使用都有显著的好处。 但是，启用它们也有一些缺点。

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

启用指针压缩的主要缺点是 V8 堆的最大大小限制为 4GB。 这方面的确切细节有点复杂——例如，ArrayBuffer 与 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 将允许使用 WebAssembly 构建的应用程序在 Web 和 Electron 上使用明显超过 4GB 的内存。

常见问题解答​

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

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

如果您在应用程序中不使用任何原生 Node 模块，那么您是安全的——无法从纯 JS 触发此崩溃。 此更改仅影响在 V8 堆之外分配内存（例如，使用 malloc 或 new）然后使用 ArrayBuffer 包装外部内存的原生 Node 模块。 这是一个相当罕见的用例，但一些模块确实使用了这种技术，并且需要重构此类模块才能与 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 21+。 我该怎么做？​

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

为了使这更具体，这是一个使用外部数组缓冲区的 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​

半公开的 preloadURL 属性已从 WebPreferences 中删除。#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 正在更改其主要的 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

这里重要的是 Hostname 发生了变化，并且 /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
• 删除了基于 BrowserWindowProxy 的旧 window.open 实现。 这也从 webPreferences 中删除了 nativeWindowOpen 选项。#29405
• 将“focus”和“blur”事件添加到 WebContents。#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 中引入的重大更改。有关这些以及未来更改的更多信息，请访问计划的重大更改页面。

renderer 中的 desktopCapturer.getSources​

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

API 更改​

Electron 17 中没有 API 更改。

已删除/已弃用的更改​

• 已删除 renderer 中 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 的公共时间表。

有关未来更改的更多信息，请参见 计划重大更改 页面。