回顾 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 月 1 日起，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 makers 现在可以配置为输出与 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 将继续在其所有单体库软件包下发布 @electron-forge/ 命名空间。

推出 @electron/windows-sign​

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

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

这种情况一直是 Electron 开发人员的常见痛点，因此我们一直在努力寻找更好的解决方案，该解决方案将 Windows 代码签名隔离到其自己的独立步骤中，类似于 @electron/osx-sign 在 macOS 上的操作。

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

请尝试一下，并在 存储库的问题跟踪器 中向我们提供您的反馈！

接下来是什么？​

我们将在下个月进入每年的 12 月份的平静期。在此期间，我们将思考如何使 2024 年的 Electron 开发体验变得更好。

您希望我们接下来处理哪些内容？请告诉我们！

Electron 项目将在 2023 年 12 月暂停一个月，然后于 2024 年 1 月恢复全速运行。

via GIPHY

12 月份哪些内容保持不变​

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

12 月份哪些内容有所不同​

1. Electron 28.0.0 将于 12 月 5 日发布。Electron 28 发布后，12 月份将不会发布新的稳定版本。
2. 12 月份最后两周将不会发布 Nightly 和 Alpha 版本。
3. 除少数例外情况外，不会进行拉取请求审查或合并。
4. 任何存储库都不会更新问题跟踪器。
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 install electron@latest 使用 npm 安装它，或从我们的 发布网站 下载它。继续阅读以了解有关此版本的详细信息。

如果您有任何反馈，请在 Twitter 或 Mastodon 上与我们分享，或加入我们的社区 Discord！错误和功能请求可以在 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 支持​

macOS 10.13（High Sierra）和 macOS 10.14（Mojave）不再受 Chromium 支持。

旧版本的 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 发行版都收到了更新。此前，公民实验室进行了调查，发现一个“位于华盛顿特区的民间社会组织”使用的 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设置时，这也会禁用沙箱。这是可以理解的：如果您使用 Electron 已经很久了，您可能很享受将require("child_process")或require("fs")放入与 HTML/CSS 代码相同的代码中的便利。

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

沙箱会在所有渲染器进程周围设置一个坚固的“笼子”，确保无论内部发生什么，代码都将在受限的环境中执行。从概念上讲，沙箱比 Chromium 的历史还要悠久，并且是所有主要操作系统都提供的一项功能。Electron 和 Chromium 的沙箱构建在这些系统功能之上。即使您从未显示过用户生成的内容，也应该考虑渲染器可能会受到攻击的可能性：从供应链攻击等复杂场景到细微的错误等简单场景，都可能导致渲染器执行您并非完全打算让它执行的操作。

沙箱使这种场景不那么可怕：进程内部可以自由地使用 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. 由于启用沙箱会禁用 preload 脚本中的 Node.js 集成，因此您不能再使用require("../my-script")。换句话说，您的 preload 脚本需要是一个单独的文件。

   有多种方法可以做到这一点：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！错误和功能请求可以在 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
• 将senderIsMainFrame 添加到通过ipcRenderer.sendTo()发送的消息中。 #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！错误和功能请求可以在 Electron 的问题跟踪器中报告。

值得注意的更改​

亮点​

• 在 Electron 的 net 模块中实现了net.fetch，使用 Chromium 的网络堆栈。这与 Node 的fetch()不同，后者使用 Node.js 的 HTTP 堆栈。请参阅#36733 和#36606。
• 添加了protocol.handle，它替换并弃用了protocol.{register,intercept}{String,Buffer,Stream,Http,File}Protocol。 #36674
• 扩展了对 Electron 22 的支持，以匹配 Chromium 和 Microsoft 的 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://www.electron.js.cn' });
});

// Replace with
protocol.handle('some-protocol', () => {
  return net.fetch('https://www.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
• 向导航器事件添加了发起者信息。此信息允许区分来自父框架导致导航的 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！错误和功能请求可以在 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，以反映传入的大小将是创建的缩略图的大小。以前，如果 Windows 中图像小于 maxSize，则不会将其放大，而 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
• 向 webRequest 过滤器添加了 types，增加了过滤监听请求的功能。 #37427
• 向 webContents 添加了一个新的 devtools-open-url 事件，允许开发人员使用它们打开新窗口。 #36774
• 向 webContents.print() 添加了几个标准页面大小选项。 #37265
• 向会话处理程序 ses.setDisplayMediaRequestHandler() 回调添加了 enableLocalEcho 标志，用于允许在 audio 为 WebFrameMain 时将远程音频输入回显到本地输出流中。 #37528
• 允许将应用程序特定的用户名传递给 inAppPurchase.purchaseProduct()。 #35902
• 公开了 window.invalidateShadow() 以清除 macOS 上的残余视觉伪影。 #32452
• 现在在 electron node 头文件配置文件中默认启用整个程序优化，允许编译器使用来自程序中所有模块的信息执行优化，而不是基于每个模块（编译单元）执行优化。 #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 位唯一贡献者的 27147 次更多提交，Electron 已成为当今最流行的桌面应用程序构建框架之一。这一里程碑是庆祝和回顾我们迄今为止旅程的绝佳机会，并分享我们在此过程中学到的知识。

如果没有每个人都投入时间和精力为该项目做出贡献，我们今天将不会取得成功。虽然源代码提交始终是最明显的贡献，但我们也必须承认那些报告错误、维护用户模块、提供文档和翻译以及在网络空间参与 Electron 社区的人们的努力。每个贡献对我们维护人员来说都非常宝贵。

在我们继续这篇博文的其余部分之前：谢谢您。❤️

我们是如何走到今天这一步的？​

Atom Shell 是作为 GitHub 的 Atom 编辑器 的基础构建的，该编辑器于 2014 年 4 月公开测试版发布。它是从头开始构建的，作为当时可用的基于 Web 的桌面框架（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 时，我们转向了每 12 周发布一个主要版本的定期节奏，以匹配 Chromium 的节奏。这一决定是该项目思维方式的转变，将“拥有最新的 Chromium 版本”从锦上添花变成了优先事项。这减少了升级之间的技术债务，使我们更容易保持 Electron 的更新和安全。

从那时起，我们便成为了一台运转良好的机器，在 Chromium 稳定版发布的同一天发布新的 Electron 版本。到 2021 年 Chromium 加快发布节奏至 4 周时，我们能够耸耸肩并相应地将我们的发布节奏提高到 8 周。

我们现在使用 Electron v23（并且还在继续），并且仍然致力于为构建跨平台桌面应用程序构建最佳运行时。即使近年来 JavaScript 开发工具蓬勃发展，Electron 仍然是桌面应用程序框架领域中稳定且经过实战检验的中坚力量。Electron 应用程序如今无处不在：您可以使用 Visual Studio Code 进行编程，使用 Figma 进行设计，使用 Slack 进行沟通，并使用 Notion 记录笔记（以及许多其他用例）。我们为这一成就感到无比自豪，并感谢所有为此做出贡献的人。

我们在这一过程中学到了什么？​

通往 10 周年里程碑的道路漫长而曲折。以下是一些帮助我们运营可持续的大型开源项目的关键因素。

使用治理模型扩展分布式决策​

我们必须克服的一个挑战是在 Electron 首次流行后处理项目的长期方向。我们如何处理成为一个分布在公司、国家和时区之间的大约几十名工程师的团队？

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

• 发布 Electron 版本（发布 WG）
• 升级 Chromium 和 Node.js（升级 WG）
• 监督公共 API 设计（API WG）
• 保持 Electron 安全（安全 WG）
• 运行网站、文档和工具（生态系统 WG）
• 社区和企业推广（推广 WG）

• 社区维护 (社区与安全工作组)
• 维护我们的构建基础设施、维护者工具和云服务 (基础设施工作组)

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

虽然这种模式并不完美，但它在全球大流行和持续的宏观经济逆风中对我们非常有利。展望未来，我们计划修改治理章程，指导我们度过 Electron 的第二个十年。

社区​

开源项目的社区部分很难，尤其是在你的外联团队是一个穿着印着“社区经理”字样的风衣的十几名工程师的时候。也就是说，作为一个大型开源项目，意味着我们拥有大量的用户，利用他们的能量为 Electron 构建用户生态系统是维持项目健康的关键部分。

我们一直在做些什么来发展我们的社区影响力？

构建虚拟社区​

• 2020 年，我们推出了我们的社区 Discord 服务器。我们之前在 Atom 的论坛中有一个版块，但决定建立一个更非正式的消息平台，为维护者和 Electron 开发人员之间的讨论以及一般的调试帮助提供一个空间。
• 2021 年，在 @BlackHole1 的帮助下，我们建立了 Electron 中国 用户组。该用户组对于来自中国蓬勃发展的科技行业的 Electron 用户的增长起到了至关重要的作用，为他们提供了一个在我们的英语空间之外协作想法和讨论 Electron 的场所。我们还要感谢 cnpm 为支持 Electron 的 nightly 版本在其 npm 的中国镜像中所做的工作。

参与高可见度的开源项目​

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

自动化一切！​

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

非 Goma​

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

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

持续双因素身份验证​

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

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

我们构建 CFA 的目的是为 npm 2FA 提供基于时间的一次性密码 (TOTP) 给任意 CI 作业，从而使我们能够利用 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 标签将补丁 cherry-pick 到以前的发布分支来自动化 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！错误和功能请求可以在 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() 的支持，以及一个新的事件 serial-port-revoked，当给定来源被撤销时，该事件会在 Session 对象上发出。 #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！错误和功能请求可以在 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 蓝牙 PIN 配对的支持。 #35416
• 添加了 LoadBrowserProcessSpecificV8Snapshot 作为新的保险丝，它将允许主/浏览器进程从 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 月恢复。更多信息可以在 12 月关闭博客文章 中找到。

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

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

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