跳至主要內容

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 入口點的支援。）
  • 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 套件。
尋求星號

⭐ 在此過程中，我們還意外地將 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 使用。

請嘗試使用它，並在儲存庫的 issue 追蹤器中提供您的回饋！

接下來是什麼？​

我們將在下個月進入年度 12 月的靜默期。在此期間，我們將思考如何在 2024 年讓 Electron 開發體驗變得更好。

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