跳至主要内容

2023 年生态系统回顾

·阅读时长 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 终止了旧版 altool 用于 macOS 公证，此版本已将其从 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 的活跃用户，我们将非常感谢您给一个 ⭐ Star ⭐！

介绍 @electron/windows-sign​

自 2023-06-01 起，行业标准开始要求 Windows 代码签名证书的密钥存储在符合 FIPS 标准的硬件上。

实际上，这意味着对于在 CI 环境中构建和签名的应用来说，代码签名变得更加困难，因为许多 Electron 工具将证书文件和密码作为配置参数，并尝试使用硬编码逻辑进行签名。

这种情况一直是 Electron 开发者的一个常见痛点，这就是为什么我们一直在致力于一个更好的解决方案，将 Windows 代码签名隔离到自己的独立步骤中，类似于 @electron/osx-sign 在 macOS 上所做的那样。

将来，我们计划将此包完全集成到 Electron Forge 工具链中，但目前它独立存在。 该包目前可通过 npm install --save-dev @electron/windows-sign 安装，并可通过编程方式或 CLI 使用。

请尝试一下，并在仓库的问题跟踪器中给我们反馈！

下一步是什么？​

下个月我们将进入一年一度的十二月静默期。在此期间，我们将思考如何在 2024 年进一步提升 Electron 开发体验。

您希望我们下一步开展哪些工作？请告诉我们！