Réflexion à propos des améliorations et changements intervenu dans l’écosystème des développeurs d’Electron en 2023.
Au cours des derniers mois, nous avons concocté plusieurs changements dans l’écosystème Electron pour booster l’expérience des développeurs pour les applications Electron ! Voici un rapide aperçu des derniers ajouts en direct du siège d’Electron.
Forge Electron 7 et au-delà
Electron Forge 7— nouvelle version majeure de notre outil tout-en-un pour l’empaquetage et la distribution des applications Electron, est maintenant disponible.
Alors que Forge 6 était une réécriture complète de la v5, la v7 a une portée plus réduite, mais contient toujours quelques modifications de rupture. À l’avenir, nous continuerons à publier des versions majeures de Forge car des modifications de rupture doivent être apportées.
Pour plus de détails, consultez la version 7.0.0 de Forge sur GitHub.
Dernières modifications
- Switched to
notarytool for macOS notarization: As of 2023-11-01, Apple sunset the legacy altool for macOS notarization, and this release removes it from Electron Forge entirely.
- Minimum Node.js increased to v16.4.0: With this release, we’ve set the minimum required Node.js version to 16.4.0.
- Dropped support for
electron-prebuilt and electron-prebuilt-compile: electron-prebuilt was the original name for Electron’s npm module, but was replaced by electron in v1.3.1. electron-prebuilt-compile was an alternative to that binary that came with enhanced DX features, but was eventually abandoned as a project.
Points clés
- Google Cloud Storage publisher : Dans le cadre de nos efforts pour mieux soutenir la mise à jour automatique statique, Electron Forge prend maintenant en charge la publication directement dans Google Cloud Storage!
- ESM forge.config.js support: Electron Forge prend désormais en charge les fichiers ESM `forge.config.js. (P.S. Nous attendons avec impatience le support des points d'entrée ESM dans Electron 28. )
- Les fabricants fonctionnent maintenant en parallèle: Dans Electron Forge 6, les makers s'exécutaient séquentiellement pour ✨ raisons historiques héritées ✨ . Since then, we’ve tested out parallelization for the Make step with no adverse side effects, so you should see a speed-up when building multiple targets for the same platform!
🙇 Un grand merci à mahnunchik pour ses contributions au support de GCS Publisher et de l'ESM dans les configurations Forge!
Amélioration des mises à jour automatiques pour stockage statique
Squirrel.Windows and Squirrel.Mac are platform-specific updater technologies that back Electron’s built-in autoUpdater module. Both projects support auto updates via two methods:
- A Squirrel-compatible update server
- A manifest URL hosted on a static storage provider (e.g. AWS, Google Cloud Platform, Microsoft Azure, etc.)
The update server method has traditionally been the recommended approach for Electron apps (and provides additional customization of update logic), but it has a major downside—it requires apps to maintain their own server instance if they are closed-source.
On the other hand, the static storage method has always been possible, but was undocumented within Electron and poorly supported across Electron tooling packages.
With some great work from @MarshallOfSound, the update story for serverless automatic app updates has been drastically streamlined:
- Electron Forge’s Zip and Squirrel.Windows makers can now be configured to output
autoUpdater-compatible update manifests.
- A new major version of
update-electron-app (v2.0.0) can now read these generated manifests as an alternative to the update.electronjs.org server.
Once your Makers and Publishers are configured to upload update manifests to cloud file storage, you can enable auto updates with only a few lines of configuration:
const { updateElectronApp, UpdateSourceType } = require('update-electron-app');
updateElectronApp({
updateSource: {
type: UpdateSourceType.StaticStorage,
baseUrl: `https://my-manifest.url/${process.platform}/${process.arch}`,
},
});
L’univers étendu « @electron/
Au débuts d'Electron, la communauté a publié de nombreux packages pour améliorer l’expérience de développement, d’empaquetage et de distribution d’applications Electron. Au fil du temps, bon nombre de ces paquets ont été incorporés dans l'organisation GitHub d'Electron, l'équipe principale assumant le fardeau de la maintenance.
En 2022, nous avons commencé à unifier tous ces outils sous l’espace de noms « @electron/» sur npm. Ce changement signifie que les paquets qui étaient dans « electron-foo » sont maintenantsur npm dans « @electron/foo » et les dépôts qui étaient nommés « electron/electron-foo » sont maintenant « electron/foo » sur GitHub. Ces changements aident à délimiter clairement les projets initiaux des projets du userland. Cela inclut de nombreux paquets couramment utilisés, tels que:
@electron/asar@electron/fuses@electron/get@electron/notarize@electron/osx-sign@electron/packager@electron/rebuild@electron/remote@electron/symbolicate-mac@electron/universal
Going forward, all first-party packages we release will also be in the @electron/ namespace. There are two exceptions to this rule:
- Electron core will continue to be published under the
electron package.
- Electron Forge will continue to publish all of its monorepo packages under the
@electron-forge/ namespace.
⭐ During this process, we also accidentally took the electron/packager repository private, which has the unfortunate side effect of erasing our GitHub star count (over 9000 before the erasure). If you are an active user of Packager, we’d appreciate a ⭐ Star ⭐!
Introduction à @electron/windows-sign
À partir du 2023-06-01, les normes de l’industrie ont commencé à exiger que les clés des certificats de signature de code Windows soient stockées sur du matériel conforme à la FIPS.
En pratique, cela signifie que la signature de code est devenue beaucoup plus compliquée pour les applications qui compilent et signet des environnements d'intégration continue, car de nombreux outils Electron prennent un fichier de certificat et un mot de passe comme paramètres de configuration et tentent de signer à partir de là en utilisant une logique codée en dur.
This situation has been a common pain point for Electron developers, which is why we have been working on a better solution that isolates Windows code signing into its own standalone step, similar to what @electron/osx-sign does on macOS.
In the future, we plan on fully integrating this package into the Electron Forge toolchain, but it currently lives on its own. The package is currently available for installation at npm install --save-dev @electron/windows-sign and can used programmatically or via CLI.
Veuillez si vous le pouvez l’essayer et nous faire part de vos commentaires dans l’outil de suivi des problèmes de repo!
Et ensuite ?
We'll be entering our annual December quiet period next month. While we do, we'll be thinking about how we can make the Electron development experience even better in 2024.
Is there anything you'd like to see us work on next? Signalez-le nous!