回顾 2023 年 Electron 开发者生态系统的改进和变化。

在过去的几个月里，我们一直在 Electron 生态系统中酝酿一些变化，以增强 Electron 应用程序的开发者体验！以下是来自 Electron 总部的最新补充内容的快速概要。

Electron Forge 7 及未来版本​

Electron Forge 7——我们用于打包和分发 Electron 应用程序的一体化工具的最新主版本——现已发布。

虽然 Forge 6 是对 v5 的完全重写，但 v7 的范围更小，但仍包含一些破坏性变更。未来，我们将继续在需要进行破坏性变更时发布 Forge 的主版本。

更多详情，请查看 GitHub 上的完整 Forge v7.0.0 更新日志。

破坏性变更​

• 切换到使用 notarytool 进行 macOS 公证： 自 2023-11-01 起，Apple 停用了用于 macOS 公证的旧版 altool，此版本将其从 Electron Forge 中完全移除。
• 最低 Node.js 版本提升至 v16.4.0： 在此版本中，我们将最低要求的 Node.js 版本设置为 16.4.0。
• 停止支持 electron-prebuilt 和 electron-prebuilt-compile：electron-prebuilt 是 Electron npm 模块的原始名称，但在 v1.3.1 中被 electron 取代。electron-prebuilt-compile 是该二进制文件的替代方案，具有增强的 DX 功能，但最终被废弃为一个项目。

亮点​

• Google Cloud Storage 发布者：作为我们为更好地支持静态自动更新所做的努力的一部分，Electron Forge 现在支持直接发布到 Google Cloud Storage！
• ESM forge.config.js 支持：Electron Forge 现在支持 ESM forge.config.js 文件。（附注：敬请期待 Electron 28 中的 ESM 入口点支持。）
• Makers 现在并行运行：在 Electron Forge 6 中，Makers 出于 ✨ 遗留 ✨ 原因按顺序运行。此后，我们已经测试了 Make 步骤的并行化，没有产生不利影响，因此在为同一平台构建多个目标时，您应该会看到速度提升！

更好的静态存储自动更新​

Squirrel.Windows 和 Squirrel.Mac 是支持 Electron 内置 autoUpdater 模块的平台特定更新技术。这两个项目都通过两种方法支持自动更新

• 一个兼容 Squirrel 的更新服务器
• 一个托管在静态存储提供商（例如 AWS、Google Cloud Platform、Microsoft Azure 等）上的清单 URL

传统上，更新服务器方法一直是 Electron 应用程序的推荐方法（并提供更新逻辑的额外自定义），但它有一个主要缺点——如果应用程序是闭源的，它需要应用程序维护自己的服务器实例。

另一方面，静态存储方法一直都是可行的，但在 Electron 内部没有文档记录，并且在 Electron 的工具包中支持不佳。

在 @MarshallOfSound 的出色工作下，无服务器自动应用更新的流程得到了极大的简化

• Electron Forge 的 Zip 和 Squirrel.Windows maker 现在可以配置为输出与 autoUpdater 兼容的更新清单。
• update-electron-app 的新主版本（v2.0.0）现在可以读取这些生成的清单，作为 update.electronjs.org 服务器的替代方案。

一旦你的 Makers 和 Publishers 配置为将更新清单上传到云文件存储，你只需几行配置即可启用自动更新

const { updateElectronApp, UpdateSourceType } = require('update-electron-app');

updateElectronApp({
  updateSource: {
    type: UpdateSourceType.StaticStorage,
    baseUrl: `https://my-manifest.url/${process.platform}/${process.arch}`,
  },
});

@electron/ 扩展宇宙​

当 Electron 最初推出时，社区发布了许多用于增强 Electron 应用程序的开发、打包和分发体验的软件包。随着时间的推移，其中许多软件包被整合到 Electron 的 GitHub 组织中，核心团队承担了维护负担。

2022 年，我们开始将所有这些第一方工具统一在 npm 上的 @electron/ 命名空间下。此更改意味着以前是 electron-foo 的软件包现在在 npm 上是 @electron/foo，以前命名为 electron/electron-foo 的存储库现在在 GitHub 上是 electron/foo。这些更改有助于清晰地区分第一方项目和用户项目。这包括许多常用的软件包，例如

• @electron/asar
• @electron/fuses
• @electron/get
• @electron/notarize
• @electron/osx-sign
• @electron/packager
• @electron/rebuild
• @electron/remote
• @electron/symbolicate-mac
• @electron/universal

未来，我们发布的所有第一方包也将在 @electron/ 命名空间下。此规则有两个例外

• Electron 核心将继续在 electron 包下发布。
• Electron Forge 将继续将其所有 monorepo 包发布在 @electron-forge/ 命名空间下。

介绍 @electron/windows-sign​

从 2023-06-01 开始，行业标准开始要求将 Windows 代码签名证书的密钥存储在符合 FIPS 标准的硬件上。

实际上，这意味着对于在 CI 环境中构建和签名的应用程序来说，代码签名变得更加困难，因为许多 Electron 工具将证书文件和密码作为配置参数，并尝试使用硬编码逻辑进行签名。

这种情况一直是 Electron 开发者的一个常见痛点，这就是为什么我们一直在努力开发一个更好的解决方案，将 Windows 代码签名隔离成一个独立的步骤，类似于 @electron/osx-sign 在 macOS 上的做法。

未来，我们计划将此软件包完全集成到 Electron Forge 工具链中，但目前它独立存在。该软件包目前可以通过 npm install --save-dev @electron/windows-sign 进行安装，并且可以以编程方式或通过 CLI 使用。

请试用它，并在仓库的问题跟踪器中给我们反馈！

下一步是什么？​

下个月我们将进入我们年度的十二月静默期。在此期间，我们将思考如何在 2024 年让 Electron 的开发体验变得更好。

你希望我们接下来做些什么吗？告诉我们吧！

Electron 项目将在 2023 年 12 月暂停，并于 2024 年 1 月恢复全面开发。

来自 GIPHY

12 月份保持不变的事项​

1. 零日漏洞和其他与主要安全相关的版本将根据需要发布。安全事件应通过 SECURITY.md 报告。
2. 行为准则的报告和管理工作将继续进行。

12 月份会有所不同的事项​

1. Electron 28.0.0 将于 12 月 5 日发布。在 Electron 28 之后，12 月将不再有新的稳定版发布。
2. 12 月的最后两周将不会有 Nightly 和 Alpha 版本发布。
3. 除少数例外情况外，不会进行 Pull Request 的审查或合并。
4. 任何代码仓库的 Issue Tracker 都不会有更新。
5. 维护者不会在 Discord 上提供调试帮助。
6. 社交媒体内容将暂停更新。

未来计划​

这是我们第三年尝试静默期实验，到目前为止，我们已成功地平衡了一个月的休息时间和之后保持正常发布节奏的需求。因此，我们决定将其作为我们发布日历的常规组成部分。我们仍会在每个日历年的最后一个稳定版本中添加提醒。

2024 年再见！

Electron 27.0.0 现已发布！ 它包括对 Chromium 118.0.5993.32、V8 11.8 和 Node.js 18.17.1 的升级。

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

如果您有任何反馈，请在 Twitter 或 Mastodon 上与我们分享，或者加入我们的社区 Discord！Bug 和功能请求可以在 Electron 的问题追踪器中报告。

重要变更​

技术栈变更​

• Chromium 118.0.5993.32
  • Chrome 118 的新功能
  • DevTools 118 的新功能
• Node.js 18.17.1
  • Node 18.17.1 博客文章
  • Node 18.17.0 博客文章
• V8 11.8

破坏性变更​

已移除：对 macOS 10.13 / 10.14 的支持​

Chromium 不再支持 macOS 10.13 (High Sierra) 和 macOS 10.14 (Mojave)。

旧版本的 Electron 将继续在这些操作系统上运行，但运行 Electron v27.0.0 及更高版本将需要 macOS 10.15 (Catalina) 或更高版本。

已弃用：ipcRenderer.sendTo()​

ipcRenderer.sendTo() API 已被弃用。 它应该被替换为在渲染器之间设置一个 MessageChannel。

IpcRendererEvent 的 senderId 和 senderIsMainFrame 属性也已被弃用。

已移除：systemPreferences 中的配色方案事件​

以下 systemPreferences 事件已被移除：

• inverted-color-scheme-changed
• high-contrast-color-scheme-changed

请改用 nativeTheme 模块上新的 updated 事件。

// Removed
systemPreferences.on('inverted-color-scheme-changed', () => {
  /* ... */
});
systemPreferences.on('high-contrast-color-scheme-changed', () => {
  /* ... */
});

// Replace with
nativeTheme.on('updated', () => {
  /* ... */
});

已移除：webContents.getPrinters​

webContents.getPrinters 方法已被移除。 请改用 webContents.getPrintersAsync。

const w = new BrowserWindow({ show: false });

// Removed
console.log(w.webContents.getPrinters());
// Replace with
w.webContents.getPrintersAsync().then((printers) => {
  console.log(printers);
});

已移除：systemPreferences.{get,set}AppLevelAppearance 和 systemPreferences.appLevelAppearance​

systemPreferences.getAppLevelAppearance 和 systemPreferences.setAppLevelAppearance 方法以及 systemPreferences.appLevelAppearance 属性已移除。 请改用 nativeTheme 模块。

// Removed
systemPreferences.getAppLevelAppearance();
// Replace with
nativeTheme.shouldUseDarkColors;

// Removed
systemPreferences.appLevelAppearance;
// Replace with
nativeTheme.shouldUseDarkColors;

// Removed
systemPreferences.setAppLevelAppearance('dark');
// Replace with
nativeTheme.themeSource = 'dark';

已移除：systemPreferences.getColor 的 alternate-selected-control-text 值​

systemPreferences.getColor 的 alternate-selected-control-text 值已被移除。 请改用 selected-content-background。

// Removed
systemPreferences.getColor('alternate-selected-control-text');
// Replace with
systemPreferences.getColor('selected-content-background');

新特性​

• 添加了应用无障碍透明度设置 API #39631
• 添加了对 chrome.scripting 扩展 API 的支持 #39675
• 默认启用了 WaylandWindowDecorations #39644

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

根据项目的支持策略，Electron 24.x.y 已达到支持结束。 建议开发者和应用程序升级到较新版本的 Electron。

终止对 22.x.y 的扩展支持​

今年早些时候，Electron 团队将 Electron 22 的计划终止日期从 2023 年 5 月 30 日延长至 2023 年 10 月 10 日，以配合 Chrome 对 Windows 7/8/8.1 的扩展支持（详情请参阅告别，Windows 7/8/8.1）。

根据项目的支持策略和本次支持扩展，Electron 22.x.y 已达到支持结束。 这将把支持回退到最新的三个稳定主版本，并将结束对 Windows 7/8/8.1 的官方支持。

下一步计划​

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

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

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

自 CVE-2023-4863：WebP 中的堆缓冲区溢出 公开以来已过去一周多，这促使渲染 webp 图像的软件纷纷发布新版本：macOS、iOS、Chrome、Firefox 和各种 Linux 发行版都收到了更新。此前，Citizen Lab 的调查发现，一个“位于华盛顿特区的公民社会组织”使用的 iPhone 正在遭受 iMessage 中的零点击漏洞攻击。

Electron 也迅速行动起来，并在当天发布了新版本：如果您的应用程序渲染任何用户提供的​​内容，则应更新您的 Electron 版本 - v27.0.0-beta.2、v26.2.1、v25.8.1、v24.8.3 和 v22.3.24 都包含已修复的 libwebp 版本，这是负责渲染 webp 图像的库。

现在我们都清楚，“渲染图像”这样看似无害的操作也可能带来危险，我们想借此机会提醒大家，Electron 提供了一个进程沙盒，可以限制下一次重大攻击（无论是什么）的波及范围。

沙盒自 Electron v1 版本起就已存在，并在 v20 版本中默认启用。但我们知道，许多应用程序（尤其是那些已存在一段时间的应用程序）可能在其代码中的某个地方设置了 sandbox: false，或者设置了 nodeIntegration: true，当没有明确的 sandbox 设置时，后者同样会禁用沙盒。这是可以理解的：如果您与我们同行已久，您可能享受过将 require("child_process") 或 require("fs") 放入运行 HTML/CSS 的同一代码中的强大功能。

在我们讨论如何迁移到沙箱之前，让我们先讨论一下你为什么需要它。

沙盒为所有渲染器进程提供了严格的限制，确保无论内部发生什么，代码都在受限的环境中执行。作为一个概念，它比 Chromium 早得多，并且是所有主流操作系统提供的功能。Electron 和 Chromium 的沙盒都建立在这些系统功能之上。即使您从不显示用户生成的内容，也应考虑您的渲染器可能被破坏的可能性：像供应链攻击这样复杂的场景，以及像小 bug 这样简单的错误，都可能导致您的渲染器执行您并未完全打算让它执行的操作。

沙盒使这种情况不那么可怕：内部进程可以自由使用 CPU 周期和内存——仅此而已。进程无法写入磁盘或显示自己的窗口。在我们的 libwep 漏洞案例中，沙盒确保攻击者无法安装或运行恶意软件。事实上，在最初针对该员工 iPhone 的 Pegasus 攻击案例中，攻击者专门针对一个非沙盒化的图像进程来获取手机的访问权限，首先突破了通常被沙盒化的 iMessage 的边界。当出现像本例中的 CVE 时，您仍然需要将您的 Electron 应用程序升级到安全版本——但在此期间，攻击者造成的损害将大大减少。

将一个标准的 Electron 应用程序从 sandbox: false 迁移到 sandbox: true 是一项艰巨的任务。我知道，因为尽管我个人撰写了 Electron 安全指南 的初稿，但我自己还没有成功地迁移我的一个应用程序来使用它。本周末情况发生了变化，我建议您也这样做。

你需要解决两个问题

1. 如果您在 preload 脚本或实际的 WebContents 中使用 Node.js 代码，您需要将所有 Node.js 交互移至主进程（或，如果您喜欢，迁移到一个辅助进程）。考虑到渲染器已变得多么强大，您的绝大多数代码可能实际上不需要重构。

   请参阅我们关于 进程间通信 的文档。就我个人而言，我迁移了大量代码，并使用 ipcRenderer.invoke() 和 ipcMain.handle() 进行包装，但这个过程很简单，而且很快就完成了。在这里，要注意您的 API——如果您构建了一个名为 executeCodeAsRoot(code) 的 API，沙盒将无法很好地保护您的用户。

2. 由于启用沙箱会禁用预加载脚本中的 Node.js 集成，因此你无法再使用 require("../my-script")。换句话说，你的预加载脚本需要是单个文件。

   有多种方法可以做到这一点：Webpack、esbuild、parcel 和 rollup 都可以完成这项工作。我使用了 Electron Forge 出色的 Webpack 插件，同样流行的 electron-builder 用户可以使用 electron-webpack。

总而言之，整个过程花费了我大约四天时间——这还包括了我为了用各种方式重构我的代码而对如何驾驭 Webpack 的强大功能感到困惑的时间。

Electron 26.0.0 现已发布！ 它包括对 Chromium 116.0.5845.62、V8 11.2 和 Node.js 18.16.1 的升级。 请继续阅读以获取更多详细信息！

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

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

重要变更​

技术栈变更​

• Chromium 116.0.5845.62
  • Chrome 116 的新功能
  • DevTools 116 的新功能
• Node.js 18.16.1
  • Node 18.16.1 博客文章
• V8 11.2

破坏性变更​

已废弃：webContents.getPrinters​

webContents.getPrinters 方法已被废弃。 请改用 webContents.getPrintersAsync。

const w = new BrowserWindow({ show: false });

// Deprecated
console.log(w.webContents.getPrinters());
// Replace with
w.webContents.getPrintersAsync().then((printers) => {
  console.log(printers);
});

已弃用：systemPreferences.{get,set}AppLevelAppearance 和 systemPreferences.appLevelAppearance​

systemPreferences.getAppLevelAppearance 和 systemPreferences.setAppLevelAppearance 方法以及 systemPreferences.appLevelAppearance 属性已被弃用。请改用 nativeTheme 模块。

// Deprecated
systemPreferences.getAppLevelAppearance();
// Replace with
nativeTheme.shouldUseDarkColors;

// Deprecated
systemPreferences.appLevelAppearance;
// Replace with
nativeTheme.shouldUseDarkColors;

// Deprecated
systemPreferences.setAppLevelAppearance('dark');
// Replace with
nativeTheme.themeSource = 'dark';

已弃用：systemPreferences.getColor 的 alternate-selected-control-text 值​

systemPreferences.getColor 的 alternate-selected-control-text 值已被废弃。 请改用 selected-content-background。

// Deprecated
systemPreferences.getColor('alternate-selected-control-text');
// Replace with
systemPreferences.getColor('selected-content-background');

新特性​

• 添加了 safeStorage.setUsePlainTextEncryption 和 safeStorage.getSelectedStorageBackend API。 #39107
• 添加了 safeStorage.setUsePlainTextEncryption 和 safeStorage.getSelectedStorageBackend API。 #39155
• 为通过 ipcRenderer.sendTo() 发送的消息添加了 senderIsMainFrame。 #39206
• 增加了对将菜单标记为由键盘启动的支持。 #38954

停止对 23.x.y 的支持​

根据项目的支持策略，Electron 23.x.y 已结束支持。鼓励开发者和应用程序升级到更新版本的 Electron。

下一步计划​

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

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

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

Electron 25.0.0 已经发布！ 它包括对 Chromium 114、V8 11.4 和 Node.js 18.15.0 的升级。 请继续阅读以了解更多详情！

Electron 团队很高兴地宣布 Electron 25.0.0 的发布！您可以通过 npm install electron@latest 使用 npm 进行安装，或从我们的 发布网站 下载。请继续阅读以了解此次发布详情。

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

重要变更​

亮点​

• 在 Electron 的 net 模块中实现了 net.fetch，使用了 Chromium 的网络堆栈。这与 Node 的 fetch() 不同，Node 的 fetch() 使用的是 Node.js 的 HTTP 堆栈。请参阅 #36733 和 #36606。
• 添加了 protocol.handle，该方法将替换并弃用 protocol.{register,intercept}{String,Buffer,Stream,Http,File}Protocol。 #36674
• 扩展了对 Electron 22 的支持，以匹配 Chromium 和微软对 Windows 7/8/8.1 的废弃计划。 请参阅本篇博文末尾的更多细节。

技术栈变更​

• Chromium 114
  • Chrome 114 新特性
  • Chrome 113 新特性
  • DevTools 114 新特性
  • DevTools 113 新特性
• Node.js 18.15.0
  • Node 18.15.0 博文
• V8 11.4

破坏性变更​

已弃用：protocol.{register,intercept}{Buffer,String,Stream,File,Http}Protocol​

protocol.register*Protocol 和 protocol.intercept*Protocol 方法已被 protocol.handle 替代。

新方法既可以注册一个新协议，也可以拦截一个现有协议，并且响应可以是任何类型。

// Deprecated in Electron 25
protocol.registerBufferProtocol('some-protocol', () => {
  callback({ mimeType: 'text/html', data: Buffer.from('<h5>Response</h5>') });
});

// Replace with
protocol.handle('some-protocol', () => {
  return new Response(
    Buffer.from('<h5>Response</h5>'), // Could also be a string or ReadableStream.
    { headers: { 'content-type': 'text/html' } },
  );
});

// Deprecated in Electron 25
protocol.registerHttpProtocol('some-protocol', () => {
  callback({ url: 'https://electron.js.cn' });
});

// Replace with
protocol.handle('some-protocol', () => {
  return net.fetch('https://electron.js.cn');
});

// Deprecated in Electron 25
protocol.registerFileProtocol('some-protocol', () => {
  callback({ filePath: '/path/to/my/file' });
});

// Replace with
protocol.handle('some-protocol', () => {
  return net.fetch('file:///path/to/my/file');
});

已弃用：BrowserWindow.setTrafficLightPosition(position)​

BrowserWindow.setTrafficLightPosition(position) 已被弃用，应改用 BrowserWindow.setWindowButtonPosition(position) API，该 API 接受 null 而非 { x: 0, y: 0 } 来将位置重置为系统默认值。

// Deprecated in Electron 25
win.setTrafficLightPosition({ x: 10, y: 10 });
win.setTrafficLightPosition({ x: 0, y: 0 });

// Replace with
win.setWindowButtonPosition({ x: 10, y: 10 });
win.setWindowButtonPosition(null);

已弃用：BrowserWindow.getTrafficLightPosition()​

BrowserWindow.getTrafficLightPosition() 已被弃用，应改用 BrowserWindow.getWindowButtonPosition() API，该 API 在没有自定义位置时返回 null 而非 { x: 0, y: 0 }。

// Deprecated in Electron 25
const pos = win.getTrafficLightPosition();
if (pos.x === 0 && pos.y === 0) {
  // No custom position.
}

// Replace with
const ret = win.getWindowButtonPosition();
if (ret === null) {
  // No custom position.
}

新特性​

• 添加了 net.fetch()。 #36733
  • net.fetch 支持对 file: URL 和使用 protocol.register*Protocol 注册的自定义协议的请求。 #36606
• 添加了 BrowserWindow.set/getWindowButtonPosition API。 #37094
• 添加了 protocol.handle，取代并废弃了 protocol.{register,intercept}{String,Buffer,Stream,Http,File}Protocol。 #36674
• 向 webContents 和 <webview> 标签添加了 will-frame-navigate 事件，该事件会在框架层次结构中的任何框架尝试导航时触发。#34418
• 向 navigator 事件添加了发起者信息。此信息允许区分由父框架引起的 window.open 导航与子级发起的导航。#37085
• 添加了 net.resolveHost，它使用 defaultSession 对象解析主机。 #38152
• 为 app 添加了新的 'did-resign-active' 事件。 #38018
• 为 webContents.print() 添加了几个标准的页面尺寸选项。 #37159
• 为会话处理程序 ses.setDisplayMediaRequestHandler() 回调添加了 enableLocalEcho 标志，允许在 audio 是 WebFrameMain 时，将远程音频输入回显到本地输出流。#37315
• 向 powerMonitor 添加了热管理信息。 #38028
• 允许将绝对路径传递给 session.fromPath() API。 #37604
• 在 webContents 上暴露了 audio-state-changed 事件。 #37366

22.x.y 持续支持​

正如 告别 Windows 7/8/8.1 中所述，Electron 22（Chromium 108）的计划支持结束日期将从 2023 年 5 月 30 日延长至 2023 年 10 月 10 日。Electron 团队将继续将此计划中的安全修复反向移植到 Electron 22，直到 2023 年 10 月 10 日。10 月份的支持日期遵循 Chromium 和 Microsoft 的延长支持日期。10 月 11 日，Electron 团队将停止支持，回溯到最新的三个稳定主版本，这些版本将不再支持 Windows 7/8/8.1。

下一步计划​

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

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

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

Electron 24.0.0 已发布！它包含了 Chromium 112.0.5615.49、V8 11.2 和 Node.js 18.14.0 的升级。请继续阅读以了解更多详情！

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

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

重要变更​

技术栈变更​

• Chromium 112.0.5615.49
  • Chrome 112 中的新内容
  • Chrome 111 中的新内容
  • DevTools 112 中的新内容
  • DevTools 111 中的新内容
• Node.js 18.14.0
  • Node 18.14.0 博客文章
• V8 11.2

破坏性变更​

API 变更：nativeImage.createThumbnailFromPath(path, size)​

maxSize 参数已更改为 size，以反映传入的大小将是创建的缩略图的大小。以前，如果图像小于 maxSize，Windows 不会放大图像，而 macOS 总是将大小设置为 maxSize。现在，跨平台的行为相同。

// a 128x128 image.
const imagePath = path.join('path', 'to', 'capybara.png');

// Scaling up a smaller image.
const upSize = { width: 256, height: 256 };
nativeImage.createThumbnailFromPath(imagePath, upSize).then((result) => {
  console.log(result.getSize()); // { width: 256, height: 256 }
});

// Scaling down a larger image.
const downSize = { width: 64, height: 64 };
nativeImage.createThumbnailFromPath(imagePath, downSize).then((result) => {
  console.log(result.getSize()); // { width: 64, height: 64 }
});

新特性​

• 已添加使用 cookies.get() 过滤 HttpOnly Cookie 的功能。#37365
• 在 shell.openExternal() 选项中添加了 logUsage，它允许在 Windows 上将 SEE_MASK_FLAG_LOG_USAGE 标志传递给 ShellExecuteEx。SEE_MASK_FLAG_LOG_USAGE 标志表示用户发起的启动，它允许跟踪常用程序和其他行为。#37291
• 已将 types 添加到 webRequest 过滤器中，增加了监听请求的能力。#37427
• 向 webContents 添加了新的 devtools-open-url 事件，以允许开发者打开新窗口。#36774
• 已向 webContents.print() 添加了几种标准的页面大小选项。#37265
• 为会话处理程序 ses.setDisplayMediaRequestHandler() 回调添加了 enableLocalEcho 标志，当 audio 是 WebFrameMain 时，允许在本地输出流中回显远程音频输入。#37528
• 允许将特定于应用程序的用户名传递给 inAppPurchase.purchaseProduct()。#35902
• 暴露了 window.invalidateShadow() 以清除 macOS 上的残留视觉伪影。#32452
• Electron 节点头配置文件中默认启用全程序优化，允许编译器使用程序中所有模块的信息进行优化，而不是基于每个模块（编译单元）。#36937
• SystemPreferences::CanPromptTouchID (macOS) 现在支持 Apple Watch。#36935

停止支持 21.x.y​

根据项目的支持政策，Electron 21.x.y 已达到支持结束。建议开发者和应用程序升级到更新的 Electron 版本。

正如在告别 Windows 7/8/8.1 中提到的，Electron 22 (Chromium 108) 计划的生命周期结束日期将从 2023 年 5 月 30 日延长至 2023 年 10 月 10 日。Electron 团队将继续将此计划中的任何安全修复程序向后移植到 Electron 22，直到 2023 年 10 月 10 日。

下一步计划​

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

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

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

electron/electron 仓库的首次提交是在 2013 年 3 月 13 日¹。

10 年间，来自 1192 位独立贡献者的 27,147 次提交，Electron 已成为当今最流行的桌面应用程序构建框架之一。这个里程碑是庆祝和反思我们迄今为止的旅程，并分享我们一路走来所学到的经验的绝佳机会。

如果没有各位投入时间和精力为项目做出贡献，我们今天就不会取得如此成就。尽管源代码提交始终是最显而易见的贡献，但我们也必须感谢那些报告 Bug、维护用户态模块、提供文档和翻译，以及在网络空间中参与 Electron 社区的人们所付出的努力。对于我们这些维护者来说，每一次贡献都弥足珍贵。

在继续阅读这篇博客文章之前：谢谢你。❤️

我们是如何走到这里的？​

Atom Shell 是作为 GitHub Atom 编辑器的骨干而构建的，该编辑器于 2014 年 4 月发布公开测试版。它从头开始构建，旨在替代当时可用的基于网络的桌面框架（node-webkit 和 Chromium Embedded Framework）。它有一个杀手级功能：嵌入 Node.js 和 Chromium 以提供强大的桌面运行时，支持 Web 技术。

一年之内，Atom Shell 的功能和受欢迎程度开始大幅增长。大型公司、初创企业和个人开发者都开始使用它构建应用程序（一些早期采用者包括 Slack、GitKraken 和 WebTorrent），该项目也因此更名为 Electron。

从那时起，Electron 便一路高歌猛进，从未停歇。以下是我们的每周下载量随时间变化的图表，由 npmtrends.com 提供：

Electron v1 于 2016 年发布，承诺提供更稳定的 API、更好的文档和工具。Electron v2 于 2018 年发布，并引入了语义化版本控制，使 Electron 开发者更容易跟踪发布周期。

到 Electron v6 版本，我们转向了与 Chromium 匹配的每 12 周发布一个主要版本的节奏。这个决定改变了项目的理念，将“拥有最新的 Chromium 版本”从一个不错的选择提升为优先事项。这减少了升级之间的技术债务量，使我们更容易保持 Electron 的更新和安全。

从那时起，我们就像一台运转良好的机器，在每个 Chromium 稳定版发布的同一天发布一个新的 Electron 版本。到 2021 年 Chromium 将发布周期加快到 4 周时，我们能够轻松应对，并将发布节奏相应地加快到 8 周。

我们现在正使用 Electron v23（且仍在继续增长），并且仍然致力于为构建跨平台桌面应用程序提供最佳运行时。尽管近年来 JavaScript 开发工具蓬勃发展，但 Electron 仍然是桌面应用程序框架领域稳定、久经考验的中坚力量。Electron 应用程序如今无处不在：你可以使用 Visual Studio Code 编程，使用 Figma 进行设计，使用 Slack 进行交流，并使用 Notion 记笔记（以及许多其他用例）。我们为这一成就感到无比自豪，并感谢所有促成此事的人。

我们一路走来学到了什么？​

通往十周年的道路漫长而曲折。以下是一些帮助我们运营一个可持续的大型开源项目的关键经验。

通过治理模型扩展分布式决策​

当 Electron 首次流行起来后，我们必须克服的一个挑战是如何处理项目的长期发展方向。我们如何管理一个由分布在不同公司、国家和时区的几十名工程师组成的团队？

早期，Electron 的维护者团队依靠非正式协调，这对于小型项目来说快速且轻量，但无法扩展到更广泛的协作。2019 年，我们转向了治理模型，其中不同的工作组拥有正式的职责范围。这对于简化流程并将项目所有权的一部分分配给特定的维护者至关重要。如今，每个工作组 (WG) 负责什么？

• 负责发布 Electron 版本（Releases WG）
• 升级 Chromium 和 Node.js（Upgrades WG）
• 监督公共 API 设计（API WG）
• 维护 Electron 的安全（Security WG）
• 运营网站、文档和工具（Ecosystem WG）
• 社区和企业推广（Outreach WG）
• 社区管理（Community & Safety WG）
• 维护我们的构建基础设施、维护者工具和云服务（Infrastructure WG）

大约在我们转向治理模型的同时，我们将 Electron 的所有权从 GitHub 转移到 OpenJS 基金会。尽管最初的核心团队今天仍在 Microsoft 工作，但他们只是构成 Electron 治理的更大协作组的一部分。²

虽然这个模式并非完美，但它在全球疫情和持续的宏观经济逆风中很好地支持了我们。展望未来，我们计划修订治理章程，以指导我们度过 Electron 的第二个十年。

社区​

开源的社区部分很难，特别是当你的外展团队是穿着风衣的十几名工程师，上面写着“社区经理”时。话虽如此，作为一个大型开源项目意味着我们拥有大量用户，利用他们的精力为 Electron 构建用户态生态系统是维持项目健康的关键部分。

我们为发展我们的社区做了些什么？

建立虚拟社区​

• 2020 年，我们启动了社区 Discord 服务器。我们之前在 Atom 的论坛中有一个版块，但决定使用一个更非正式的消息平台，为维护者和 Electron 开发者之间的讨论以及一般的调试帮助提供一个空间。
• 2021 年，在 @BlackHole1 的帮助下，我们成立了 Electron China 用户组。该小组在 Electron 在中国蓬勃发展的技术领域用户增长方面发挥了重要作用，为他们提供了一个在我们英语空间之外协作想法和讨论 Electron 的空间。我们还要感谢 cnpm 在其中国 npm 镜像中支持 Electron 夜间版本方面所做的工作。

参与高知名度开源项目​

• 自 2019 年以来，我们每年都会庆祝 Hacktoberfest。Hacktoberfest 是 DigitalOcean 组织的年度开源庆祝活动，我们每年都会有数十名热情的贡献者希望在开源软件上留下自己的印记。
• 2020 年，我们参加了 Google Season of Docs 的首届活动，与 @bandantonio 合作重构了 Electron 的新用户教程流程。
• 2022 年，我们首次指导了一名 Google Summer of Code 学生。@aryanshridhar 做了一些出色的工作，重构了 Electron Fiddle 的核心版本加载逻辑，并将其打包工具迁移到 webpack。

自动化一切！​

如今，Electron 治理团队拥有大约 30 名活跃的维护者。我们中只有不到一半是全职贡献者，这意味着有很多工作要做。我们保持一切顺利运行的秘诀是什么？我们的座右铭是：计算机很便宜，而人的时间很宝贵。本着典型的工程师精神，我们开发了一套自动化支持工具，让我们的生活更轻松。

Not Goma​

Electron 核心代码库是一个庞大的 C++ 代码库，构建时间一直是我们在发布错误修复和新功能方面的一个限制因素。2020 年，我们部署了 Not Goma，这是一个针对 Google Goma 分布式编译器服务的自定义 Electron 后端。Not Goma 处理来自授权用户机器的编译请求，并将编译过程分配到后端数百个核心。它还缓存编译结果，以便其他人编译相同文件时只需下载预编译结果。

自从推出 Not Goma 以来，维护者的编译时间从几小时缩短到了几分钟。稳定的网络连接成为贡献者编译 Electron 的最低要求！

持续因子认证 (Continuous Factor Authentication)​

持续因子认证 (CFA) 是 npm 双因素认证 (2FA) 系统之上的一层自动化，我们将其与 semantic-release 结合使用，以管理我们各种 @electron/ npm 包的安全和自动化发布。

虽然 semantic-release 已经自动化了 npm 包的发布过程，但它需要关闭双因素认证，或者传入一个绕过此限制的秘密令牌。

我们构建了 CFA，以便为任意的 CI 作业提供基于时间的一次性密码 (TOTP) 用于 npm 2FA，这使我们能够利用 semantic-release 的自动化，同时保持双因素认证的额外安全性。

我们使用 CFA 与一个 Slack 集成前端，允许维护者在任何装有 Slack 的设备上验证包的发布，只要他们手头有 TOTP 生成器。

Sheriff​

Sheriff 是我们编写的一个开源工具，用于自动化管理 GitHub、Slack 和 Google Workspace 的权限。

Sheriff 的核心价值主张是权限管理应该是一个透明的过程。它使用单个 YAML 配置文件来指定上述所有服务的权限。使用 Sheriff，获得仓库的协作者状态或创建新的邮件列表就像获得 PR 批准和合并一样简单。

Sheriff 还有一个审计日志，会发布到 Slack，当 Electron 组织内任何地方发生可疑活动时，会警告管理员。

…以及我们所有的 GitHub 机器人​

GitHub 是一个具有丰富 API 扩展性和第一方机器人应用框架 Probot 的平台。为了帮助我们专注于工作中更具创造性的部分，我们构建了一套小型机器人，帮助我们完成繁琐的工作。以下是一些例子：

• Sudowoodo 从头到尾自动化 Electron 的发布过程，从启动构建到将发布资源上传到 GitHub 和 npm。
• Trop 通过尝试根据 GitHub PR 标签将补丁挑选到以前的发布分支，来自动化 Electron 的向后移植过程。
• Roller 自动化地滚动升级 Electron 的 Chromium 和 Node.js 依赖。
• Cation 是我们用于 electron/electron PR 的状态检查机器人。

总而言之，我们这个小小的机器人家族极大地提高了我们的开发效率！

下一步是什么？​

当我们进入项目的第二个十年时，你可能会问：Electron 的下一步是什么？

我们将与 Chromium 的发布节奏保持同步，每 8 周发布一个 Electron 的新主要版本，使框架与 Web 平台和 Node.js 的最新和最强大的功能保持同步，同时保持企业级应用程序的稳定性和安全性。

我们通常会在即将推出的计划具体化时公布消息。如果您想了解未来的版本、功能和一般项目更新，您可以阅读我们的博客并关注我们的社交媒体资料（Twitter 和 Mastodon）！

Electron 23.0.0 已发布！它包含了 Chromium 110、V8 11.0 和 Node.js 18.12.1 的升级。此外，Windows 7/8/8.1 的支持已被移除。请继续阅读以获取更多详细信息！

Electron 团队激动地宣布 Electron 23.0.0 发布！您可以通过 npm install electron@latest 使用 npm 安装，或从我们的 发布网站 下载。请继续阅读以了解此次发布的详细信息。

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

重要变更​

技术栈变更​

• Chromium 110
  • Chrome 110 中的新特性
  • Chrome 109 中的新特性
  • DevTools 110 中的新特性
  • DevTools 109 中的新特性
• Node.js 18.12.1
  • Node 18.12.1 博客文章
• V8 11.0

新特性​

• 已向 Display 对象添加了 label 属性。#36933
• 添加了 app.getPreferredSystemLanguages() API，用于返回用户系统的语言。 #36035
• 已添加对 WebUSB API 的支持。#36289
• 已添加对 SerialPort.forget() 的支持，以及在给定源被撤销时会在 Session 对象上发出的新事件 serial-port-revoked。#35310
• 添加了新的 win.setHiddenInMissionControl API，允许开发者在 macOS 上选择不显示 Mission Control。 #36092

停止支持 Windows 7/8/8.1​

Electron 23 不再支持 Windows 7/8/8.1。Electron 遵循 Chromium 的计划弃用策略，该策略将在 Chromium 109 中 弃用 Windows 7/8/8.1 以及 Windows Server 2012 和 2012 R2 的支持（在此处阅读更多）。

破坏性 API 变更​

以下是 Electron 23 中引入的重大更改。您可以在 计划的重大更改 页面上阅读有关这些更改和未来更改的更多信息。

已移除：BrowserWindow scroll-touch-* 事件​

已移除 BrowserWindow 上已弃用的 scroll-touch-begin、scroll-touch-end 和 scroll-touch-edge 事件。请改用 WebContents 上新提供的 input-event 事件。

// Removed in Electron 23.0
-win.on('scroll-touch-begin', scrollTouchBegin)
-win.on('scroll-touch-edge', scrollTouchEdge)
-win.on('scroll-touch-end', scrollTouchEnd)

// Replace with
+win.webContents.on('input-event', (_, event) => {
+  if (event.type === 'gestureScrollBegin') {
+    scrollTouchBegin()
+  } else if (event.type === 'gestureScrollUpdate') +{
+    scrollTouchEdge()
+  } else if (event.type === 'gestureScrollEnd') {
+    scrollTouchEnd()
+  }
+})

20.x.y 版本支持终止​

根据项目的支持策略，Electron 20.x.y 已结束支持。我们鼓励开发者和应用程序升级到更新版本的 Electron。

下一步计划​

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

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

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

Electron 22.0.0 已经发布！ 它包括一个新的实用工具进程 API，对 Windows 7/8/8.1 支持的更新，以及对 Chromium 108, V8 10.8, 和 Node.js 16.17.1 的升级。 请继续阅读以了解更多详情！

Electron 团队很高兴地宣布 Electron 22.0.0 的发布！您可以使用 npm install electron@latest 通过 npm 进行安装，或从我们的发布网站下载。请继续阅读以了解此版本详情。

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

重要变更​

技术栈变更​

• Chromium 108
  • Chrome 108 的新功能
  • Chrome 107 的新功能
  • DevTools 108 的新功能
  • DevTools 107 的新功能
• Node.js 16.17.1
  • Node 16.17.1 博客文章
• V8 10.8

亮点功能​

UtilityProcess API #36089​

新的 UtilityProcess 主进程模块允许创建一个轻量级的 Chromium 子进程，该子进程仅包含 Node.js 集成，同时允许使用 MessageChannel 与沙盒化的渲染器进行通信。该 API 的设计基于 Node.js 的 child_process.fork，以便于迁移，其主要区别在于入口点 modulePath 必须位于打包应用程序内部，以便只加载受信任的脚本。此外，该模块默认阻止与渲染器建立通信通道，以维护主进程是应用程序中唯一受信任进程的约定。

您可以在我们的文档中阅读有关新的 UtilityProcess API 的更多信息。

Windows 7/8/8.1 支持更新​

Electron 22 将是最后一个支持 Windows 7/8/8.1 的 Electron 主要版本。Electron 遵循 Chromium 的计划弃用策略，该策略将在Chromium 109 中弃用对 Windows 7/8/8.1 的支持（点击此处了解更多）。

Electron 23 及更高版本将不再支持 Windows 7/8/8.1。

其他亮点变更​

• 增加了对 Linux 和 Windows 上 Web Bluetooth PIN 配对的支持。#35416
• 添加了 LoadBrowserProcessSpecificV8Snapshot 作为一项新的 fuse，它允许主进程/浏览器进程从 browser_v8_context_snapshot.bin 文件加载其 v8 快照。任何其他进程将使用今天使用的相同路径。#35266
• 添加了 WebContents.opener 以访问窗口打开程序，以及 webContents.fromFrame(frame) 以获取与 WebFrameMain 实例对应的 WebContents。#35140
• 通过一个新的会话处理程序 ses.setDisplayMediaRequestHandler，增加了对 navigator.mediaDevices.getDisplayMedia 的支持。#30702

破坏性 API 变更​

以下是 Electron 22 中引入的重大更改。您可以在计划的重大更改页面上了解更多关于这些更改和未来更改的信息。

已弃用：webContents.incrementCapturerCount(stayHidden, stayAwake)​

webContents.incrementCapturerCount(stayHidden, stayAwake) 已被弃用。 现在当页面捕获完成时，它由 webContents.capturePage 自动处理。

const w = new BrowserWindow({ show: false })

- w.webContents.incrementCapturerCount()
- w.capturePage().then(image => {
-   console.log(image.toDataURL())
-   w.webContents.decrementCapturerCount()
- })

+ w.capturePage().then(image => {
+   console.log(image.toDataURL())
+ })

已弃用：webContents.decrementCapturerCount(stayHidden, stayAwake)​

webContents.decrementCapturerCount(stayHidden, stayAwake) 已被弃用。 现在当页面捕获完成时，它由 webContents.capturePage 自动处理。

const w = new BrowserWindow({ show: false })

- w.webContents.incrementCapturerCount()
- w.capturePage().then(image => {
-   console.log(image.toDataURL())
-   w.webContents.decrementCapturerCount()
- })

+ w.capturePage().then(image => {
+   console.log(image.toDataURL())
+ })

已移除: WebContents 的 new-window 事件​

WebContents 的 new-window 事件已被移除。它已被 webContents.setWindowOpenHandler() 取代。

- webContents.on('new-window', (event) => {
-   event.preventDefault()
- })

+ webContents.setWindowOpenHandler((details) => {
+   return { action: 'deny' }
+ })

已弃用：BrowserWindow scroll-touch-* 事件​

BrowserWindow 上的 scroll-touch-begin、scroll-touch-end 和 scroll-touch-edge 事件已被弃用。现在，请使用 WebContents 上新提供的 input-event 事件。

// Deprecated
- win.on('scroll-touch-begin', scrollTouchBegin)
- win.on('scroll-touch-edge', scrollTouchEdge)
- win.on('scroll-touch-end', scrollTouchEnd)

// Replace with
+ win.webContents.on('input-event', (_, event) => {
+   if (event.type === 'gestureScrollBegin') {
+     scrollTouchBegin()
+   } else if (event.type === 'gestureScrollUpdate') {
+     scrollTouchEdge()
+   } else if (event.type === 'gestureScrollEnd') {
+     scrollTouchEnd()
+   }
+ })

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

根据项目的支持策略，Electron 19.x.y 已结束支持。建议开发人员和应用程序升级到新版本的 Electron。

下一步计划​

Electron 项目将在 2022 年 12 月暂停，并于 2023 年 1 月恢复。您可以在十二月停工博客文章中找到更多信息。

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

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

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