跳至主要内容

Ecosystem 2023 Recap

·阅读时长 5 分钟
erickzhao
erickzhao

回顾 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-01 开始，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 入口点的支持。）
  • 制作者现在并行运行： 在 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 月的安静期。在这期间，我们将思考如何才能在 2024 年让 Electron 开发体验变得更好。

您希望我们接下来做些什么？请告诉我们！