生态系统 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文件。（P.S. 期待 Electron 28 中的 ESM 入口点支持。） - 制造者现在并行运行：在 Electron Forge 6 中，制造者为了 ✨ 传统 ✨ 原因而顺序运行。从那时起，我们测试了 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 制造者现在可以配置为输出与
autoUpdater兼容的更新清单。 update-electron-app的一个新主要版本 (v2.0.0) 现在可以读取这些生成的清单，作为 update.electronjs.org 服务器的替代方案。
一旦您的制造者和发布者配置为将更新清单上传到云文件存储，您只需进行几行配置即可启用自动更新
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 年变得更好。
您希望我们接下来做些什么？告诉我们！
