2013年3月13日¹ 首次被提交到 electron/electron 仓库。

经过10年和来自 1192 位贡献者的 27147 次提交之后，Electron 已成为如今构建桌面应用程序最受欢迎的框架之一。 这个里程碑是一个完美的机会，可以庆祝和回顾我们迄今为止的旅程，并分享我们沿途所学到的东西。

如果没有每个人都献出时间和努力为该项目做出贡献，我们今天就不会在这里了。 尽管源代码提交总是最显著的贡献，但我们还必须承认那些报告错误、维护用户空间模块、提供文档和翻译，并参与网络空间中的 Electron 社区的人所做出的努力。 对于我们作为维护者来说，每一份贡献都是无价之宝。

在我们继续博客文章的其余部分之前：谢谢你们。 ❤️

我们怎么发展到现在的？​

Atom Shell 是为 GitHub Atom 编辑器 打造的基础框架，该编辑器于 2014 年 4 月公开发布 beta 版。 它是基于当时一些以网页为基础的桌面端框架 (node-webkit and Chromium Embedded Framework) 从头开始构建的替代方案。 它有一个杀手级功能：嵌入 Node.js 和 Chromium，为网页 技术提供一个强大的桌面运行时间。

一年之内，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 进行笔记记录 (还有许多其他用例)。 我们对这一成就感到非常自豪，并感谢使之成为可能的每一个人。

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

这十年的历程曲折而漫长。 以下是一些关键因素，帮助我们运营一个可持续的大型开源项目。

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

我们不得不克服的一个挑战是，在 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 Foundation 尽管原来的核心团队今天仍然在 Microsoft 工作，他们也仅仅是 Electron 治理团队这个庞大组织的一部分。²

虽然这种模式并不完美，但它在全球流行病和持续的宏观经济逆风中为我们提供了良好的支持。 今后，我们计划修订治理章程，以指导我们走向 Electron 的第二个十年。

社区​

开源社区的组织是很困难的，特别是当你的外联团队是一群穿着“社区经理”外套的十几个工程师时。 话虽如此，成为一个大型的开源项目意味着我们拥有大量的用户，利用他们的能量来为 Electron 建立用户生态系统是维持项目健康的关键部分。

我们为发展社区做了哪些工作？

建立社区​

• 2020 年，我们推出了我们在 Discord server 的社区。 我们之前在 Atom 的论坛上有一个版块，但决定有一个更非正式的消息传递平台，让维护者和 Electron 开发人员之间有一个讨论的空间，并获得一般的调试帮助。
• 2021 年，我们在 @BlackHole1 的帮助下建立了 Electron China 用户群。 这个群体在中国蓬勃发展的科技界中对 Electron 用户的增长起了重要作用，为他们在我们的英语语言的范畴之外提供了一个创意合作、讨论 Electron 的空间。 我们还要感谢 cnpm 为支持 Electron 在他们的中文镜像中为 npm 所做的工作。

参与高知名度的开源项目​​

• 自 2019 年以来，我们每年都会庆祝 Hacktoberest 。 Hacktoberfest 是由 DigitalOcean 组织的每年一度的开源庆典，每年我们都会有数十名热情的贡献者加入其中，希望在开源软件上留下自己的印记。
• 在 2020 年，我们参加了首次举行的 Google Season of Docs 活动，与 @bandantonio 合作重新设计了 Electron 的新用户教程流程。
• 2022年，我们第一次指导 Google Summer of Code 的学生。 @aryanshridhar did some awesome work to refactor Electron Fiddle's core version loading logic and migrate its bundler to webpack.

将所有东西自动化！​

今天，Electron 的维护有大约 30 名积极的维护者。 我们中只有不到一半的人是全职贡献者，这意味着还有很多工作需要做。 我们怎么才能让一切顺利进行呢？ 我们的座右铭是计算机便宜，人的时间是昂贵的。 按照典型的工程师风格，我们开发了一套自动化支持工具来使我们的生活更轻松。

Not Goma​​

Electron 的核心代码库是一个庞大的 C++ 代码库，而编译时间一直是限制我们能够快速发布错误修复和新功能的因素之一。 在2020年，我们部署了Not Goma，这是一个专门为 Electron 定制的后端，用于 Google 的 Goma 分布式编译器服务。 Not Goma 处理来自授权用户机器的编译请求，并在后端的数百个核心上进行分布式编译。 它还会缓存编译结果，这样编译相同文件的其他人只需下载预编译的结果即可。

自从启用 Not Goma 以来，维护者的编译时间已经从几个小时缩短到几分钟的级别。 拥有稳定的互联网连接成为贡献者编译 Electron 的最低要求！

Continuous Factor Authentication​

Continuous Factor Authentication (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 标签，在先前的发行分支上尝试挑选补丁，从而自动化 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.1的支持。 请阅读下文了解更多详情！

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

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

重要变化​

架构（Stack）更新​

• Chromium 110
  • Chromium 有新版本110
  • Chromium 有新版本109
  • DevTools 110 中的新增功能
  • DevTools 109 中的新增功能
• Node.js 18.12.1
  • Node 18.12.1 博文
• V8 11.0

新特性​

• 将 label 属性添加到 Display 对象上。 #36933
• 添加了 app.getPreferredSystemLanguages() API 以返回用户的系统语言。 #36035
• 添加了对 WebUSB API 的支持。 #36289
• 添加了对 SerialPort.forget() 的支持，以及当给定来源被撤销时在 Session 对象上发出的新事件 serial-port-revoked 。 #35310
• 添加了新的 win.setHiddenInMissionControl API 以允许开发者选择退出 macOS 上的任务控制。 #36092

放弃对 Windows 7/8.1 支持​

Electron 23 不再支持 Windows 7/8.1。 Electron 遵循计划中的 Chromium 弃用政策，该政策将 在 Chromium 109 中弃用 Windows 7/8/8.1 支持（在此处阅读更多信息）。

重要的API变更​

以下是 Electron 23 中引入的破坏性变更。 您可以在 Planned Breaking Changes 页面上阅读有关这些更改和未来更改的更多信息。

已删除：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 进行安装，或者从我们的 发布网站 下载它。 继续阅读此版本的详细信息。

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

重要变化​

架构（Stack）更新​

• 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 主进程模块允许创建仅集成 Node.js 的轻量级 Chromium 子进程，同时还允许使用 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 支持（在此处阅读更多信息）](https://support.google.com/chrome/thread/185534985/sunsetting-support-for-windows-7-8-8-1-in-early -2023?hl=en)。

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 中引入的破坏性变更。 您可以在 Planned Breaking Changes 页面上阅读有关这些更改和未来更改的更多信息。

已废弃：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 事件已被删除。 Instead, use the newly available input-event event on WebContents.

// 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的公开时间表。

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

Electron 将在 Electron23 中开始结束 Windows 7, Windows 8 和 Windows 8.1 的支持。

In line with Chromium’s deprecation policy, Electron will end support of Windows 7, Windows 8 and Windows 8.1 beginning in Electron 23. This matches Microsoft's end of support for Windows 7 ESU and Windows 8.1 extended on January 10th, 2023.

Electron 22 will be the last Electron major version to support Windows versions older than 10. Electron 23 及以后的主要版本将不支持 Windows 7/8/8.1。 Older versions of Electron will continue to function on Windows 7, and we will continue to release patches for Electron the 22.x series until May 30 2023, when Electron will end support for 22.x (according to our support timeline).

为什么要废弃它？​

Electron 遵循计划中的Chromium 弃置策略，它将不支持Chromium 109 (在这里阅读更多关于 Chromium 的时间表)。 Electron 23 将包含 Chromium 110, 它不支持旧版本的Windows。

因此含有Chromium 108的Electron 22将是最后一个支持版本。

弃用时间表​

The following is our planned deprecation timeline:

• 2022 年 12 月：Electron 团队将度过一段假期，此时将不会有大的动向。
• January 2023: Windows 7 & 8 related issues are accepted for all supported release branches.
• 2023 年 2 月 7 日: Electron 23 将发布。
• February 8 2023 - May 29 2023: Electron will continue to accept fixes for supported lines older than Electron 23.
• 2023: Electron 22 迎来其支持周期的终结。

这对开发者意味着什么：

• The Electron team will accept issues and fixes related to Windows 7/8/8.1 for stable supported lines, until each line reaches the end of its support cycle.
  • This specifically applies to Electron 22, Electron 21 and Electron 20.
• New issues related to Windows 7/8/8.1 will be accepted for Electron versions older than Electron 23.
  • New issues will not be accepted for any newer release lines.
• Once Electron 22 has reached the end of its support cycle, all existing issues related to Windows 7/8/8.1 will be closed.

下一步​

Please feel free to write to us at info@electronjs.org if you have any questions or concerns. 您也可以在我们官方的 Electron Discord 中找到社区支持。

2022年12月Electron项目将进入暂停状态，然后在2023年1月全速恢复。

通过 GIPHY

12月保持不变的内容​

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

12月变动的内容​

1. 12 月没有新的稳定版。 12 月的最后两周没有 Nightly 和 Alpha 版本。
2. 除了少数例外，不会合并请求的审核或合并。
3. 任何仓库上都不会有问题跟进更新。
4. 维护人员不会提供 Discord 调试帮助。
5. 社交媒体暂停更新内容。

为什么会发生这种情况？​

With the success of December Quiet Month 2021, we wanted to bring it back for 2022. 对于大多数公司来说，12 月仍然是一个安静的月份，所以我们希望给我们的维护者一个充电的机会。 每个人都期待着2023年的到来，我们期待着会有好事！ 我们鼓励其他项目考虑采取类似措施。

我们很高兴地宣布 Electron Forge v6.0.0 现已推出！ 此版本标志着自 2018 年以来 Forge 的第一个主要版本，并将该项目从 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 Bundling 及预先配置好的构建体系。

有关详细信息，请参阅 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 已经在 beta 阶段花了很长时间，它的发布节奏也逐渐放缓。 然而，我们在 2022 年下半年加速了开发，并利用在 v6.0.0 稳定版本之前的最后几个版本推出了一些最终的重大更改。

如果您是 Electron Forge 6 测试版用户，请参阅 v6.0 GitHub 更新日志 了解最近测试版中所做的重大变更 (>=6.0.0-beta.65)。

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

提交您的反馈！​

告诉我们您的想法！ Electron Forge 团队一直在尝试提升用户在构建项目时候的开发体验。

您可以通过提交功能请求、提交 issues 或直接联系我们来进行反馈及改进 Electron Forge！ 您也可以加入我们的 官方 Electron Discord 英文社区，那里有一个专门用于 Electron Forge 讨论的频道。

如果您想在 https://electronforge.io 上对 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 提案将这个框架的一部分作为 Electron 中的 JavaScript 类引入，最终目标是允许开发人员为其 Electron 应用程序创建非 Web UI 元素。 这将避免应用程序不得不将网页内容集中在一起。

使这套新的 API 成为可能的基础工作目前正在进行之中。 以下是您在不久的将来可以期待的一些事。

示例：将窗口模型重置为 WebContentsView​

我们计划的第一次更改是在 Electron 的 API 中显示 Chrome 的 WebContentsView。这将 是我们现有的 BrowsView API 的继承者(尽管该名称是 Electron 指定的代码 与 Chromium 视图无关)。 随着 WebContentsView 暴露，我们将有一个可重用的 View 对象 可以显示网页内容，为使 BrowserWindow 类成为纯粹的 JavaScript 打开了大门。 更多的消除了代码复杂性。

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

如果您是一个使用 BrowserViews 的 Electron 开发者，请勿担心，我们没有忘记您！ 我们计划将现有的 BrowserView 类变成一个 WebContentsView 的垫片（shim），以便在您过渡到较新的 API 时提供一个缓冲。

见: electron/electron#35658

示例：使用 ScrollView 滚动网页​

我们在 Stack 的朋友一直在推动一项倡议，将 Chromium ScrollView 组件暴露给 Electron 的 API。 通过这个新的 API，任何子视图组件都可以水平滚动或 垂直滚动。

尽管这个新的 API 实现了一个较小的功能，但该团队的最终目标是建立 一套实用的视图组件，可以作为一个工具包来构建更复杂的非 HTML 接口。

加入我们​

你是 Electron 应用程序的开发者，对这些 API 提案感兴趣吗？ 虽然我们还没有准备好接收更多的 RFC，但请继续关注未来的更多细节!

Electron Forge v6 稳定发布​

自从该框架诞生以来，Electron 的构建工具生态系统在很大程度上是由社区驱动的。 社区驱动的，由许多小型的单用途包组成(例如 electron-installer, 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 install electron@latest 进行安装，或者从我们的 发布网站 下载它。 继续阅读此版本的详细信息。

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

重要变化​

架构（Stack）更新​

• 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 应用的 APN 推送通知的支持。 #33574

破坏性的 API 变更​

以下是 Electron 21 中引入的破坏性变更。

V8 Memory Cage 已启用​

Electron 21 启用 V8 沙盒指针，继 Chrome 决定在 Chrome 103 做同样的事情。 这对原生模块有一定的影响。 此功能具有性能和安全优势，但也对原生模块施加了一些新的限制，例如，使用指向外部（“堆外”）内存的 ArrayBuffers。 更多信息请查看 博客文章。 #34724

重构 webContents.printToPDF​

重构了 webContents.printToPDF 以与 Chromium headless 实现对齐。 更多信息请见 #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 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 中引入的破坏性变化。 有关这些和未来变化的更多信息可在 计划的突破性变化 页面找到。

默认值被更改：默认情况下，渲染器不为 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 21及更高版本将启用 V8 内存隔离区，这将对一些原生模块产生影响。

在Electron 21中，我们将启用 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 21+。 我该怎么做？​

有两种方法可以重构原生模块以使其与 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 进行垃圾回收，并可能导致释放后使用错误。