2023 年生态系统回顾
回顾 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 步骤的并行化,没有出现任何负面影响,因此在为同一平台构建多个目标时,您应该会看到速度提升!
🙇 非常感谢 mahnunchik 为 Forge 配置中的 GCS 发布者和 ESM 支持做出的贡献!
更好的静态存储自动更新
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}`,
},
});
📦 想了解更多?有关详细指南,请参阅Forge 的自动更新文档。
@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/packager 仓库设为私有,这不幸地导致了我们 GitHub 星标数的清零(在清零之前超过 9000 个)。如果您是 Packager 的活跃用户,我们恳请您给予一个 ⭐ **星标** ⭐!
引入 @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 月份静默期。在此期间,我们将思考如何让 Electron 开发体验在 2024 年变得更好。
您希望我们接下来关注哪些方面?请告诉我们!