跳至主要內容

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 進入點支援。)
  • Maker 現在並行執行： 在 Electron Forge 6 中，Maker 由於 ✨ 舊版 ✨ 原因而循序執行。從那時起，我們測試了 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 maker 現在可以設定為輸出與 autoUpdater 相容的更新資訊清單。
  • 新主要版本的 update-electron-app (v2.0.0) 現在可以讀取這些產生的資訊清單，以替代 update.electronjs.org 伺服器。

一旦您的 Maker 和發布者設定為將更新資訊清單上傳到雲端檔案儲存空間，您只需幾行設定即可啟用自動更新

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/ 命名空間下發布其所有 monorepo 套件。
尋求 Star

⭐ 在此過程中，我們也不小心將 electron/packager 儲存庫設為私有，這產生了不幸的副作用，即抹除了我們的 GitHub Star 數 (在抹除之前超過 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 開發體驗變得更好。

您希望我們接下來處理哪些方面？請告訴我們！