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 Publisher 和 ESM 支持所做的贡献!
更好的静态存储自动更新
Squirrel.Windows 和 Squirrel.Mac 是平台特定的更新器技术,它们支持 Electron 内置的 autoUpdater
模块。这两个项目都通过两种方法支持自动更新:
- 与 Squirrel 兼容的更新服务器
- 托管在静态存储提供商上的清单 URL(例如 AWS、Google Cloud Platform、Microsoft Azure 等)
更新服务器方法传统上是 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 将继续将其所有 monorepo 包发布在
@electron-forge/
命名空间下。
⭐ 在此过程中,我们还意外地将 electron/packager 仓库设为私有,这不幸地导致我们的 GitHub Star 计数被清零(清零前超过 9000)。如果您是 Packager 的活跃用户,我们将不胜感激您的 ⭐ Star ⭐!
介绍 @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 方式使用。
请试用并向我们在 该仓库的 issues 跟踪器 中提供反馈!
下一步计划?
下个月我们将进入一年一度的十二月静默期。在此期间,我们将思考如何在 2024 年让 Electron 开发体验更上一层楼。
您希望我们接下来从事哪些方面的工作?请告诉我们!