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
- Passé à
notarytool pour la macOS notarization : À partir de 2023-11-01, Apple sunset l''ancien altool pour la macOS notarization, et cette version le retire d'Electron Forge entièrement.
- Node.js minimum augmenté à v16.4.0 : Avec cette version, nous avons défini la version minimale requise de Node.js à 16.4.0.
- Abandonné le support de
electron-prebuilt et electron-prebuilt-compile: electron-prebuilt était le nom original du module npm d'Electron, mais a été remplacé par electron dans la v1.3.1. electron-prebuilt-compile était une alternative à ce binaire qui apportait des fonctionnalités DX améliorées, mais fut finalement abandonné en tant que projet.
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 ✨ . Depuis, nous avons testé la parallélisation de l'étape Make sans effets secondaires négatifs, donc vous devriez voir une accélération lors de la construction de plusieurs cibles pour la même plateforme !
🙇 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 et Squirrel.Mac sont des technologies de mise à jour spécifiques à la plate-forme qui soutiennent le module autoUpdater intégré d'Electron. Les deux projets prennent en charge les mises à jour automatiques via deux méthodes :
- Un serveur de mise à jour compatible avec Squirrel
- Un manifest URL est hébergée sur un fournisseur de stockage statique (ex : AWS, Google Cloud Platform, Microsoft Azure, etc.)
La méthode du serveur de mise à jour a traditionnellement été l'approche recommandée pour les applications Electron (et fournit une personnalisation supplémentaire de la logique de mise à jour), mais il a un inconvénient majeur — il faut que les applications maintiennent leur propre instance de serveur si elles sont fermées.
D'un autre côté, la méthode de stockage statique a toujours été possible, mais n'a pas été documentée dans Electron et mal supportée dans les paquets d'outillage d'Electron.
Avec un excellent travail de @MarshallOfSound, l'histoire de mise à jour pour les mises à jour automatiques des applications sans serveur a été considérablement rationalisée :
- Les créateurs de Zip et Squirrel.Windows d'Electron Forge peuvent maintenant être configurés pour afficher les événements de mise à jour compatibles avec
autoUpdater.
- Une nouvelle version majeure de
update-electron-app (v2.0.0) peut maintenant lire ces manifestes générés comme alternative au serveur update.electronjs.org.
Une fois que vos Makers et Publishers sont configurés pour télécharger des manifestes de mise à jour vers le stockage de fichiers dans le cloud, vous pouvez activer les mises à jour automatiques avec seulement quelques lignes de 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
Pour aller de l'avant, tous les paquets de première partie que nous publions seront également dans l'espace de noms @electron/. Il y a deux exceptions à cette règle :
- Le noyau d'Electron continuera d'être publié dans le paquet
electron.
- Electron Forge continuera à publier tous ses paquets monorepo dans l'espace de noms
@electron-forge/.
⭐ Au cours de ce processus, nous avons également accidentellement pris le dépôt electron/packager en privé, qui a l'effet secondaire malheureux d'effacer notre compte d'étoiles GitHub (plus de 9000 avant l'effacement). Si vous êtes un utilisateur actif de Packager, nous apprécierions un ⭐ 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.
Cette situation a été un point de douleur courant pour les développeurs d'Electron, c'est pourquoi nous avons travaillé sur une meilleure solution qui isole la signature du code Windows dans sa propre étape autonome. similaire à ce que @electron/osx-sign fait sur macOS.
Dans le futur, nous prévoyons d'intégrer complètement ce paquet dans la toolchain d'Electron Forge, mais il vit tout seul. Le paquet est actuellement disponible pour l'installation à npm install --save-dev @electron/windows-sign et peut être utilisé par programmation ou 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 ?
Nous entrerons dans notre période annuelle de repos de décembre le mois prochain. Pendant que nous le faisons, nous réfléchirons à la manière dont nous pouvons améliorer l'expérience de développement d'Electron en 2024.
Y a-t-il quelque chose que vous aimeriez que nous fassions travailler sur la suite ? Signalez-le nous!
