A partir d'Electron 23. Electron mettra fin à la prise en charge de Windows 7, Windows 8 et Windows 8.1.

Conformément à la politique de dépréciation de Chromium, Electron mettra fin à la prise en charge de Windows 7, Windows 8 et Windows 8.1 à partir d'Electron 23. Ceci correspond à la fin du support de Microsoft pour Windows 7 ESU et Windows 8.1 extended le 10 janvier 2023.

Electron 22 sera la dernière version majeure d'Electron à prendre en charge les versions de Windows antérieures à 10. Windows 7/8/8.1 ne seront plus pris en charge dans les versions majeures d'Electron 23 et ultérieures. Les anciennes versions d'Electron continueront à fonctionner sous Windows 7, et nous continuerons à publier des correctifs pour Electron 22.x jusqu'au 30 mai 2023, date à laquelle Electron mettra fin à la prise en charge de 22.x (selon notre calendrier de support).

Pourquoi déprécier ?​

Electron suit la politique de dépréciation de Chromium qui va déprécier le support dans Chromium 109 (en savoir plus sur la timeline de Chromium ici). Electron 23 incluera Chromium 110, qui ne prendra pas en charge les anciennes versions de Windows.

Electron 22, qui contient lui, Chromium 108, sera donc la dernière version supportée.

Chronologie de la dépréciation​

Voici le calendrier prévu :

• Décembre 2022: L'équipe Electron entre dans une période calme pour les vacances
• Janvier 2023: Les problèmes liés à Windows 7 & 8 sont acceptés pour toutes les branches de version prises en charge.
• February 7 2023: Sortie d'Electron 23.
• 8 février 2023 - 29 mai 2023: Electron continuera à accepter des corrections pour les versions plus anciennes qu'Electron 23.
• 30 mai 2023: Electron 22 atteint la fin de son cycle de support.

Qu'est ce que cela signifie pour les développeurs :

• L'équipe d'Electron acceptera les problèmes et les corrections liés à Windows 7/8/8. pour les versions stables prises en charge jusqu'à ce que chacune atteigne la fin de son cycle de support.
  • Ceci s'applique spécifiquement pour Electron 22, Electron 21 et Electron 20.
• Les nouveaux problèmes liés à Windows 7/8/8.1 seront acceptés pour les versions d'Electron antérieures à Electron 23.
  • Les nouveaux problèmes liés ne seront plus acceptés pour toute nouvelle version.
• Une fois Electron 22 arrivé à la fin de son cycle de support, tous les problèmes existants liés à Windows 7/8/8.1 seront cloturés.

Et pour la suite​

N'hésitez pas à nous joindre sur info@electronjs.org si vous avez des questions ou des préoccupations. Vous pouvez également obtenir le support de la communauté dans notre Discord officiel d'Electron.

Le projet Electron fera une pause pour le mois de décembre 2022 et reviendra gonflé à bloc en janvier 2023.

via GIPHY

Ce qui ne changera pas en Décembre​

1. Les versions zero-day et autres versions majeures liées à la sécurité seront publiées si nécessaire. Les incidents de sécurité doivent être signalés via SECURITY.md.
2. Les Rapports du Code de Conduite et la modération se poursuivront.

Ce qui sera différent en Décembre​

1. Aucune nouvelle version stable en décembre. Pas de sorties Nightly et Alpha pour les deux dernières semaines de décembre.
2. À quelques exceptions près, il n'y aura pas de ré-éxamen de pull request ni de merge.
3. Aucune mise à jour de suivi de tickets sur aucun dépôt.
4. Aucune aide de débogage de la part des mainteneurs sur Discord.
5. Aucune mise à jour du contenu des réseaux sociaux.

Mais pourquoi donc?​

Après le succès du Mois silencieux de Décembre 2021, nous avons voulu rééditer pour 2022. Décembre continue d'être un mois calme pour la plupart des entreprises, nous voulons donc donner à nos mainteneurs une chance de se ressourcer. Tout le monde attend 2023 avec impatience, et nous nous attendons à de bonnes choses à venir! Nous encourageons les autres projets à envisager des mesures similaires.

Nous sommes très heureux de vous annoncer qu'Electron Forge v6.0.0 est maintenant disponible ! Cette nouvelle version est la première version majeure de Forge depuis 2018 et transfère le projet qui était dans electron-userland vers l'organisation principale electron sur Github.

Lisez donc la suite afin de découvrir ce qu'il y a de nouveau et comment vous pouvez adopter Electron Forge pour votre application!

Qu'est-ce qu'Electron Forge ?​

Electron Forge est un outil pour l'empaquetage et la ditribution des applications Electron. Il unifie l'écosystème d'outillage d'Electron en une seule interface extensible afin que tout le monde puisse se lancer dans la création d'applications Electron.

Les fonctionnalités principales comprennent :

• 📦 Empaquetage d'application et signature de code
• 🚚 Installateurs personnalisables pour Windows, macOS et Linux (DMG, deb, MSI, PKG, AppX, etc.)
• ☁️ Flux de publication automatique pour les fournisseurs de cloud (GitHub, S3, Bitbucket, etc.)
• ⚡ Modèles de structure standard de projet pour webpack et TypeScript faciles à utiliser
• ⚙️ Prise en charge des modules Node.js natifs
• 🔌 API Javascript Extensible

Quoi de neuf dans la v6 ?​

Ré-écriture totale​

Pour les versions de v1 à v5, Electron Forge était basée sur le projet, désormais abandonnée, electron-compile. Forge 6 est une ré-écriture complère du projet ayant une toute nouvelle architecture modulaire pouvant être étendue afin de satisfaire les besoins de toute application Electron.

Au cours des dernières années, Forge v6.0.0-beta a atteint la parité de fonctionnalités avec la v5 et le taux de perte de code a ralenti de façon spectaculaire, rendant l'outil prêt pour l'adoption générale.

Soutien technique officiel​

Historiquement, les responsables d'Electron restaient neutres quant aux outils de génération, laissant la tâche à divers paquets de la communauté. Cependant, avec l'évolution d'Electron en tant que projet, il est devenu plus difficile pour les nouveaux développeurs Electron de savoir quels outils ils ont besoin pour construire et distribuer leurs applications.

Pour aider les développeurs Electron dans le processus de distribution, nous avons décidé de faire de Forge le pipeline de construction officiel pour Electron.

Au cours de la dernière année, nous avons lentement intégré Forge dans la documentation officielle d'Electron, et nous avons récemment déplacé Forge de son ancien logis dans electron-userland/electron-forge pour l'installer dans le dépôt electron/forge. Maintenant, nous sommes enfin prêts à diffuser Electron Forge à un large public !

Premiers Pas​

Initialisation d'un nouveau projet Forge​

La mise en place d'un nouveau projet Electron Forge peut être fait en utilisant le script CLI create-electron-app.

yarn create electron-app my-app --template=webpack
cd my-app
yarn start

npm init electron-app@latest my-app -- --template=webpack
cd my-app
npm start

Le script va créer un projet Electron dans le dossier my-app avec un bundling complètement JavaScript et un pipeline de construction préconfiguré.

Pour plus d'informations, consultez le guide Getting Started dans la documentation de Forge.

Importation d'un projet existant​

Le CLI Electron Forge contient également une commande d'importation pour les projets Electron existants.

cd my-app
yarn add --dev @electron-forge/cli
yarn electron-forge import

cd my-app
npm install --save-dev @electron-forge/cli
npm exec --package=@electron-forge/cli -c "electron-forge import"

Lorsque vous utilisez la commande import , Electron Forge ajoutera quelques dépendances essentielles et créera une nouvelle configuration forge.config.js. Si vous avez un outil de compilation existant (par exemple, Electron Packager, Electron Builder, ou Forge 5), il essaiera de migrer autant de paramètres que possible. Certaines de vos configurations existantes pourront tout de même avoir besoin d'être migrées manuellement.

Des détails sur la migration manuelle peuvent être trouvés dans la documentation d'importation de Forge. Si vous avez besoin d'aide, veuillez vous rendre sur notre serveur Discord!

Pourquoi adopter Forge?​

Si vous avez déjà des outils pour empaqueter et publier votre application Electron, les avantages associés à l'adoption d'Electron Forge dépassent largement les tracas du basculement.

Nous pensons qu'il y a deux avantages majeurs à utiliser Forge:

1. Forge incorpore de nouvelles fonctionnalités pour la construction d'applications dès qu'elles sont prises en charge dans Electron. Dans de tes cas, vous n'aurez pas besoin avant la mise à niveau de câbler le support du nouvel outillage, ou attendre que ce support soit éventuellement implémenté par d'autres paquets . Pour des exemples récents, voir binaires universels macOS et vérification d'intégrité ASAR.

2. L'architecture multi-package de Forge en facilite la compréhension et l'extension. Puisque Forge est composé de nombreux packages plus petits aux responsabilités claires, il est plus facile de suivre le flux de code. De plus, La conception extensible de l'API de Forge signifie que vous pouvez écrire, pour les cas d'utilisation avancés, votre propre logique de compilation supplémentaire séparée des options de configuration fournies. Pour plus de détails sur l'écriture de plugins, makers et publishers personnalisés pour Forge, consultez la section Étendre Electron Forge de la documentation.

Dernières modifications​

Forge 6 a passé beaucoup de temps dans la phase bêta, et sa cadence de sortie s'est progressivement ralentie. Cependant, nous avons accéléré le développement dans la seconde moitié de 2022 et utilisé les dernières versions pour pousser quelques changements de rupture finaux avant la version stable v6.0.0.

Si vous êtes un utilisateur de la version bêta d'Electron Forge, consultez la Note de publication de v6.0.sur GitHub pour une liste des changements de rupture effectués dans les bêtas récentes (>=6.0.0-beta.65).

Une liste complète des modifications et des commits peut être trouvée dans CHANGELOG.md.

Envoyez vos commentaires!​

Dites-nous ce dont vous avez besoin ! L'équipe Electron Forge cherche toujours à améliorer le projet pour mieux répondre à ses utilisateurs.

Vous pouvez nous aider à améliorer Electron Forge en soumettant des demandes de fonctionnalités, en publiant des issues, ou simplement en nous informant de vos commentaires ! Vous pouvez également nous rejoindre sur le serveur officiel d'Electron Discord, où il y a un canal dédié aux discussions à propos d'Electron Forge.

Si vous voulez émettre des commentaires sur la documentation de Forge sur https://electronforge.io, nous avons une instance de GitBook synchronisée au dépôt electron-forge/electron-forge-docs.

Le mois dernier, le groupe des mainteneurs d'Electron s'est réuni à Vancouver, au Canada, pour discuter de la direction du projet pour 2023 et au-delà. Pendant plus de quatre jours dans une salle de conférence, les responsables de base et collaborateurs invités ont discuté des nouvelles initiatives, des points faibles de la maintenance et de la santé générale du projet.

Allant de l'avant, l'équipe se consacrera entièrement à la publication de mises à jour régulières et rapides de Chromium, à la correction des bogues ainsi qu'à rendre Electron plus sûr et performant pour tout le monde. Nous avons également quelques projets passionnants dans les travaux que nous aimerions partager avec la communauté !

Nouvelles API novatrices​

Les principales propositions d'API du projet Electron nécessitant un consensus passent par un processus de demande de commentaires (RFC) qui est révisé par les membres de notre groupe API Working Group.

Cette année, nous avons avancé deux propositions majeures ayant le potentiel de donner une nouvelle dimension aux capacités des applications Electron. Ces propositions sont hautement expérimentales, mais voici un avant-goût de ce à quoi cela ressemblerait !

Nouvelles améliorations natives des addons (API C)​

Cette proposition décrit une nouvelle couche d'API C pour Electron qui permettrait aux développeurs d'applications d'écrire leurs propres Addons Natifs pour Node s'interfaçant avec les ressources internes d'Electron. similaire à la propre Node-API de Node. Pour d'avantage d'informations sur la nouvelle API proposée voir ici.

Exemple: Booster des applications avec des ressources Chromium​

De nombreuses applications Electron maintiennent leurs propres forks pour interagir directement avec des fonctionnalités internes de Chromium qui serait autrement inaccessibles avec du pur Electron (non modifié). En exposant ces ressources dans la couche d'API C , ce code peut fonctionner en tant que module natif aux côtés d'Electron, réduisant les tâches de maintenance des développeurs d'applications.

Exposition de la couche UI de Chromium (API Views)​

Sous le capot, les parties non-web de l'interface utilisateur de Chromium(UI), telles que les barres d'outils, les onglets ou les boutons , sont construites avec un framework appelé Views. La proposition d'API Views introduit dans Electron, des parties de ce framework en tant que classes JavaScript , afin de permettre aux développeurs de créer des éléments d'UI non-web dans leurs applications Electron. Cela empêchera les applications d'avoir à bricoler le contenu web.

Les fondements nécessaires à ce nouvel ensemble d'API sont actuellement en cours de réalisation. Voici quelques-unes des premières choses auquelles vous pouvez vous attendre dans un futur proche.

Exemple : Refactorisation du modèle de fenêtre avec WebContentsView​

Notre premier changement prévu est d’exposer WebContentsView à l’API d’Electron, succédant ainsi à notre API BrowserView existante (et qui, malgré le nom, est du code spécifique à Electron sans lien avec les vues Chromium). Avec l'exposition de WebContentsView, nous disposerons d'un objet de vue réutilisable pouvant afficher un contenu Web et ouvrant la porte à une classe BrowserWindow en pur JavaScript pure réduisant davantage la complexité du code.

Bien que ce changement ne fournisse pas beaucoup de nouvelles fonctionnalités aux développeurs d'applications, c'est une refactorisation importante éliminant pas mal de code sous le capot, simplifantr les mises à jour de Chromium et réduisant le risque de nouvelles bogues apparaissant entre les versions majeures.

Si vous êtes un développeur d'Electron utilisant les BrowserViews dans votre application : ne vous inquiétez pas, nous ne vous avons pas oublié pour autant! Nous prévoyons de faire de la classe BrowserView existante un shim pour la WebContentsView afin d'amortir votre transition vers les nouvelles API.

Voir: electron/electron#35658

Exemple : Défilement du contenu web avec ScrollView​

Nos amis de chez Stack ont conduit un projet pour exposer le composant Chromium ScrollView à l'API d'Electron. Avec cette nouvelle API, n'importe quel composant View enfant peut être rendu scrollable horizontalement ou verticalement.

Même si cette nouvelle API remplit une fonctionnal restreinte, l'objectif final de l'équipe est de construire un ensemble de composants View utilitaires pouvant être utilisé comme boîte à outils pour construire des interfaces non-HTML plus complexes.

Contribuer​

Êtes-vous un développeur d'applications Electron intéressé par l'une de ces propositions d'API ? Bien que nous ne soyons pas prêt à recevoir de RFC supplémentaires, veuillez rester à l'écoute pour plus de détails à l'avenir!

Version stable d'Electron Forge v6​

Depuis la création de ce framework, l'écosystème des outils de génération d'Electron a été largement porté par la communauté et a consisté en de nombreux petits packages à vocation unique (e.g. electron-winstaller, electron-packager, electron-notarize, electron-osx-sign). Bien que ces outils fonctionnent très bien, il est intimidant pour les utilisateurs d'avoir à assembler un pipeline de construction fonctionnel.

Afin de rendre tout cela plus convivial pour les développeurs d'Electron, nous avons construit Electron Forge, une solution tout-en-un qui combine tous ces outils existants sous une seule interface. Bien que Forge soit en développement depuis 2017, le projet est resté en sommeil depuis quelques années. Cependant, considérant les commentaires de la communauté sur l'état des outils de compilation dans Electron, nous avons travaillé dur et publié la version majeure stable de Forge nouvelle génération.

Electron Forge 6 vient avec un support de premier ordre pour TypeScript et Webpack, ainsi qu'une API extensible permettant aux développeurs de créer leurs propres plugins et installateurs.

Restez à l'écoute : une annonce est à venir bientôt​

Si vous êtes intéressé à construire un projet avec Forge ou à construire des modèles ou des plugins avec les API tierces extensibles de Forge, Restez à l'écoute de notre annonce officielle sur la version stable de Forge v6 ce mois-ci !

Et ensuite ?​

Parallèlement à ce qui a été dit précèdemment, l'équipe est toujours en train de penser à un tas de projets exploratoires afin d'améliorer l'usage d'Electron pour les développeurs d'applications et les utilisateurs finaux. Les autres choses avec lesquelles nous expérimentons sont l'outil de mise à jour, le processus de révision de l'API, et l'amélioration de la documentation. Nous espérons avoir plus de nouvelles à partager dans un avenir proche !

Electron 21.0.0 est disponible ! Cette version inclut les mises à jour vers Chromium 106, V8 10.6, et Node.js 16.16.0. Lisez la suite ci-dessous pour plus de détails !

L'équipe d'Electron est heureuse d'annoncer la sortie d'Electron 21.0.0 ! Vous pouvez l'installer via npm install electron@latest ou la télécharger depuis notre site officiel. Vous obtiendrez plus de détails sur cette version en lisant ce qui suit.

Pour tout commentaire, veuillez partager avec nous sur Twitter, ou rejoindre notre communauté Discord! Les bogues et les demandes de fonctionnalités peuvent être signalés dans le traqueur de tickets d'Electron.

Changements notables​

Changements de la Stack​

• Chromium 106
  • Nouveautés de Chrome 106
  • Nouveautés de Chrome 105
  • Nouveautés de DevTools 106
  • Nouveautés de DevTools 105
• Node.js 16.16.0
  • Article de blog sur Node 16.16.0
• V8 10.6

Nouvelles fonctionnalités​

• Ajout de webFrameMain.origin. #35534
• Ajout de nouvelles API WebContents.ipc et WebFrameMain.ipc. #35231
• Ajout de la prise en charge des comportements de type panel. Une fenêtre peut flotter au dessus des applications plein écran. #34388
• Ajout de la prise en charge du push de notifications des APN pour les applications macOS. #33574

Modifications & changements majeurs de l’API​

Vous trouverez ci-dessous les changements majeurs introduits dans Electron 21.

Activation de la Cage mémoire de V8​

Electron 21 permet les pointeurs V8 en bac à sable, suite à la décision de Chrome de faire de même dans Chrome 103. Cela a des implications pour les modules natifs. Cette fonctionnalité présente des avantages en termes de performances et de sécurité, mais impose également de nouvelles restrictions aux modules natifs, par exemple l’utilisation de ArrayBuffers qui pointent vers de la mémoire externe (« hors tas »). Veuillez consulter ce billet du blog pour plus d'informations. #34724

Restructuration de webContents.printToPDF​

webContents.printToPDF a été revu pour s'aligner sur l'implémentation Chromium sans affichage. Voir #33654 pour plus d'informations.

Vous trouverez plus d’informations sur ces changements et les changements futurs sur la pagechangements de rupture prévus.

Fin du support pour 18.x.y​

Electron 18.x.y a atteint la limite pour le support conformément à la politique d'assistance du projet. Nous encourageons les développeurs à mettre à jour vers une version plus récente d'Electron et de faire de même avec leurs applications.

Pour la suite​

À court terme, vous pouvez compter sur l’équipe pour continuer a se concentrer sur le développement des principaux composants qui composent Electron, notamment Chromium, Node et V8.

Vous pouvez trouver la chronologie publique d'Electron ici.

Vous trouverez plus d’informations sur les changements futurs sur la page changements de rupture prévus.

Electron 20.0.0 est disponible ! Cette version inclue les mises à jour vers Chromium 104, V8 10.4, et Node.js 16.15.0. Lisez la suite ci-dessous pour plus de détails !

L'équipe d'Electron est heureuse d'annoncer la sortie d'Electron 20.0.0 ! Vous pouvez l'installer via npm install electron@latest ou le télécharger depuis notre site officiel. Lisez la suite pour plus de détails sur cette version et veuillez partagez vos commentaires et remarques !

Changements notables​

Nouvelles fonctionnalités​

• Ajout du mode sombre immersif sous Windows. #34549
• Ajout de la prise en charge des comportements de type panel. Une fenêtre peut flotter au dessus des applications plein écran. #34665
• Mise à jour des boutons Windows de controle en overlay pour un affichage plus proche du mode natif sur Windows 11. #34888
• Les moteurs de rendu sont désormais mis en bac à sable (sandbox) par défaut, sauf si nodeIntegration: true ou sandbox: false est spécifié. #35125
• Ajout de protections lors de la construction de modules natifs avec nan. #35160

Changements de la Stack​

• Chromium 104
  • Nouveau avec Chrome 104
  • Nouveau avec Chrome 103
  • Nouveautés de DevTools
• Node.js 16.15.0
  • Article de blog sur Node 16.15.0
• V8 10.4

Modifications et changement majeurs de l’API​

Vous trouverez ci-dessous les changements majeurs introduits dans Electron 20. Vous trouverez plus d’informations sur ces changements et les changements futurs sur la pagechangements de rupture prévus.

Modification de valeur par défaut : les renderers sans nodeIntegration: true sont mis par défaut en bac à sable​

Auparavant, les moteurs de rendu (renderers) qui spécifiaient un script de préchargement n'étaient pas par défaut mis en bac à sable. Cela signifiait que par défaut, les scripts de préchargement avaient accès à Node.js. Dans Electron 20, cette valeur par défaut a changé. À partir d’Electron 20, les moteurs de rendu seront mis en bac à sable par défaut, sauf si nodeIntegration: true ou sandbox: false sont spécifiés.

Si vos scripts de préchargement ne dépendent pas de Node, aucune action n’est nécessaire. Par contre si vos scripts de préchargement dépendent de Node, refactorisez-les pour supprimer l’utilisation de Node du moteur de rendu ou spécifiez explicitement sandbox: false pour les moteurs de rendu appropriés.

Correction : plantage spontané dans les modules natifs nan​

Dans Electron 20, nous avons modifié deux éléments liés aux modules natifs :

1. Les en-têtes V8 utilisent désormais c++17 par défaut. Ce drapeau a été ajouté à electron-rebuild.
2. Nous avons corrigé un problème où un include manquant provoquait un plantage spontané dans les modules natifs qui dépendaient de nan.

Pour plus de stabilité, nous vous recommandons d’utiliser node-gyp >= 8.4.0 et electron-rebuild >= 3.2.9 lors de la reconstruction de modules natifs, en particulier les modules qui dépendent de nan. Voir électronique #35160 et node-gyp #2497 pour plus d’informations.

Supprimé : .skipTaskbar sous Linux​

Sur X11, skipTaskbar envoie un message de _NET_WM_STATE_SKIP_TASKBAR au gestionnaire de fenêtres X11. Il n'y a pas d'équivalent direct pour Wayland, et les contournements connus ont des compromis inacceptables (par ex. Window.is_skip_taskbar dans GNOME nécessite un mode dangereux), donc Electron n'est pas en mesure de supporter cette fonctionnalité sous Linux.

Fin du support pour 17.x.y​

Electron 17.x.y a atteint la limite pour le support conformément à la politique d'assistance du projet. Nous encourageons les développeurs à mettre à jour vers une version plus récente d'Electron et de faire de même avec leurs applications.

Pour la suite​

À court terme, vous pouvez vous attendre à ce que l’équipe continue de se concentrer sur le développement des principaux composants qui composent Electron, y compris Chromium, Node et V8. Bien que nous veillions à ne pas trop faire de promesses concernant les dates de publication, notre plan est de publier de nouvelles versions majeures d'Electron avec de nouvelles versions de ces composants environ tous les 2 mois.

Vous pouvez trouver la chronologie publique d'Electron ici.

Vous trouverez plus d’informations sur les changements futurs sur la page changements de rupture prévus.

Electron 21 et les versions ultérieures auront la cage de mémoire V8 activée, avec des implications pour certains modules natifs.

Electron 21 permet les pointeurs V8 en bac à sable, suite à la décision de Chrome de faire de même dans Chrome 103. Cela a des implications pour les modules natifs. De plus, nous avons précédemment, dans Electron 14, activé une technologie connexe, la compression de pointeur. Nous n'en avons pas beaucoup parlé sur le moment, mais la compression de pointeur a des implications sur la taille maximale du tas de V8.

Ces deux technologies, lorsqu'elles sont activées, sont significativement bénéfiques pour la sécurité, les performances et l'utilisation de la mémoire. Mais leur activation présente également des inconvénients.

L'inconvénient principal de l'activation des pointeurs dans un bac à sable est que les ArrayBuffers qui pointent vers la mémoire externe (« hors tas ») ne sont plus autorisés. Cela signifie que les modules natifs qui dépendent de cette fonctionnalité dans V8 devront être refactorisés pour continuer à fonctionner dans Electron 20+.

L'inconvénient principal de l'activatiçon de la compression de pointeur est que le tas de V8 est limité à une taille maximale de 4Go. Les détails exacts sont un peu compliqués — par exemple, Les ArrayBuffers sont comptés séparément du reste du tas V8, mais ont leurs propres limites.

Le Groupe de travail Electron Upgrades considère que les avantages de la compression de pointeur et de la cage mémoire de V8 l'emportent sur les désavantages. Il y a trois raisons principales à cela :

1. Cela conserve Electron plus proche de Chromium. Moins Electron se différencie de Chromium dans des détails internes complexes tels que la configuration de V8, moins nous avons de chances d'introduire accidentellement des bogues ou des vulnérabilités de sécurité. L'équipe de sécurité de Chromium est formidable, et nous voulons nous assurer que nous tirons parti de leur travail. De plus, si un bogue affecte uniquement des configurations qui ne sont pas utilisées dans Chromium, sa correction n'est pas susceptible d'être une priorité pour l'équipe Chromium.
2. Cela assure de meilleures performances. La compression de pointeur réduit la taille du tas de V8 jusqu'à 40% et améliore les performances du processeur et du GC de 5 à 10%. Pour la grande majorité des applications Electron qui n'atteindront pas dans la limite de taille de tas de 4 Go et n'utilisent pas de modules natifs nécessitant les buffers externes, ce sont des gains de performance significatifs.
3. C'est plus sûr. Certaines applications Electron exécutent du JavaScript non fiable (en suivant, nous l'espérons, nos recommandations de sécurité !), et, pour ces applications, l'activation de la cage mémoire de V8 protège contre une grande classe de vulnérabilités pernicieuses de V8.

Enfin, il y a des solutions pour les applications qui ont vraiment besoin d'une taille de tas supérieure. Par exemple, il est possible d'inclure avec votre application une copie de Node.js générée avec la compression de pointeur désactivée, et de déplacer le travail nécéssitant beaucoup de mémoire vers un processus enfant. Bien que ce soit quelque peu compliqué, il est également possible de construire une version personnalisée d'Electron avec la compression de pointeur désactivée, si vous décidez d'avoir un compromis différent répondant à votre cas d'utilisation. Et enfin, dans un avenir pas si lointain, wasm64 permettra aux applications construites avec WebAssembly, sur le Web et dans Electron, d'utiliser beaucoup plus que 4 Go de mémoire.

FAQ​

Comment savoir si mon application est affectée par ce changement ?​

Tenter d'encapsuler la mémoire externe dans un ArrayBuffer causera un plantage à l'exécution, dans Electron 20+.

Si vous n'utilisez aucun module Node natif dans votre application, vous n'êtes pas concernés — il n'y a aucun moyen de déclencher ce plantage exclusivement avec JS. Ce changement n'affecte que les modules natifs de Node qui allouent de la mémoire en dehors du tas de V8 (ex : en utilisant malloc ou new) puis encapsulent la mémoire externe dans un ArrayBuffer. C'est un cas d'utilisation assez rare, mais certains modules utilisent cette technique, et devront être refactorisés afin d'être compatibles avec Electron 20+.

Comment puis-je mesurer la quantité de mémoire de tas V8 que mon application utilise pour savoir si je suis proche de la limite de 4Go ?​

Dans le processus de rendu, vous pouvez utiliser performance.memory.usedJSHeapSize, qui retournera l'utilisation du tas de V8 en octets. Dans le processus principal, vous pouvez utiliser process.memoryUsage().heapUsed, qui est comparable.

Qu'est-ce que la cage mémoire de V8 ?​

Certains documents l'appellent "le bac à sable V8", mais ce terme peut être confondu facilement avec d'autres types de bac à sable présents dans Chromium, donc je m'en tiendrai au terme "cage mémoire".

Voici un type assez courant d'exploitation de failles de V8 :

1. Trouver un bogue dans le moteur JIT de V8. Les moteurs JIT analysent le code afin de pouvoir omettre les vérifications lentes de type à l'exécution afin de produire du code machine rapide. Parfois, des erreurs de logique signifient que cette analyse est erronée, et causent l'omission d'une vérification de type qui est réellement nécessaire — par exemple, il pense que x est une chaîne alors que c'est en fait un objet.
2. Abuser de cette confusion pour écraser quelque octets de mémoire dans le tas de V8, par exemple, un pointeur vers le début d'un ArrayBuffer.
3. Maintenant vous avez un ArrayBuffer qui pointe où vous voulez, ce qui permet de lire et écrire à n'importe quel emplacement mémoire dans le processus, y compris de la mémoire à laquelle V8 n'a normalement pas accès.

La cage mémoire de V8 est une technique conçue pour prévenir catégoriquement ce type d'attaque. Cela est accompli en ne stockant aucun pointeur dans le tas de V8. Au lieu de cela, toutes les références à une autre mémoire dans le tas de V8 sont stockées sous forme d'offset à partir du début d'une région réservée. Ensuite, même si un attaquant parvient à corrompre l'adresse de début d'un ArrayBuffer, par exemple en exploitant dans V8 une erreur de confusion de type , il ne pourra, au pire, que de lire et écrire de la mémoire dans la cage, ce qu'il pouvait probablement déjà faire. Il y a beaucoup plus de choses à lire sur le fonctionnement de la cage mémoire de V8, je n'entrerai donc pas dans les détails ici — le meilleur endroit est pour commencer probablement le document de design de haut niveau de l'équipe Chromium.

Je veux refactoriser un module natif de Node pour supporter Electron 21+. Comment faire ?​

Il y a deux façons de refactoriser un module natif pour qu'il soit compatible avec la cage mémoire de V8. La première est de copier les tampons créés en externe dans la cage mémoire de V8 avant de les passer à JavaScript. C'est généralement une refactorisation simple, mais qui peut introduire des lenteurs lorsque les tampons sont importants. L'autre approche est d'utiliser l'allocateur de mémoire de V8 pour allouer la mémoire que vous avez l'intention de passer à JavaScript. C'est un peu plus complexe, mais évitera la copie, ce qui signifie une meilleure performance pour les tampons de grande taille.

Pour rendre cela plus concret, voici un exemple de module N-API qui utilise des tableaux externes de tampons :

// Créer un tampon alloué dans la mémoire externe.
// |create_external_resource| alloue de la mémoire via malloc().
size_t length = 0;
void* data = create_external_resource(&length);
// Encapsulation dans un Buffer — échouera si la cage mémoire est activée!
napi_value result;
napi_create_external_buffer(
    env, length, data,
    finalize_external_resource, NULL, &result);

Cela va planter si la cage mémoire est activée, car les données sont allouées en dehors de la cage. En refactorisant pour copier les données dans la cage, nous obtenons :

size_t length = 0;
void* data = create_external_resource(&length);
// Créer un nouveau Buffer en copiant les données dans la mémoire allouée à V8
napi_value result;
void* copied_data = NULL;
napi_create_buffer_copy(env, length, data, &copied_data, &result);
// Pour accéder à la nouvelle copie, |copied_data| est un pointeur vers 
// cette copie!

Cela copiera les données dans une zone de mémoire nouvellement allouée contenue dans la cage mémoire de V8. De manière optionnelle, N-API peut également fournir un pointeur vers les données nouvellement copiées, au cas où vous auriez besoin de les modifier ou de les référencer après initialisation.

Refactoriser pour utiliser l'allocateur de mémoire de V8 est un peu plus compliqué, puisqu'il nécessite de modifier la fonction create_external_resource pour utiliser la mémoire allouée par V8, au lieu de malloc. Cela peut être plus ou moins faisable, selon que vous contrôlez ou non la définition de create_external_resource. L'idée est dans un premier temps de créer le tampon en utilisant V8, par exemple avec napi_create_buffer, puis d'initialiser la ressource dans la mémoire allouée par V8. Il est important de conserver un napi_ref à l'objet Buffer pour la durée de vie de la ressource, sinon, V8 peut expulser le Buffer au travers du ramasse-miette et entraîner potentiellement des erreurs d'utilisation de mémoire libérée.

Electron 19.0.0 est disponible ! Cette version inclue les mises à jour vers Chromium 102, V8 10.2, et Node.js 16.14.2. Lisez la suite ci-dessous pour plus de détails !

La team Electron est excitée d'annoncer la sortie de Electron 19.0.0 ! Vous pouvez l'installer via npm install electron@latest ou le télécharger depuis notre site officiel. Lisez la suite pour plus de détails sur cette version et veuillez partagez vos commentaires et remarques !

Changements notables​

Changement de le cadence de publication d'Electron​

The project is returning to its earlier policy of supporting the latest three major versions. See our versioning document for more detailed information about Electron versioning and support. This had temporarily been four major versions to help users adjust to the new release cadence that began in Electron 15. Vous pouvez lire les détails complets ici.

Changements de la Stack​

• Chromium 102
  • Nouveau avec Chrome 102
  • Nouveau avec Chrome 101
• Node.js 16.14.2
  • Article de blog sur Node 16.14.2
• V8 10.2

Modifications & changements majeurs de l’API​

Vous trouverez ci-dessous les changements de rupture introduits dans Electron 19. Vous trouverez plus d’informations sur ces changements et les changements futurs sur la pagechangements de rupture prévus.

Unsupported on Linux: .skipTaskbar​

The BrowserWindow constructor option skipTaskbar is no longer supported on Linux. Changed in #33226

Removed WebPreferences.preloadURL​

The semi-documented preloadURL property has been removed from WebPreferences. #33228. WebPreferences.preload should be used instead.

End of Support for 15.x.y and 16.x.y​

Electron 14.x.y and 15.x.y have both reached end-of-support. This returns Electron to its existing policy of supporting the latest three major versions. Nous encourageons les développeurs à mettre à jour vers une version plus récente d'Electron et de faire de même avec leurs applications.

Et maintenant ?​

À court terme, vous pouvez compter sur l’équipe pour continuer a se concentrer sur le développement des principaux composants qui composent Electron, notamment Chromium, Node et V8. Bien que nous veillions à ne pas faire trop de promesses concernant les dates de publication, notre plan est de publier de nouvelles versions majeures d'Electron avec de nouvelles versions de ces composants environ tous les 2 mois.

Vous pouvez trouver la chronologie publique d'Electron ici.

Vous trouverez plus d’informations sur les changements futurs sur la page changements de rupture prévus.

Electron is changing its primary S3 bucket, you may need to update your build scripts

What is happening?

A significant amount of Electron's build artifacts are uploaded to an S3 bucket called gh-contractor-zcbenz. As part of ongoing infrastructure/ownership migrations that started way back in 2020, we will be changing everything that used gh-contractor-zcbenz from its old home in S3 to a new storage system hosted at https://artifacts.electronjs.org. The path prefix that most of our assets use is changing slightly as well. Examples are included below:

Avant : https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/dist/v17.0.0/node.lib Après : https://artifacts.electronjs.org/headers/dist/v17.0.0/node.lib

The important things here are the Hostname changed and the /atom-shell prefix changed. Another example, this time for debug symbols:

Avant : https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/symbols/path/to/symbol.pdb Après : https://artifacts.electronjs.org/symbols/path/to/symbol.pdb

Again, the hostname changed and the /atom-shell prefix was changed.

How might this impact you?

Anyone using standard build tooling such as electron-rebuild, electron-packager or @electron/get won't have to do anything. This should be the majority of people.

For anyone directly referencing the S3 bucket, you must update your reference to point at the hostname and update the path as well.

What about existing data?

Most data that existed on the gh-contractor-zcbenz bucket has been cloned into the new storage system. This means all debug symbols and all headers have been copied. If you relied on some data in that bucket that hasn't been copied over please raise an issue in electron/electron and let us know.

The current gh-contractor-zcbenz S3 bucket will not be actively deleted. However, we can't guarantee how long that bucket will be left alive. We strongly recommend updating to target the new bucket as soon as possible.

Electron 18.0.0 est disponible ! Cette version inclue les mises à jour vers Chromium 100, V8 10.0, et Node.js 16.13.2. Lisez la suite ci-dessous pour plus de détails !

La team Electron est excitée d'annoncer la sortie de Electron 18.0.0 ! Vous pouvez l'installer via npm install electron@latest ou le télécharger depuis notre site officiel. Lisez la suite pour plus de détails sur cette version et veuillez partagez vos commentaires et remarques !

Changements notables​

Changement de le cadence de publication d'Electron​

À partir d'Electron 15, Electron publiera une nouvelle version stable majeure toutes les 8 semaines. Vous pouvez lire les détails complets ici.

De plus Electron passera des trois dernières versions supportées aux quatre dernières versions jusqu'en mai 2022. Consultez notre document de gestion des versions pour plus d’informations sur le contrôle de version dans Electron. Après Electron 2022, nous reviendrons à supporter les trois dernières versions.

Changements de la Stack​

• Chromium 100
  • Nouveau avec Chrome 100
• Node.js 16.13.2
  • Article de blog sur Node 16.13.2
• V8 10.0

Nouveautés de cette version​

• Added ses.setCodeCachePath() API for setting code cache directory. #33286
• Removed the old BrowserWindowProxy-based implementation of window.open. This also removes the nativeWindowOpen option from webPreferences. #29405
• Added 'focus' and 'blur' events to WebContents. #25873
• Added Substitutions menu roles on macOS: showSubstitutions, toggleSmartQuotes, toggleSmartDashes, toggleTextReplacement. #32024
• Ajout d'un événement first-instance-ack au flux app.requestSingleInstanceLock() , permettant aux utilisateurs de transmettre de façon transparente des données de la première instance à la seconde instance. #31460
• Added support for more color formats in setBackgroundColor. #33364

Voir les notes de version 18.0.0 pour une liste complète des nouvelles fonctionnalités et des modifications.

Modifications & changements majeurs de l’API​

Vous trouverez ci-dessous les changements de rupture introduits dans Electron 18. Vous trouverez plus d’informations sur ces changements et les changements futurs sur la pagechangements de rupture prévus.

Supprimé : nativeWindowOpen​

Avant Electron 15, window.open utilisait par défaut BrowserWindowProxy. Cela signifiait, entre autres incompatibilités, que window.open('about:blank') ne fonctionnait pas pour ouvrir des fenêtres enfants scriptables de manière synchrone. Depuis Electron 15, nativeWindowOpen est activé par défaut.

See the documentation for window.open in Electron for more details. Removed in #29405

Fin du support pour 14.x.y​

Electron 14.x.y a atteint la limite pour le support conformément à la politique d'assistance du projet. Nous encourageons les développeurs à mettre à jour vers une version plus récente d'Electron et de faire de même avec leurs applications.

À partir d'Electron 15, nous passeront de trois dernières versions supportées aux quatre dernières versions jusqu'en mai 2022 avec Electron 19. Après Electron 19, nous reviendrons à supporter les trois dernières versions. Cette version de support du changement fait partie de notre nouveau changement de cadence. Veuillez consulter notre article de blog pour plus de détails ici.

Et maintenant ?​

À court terme, vous pouvez compter sur l’équipe pour continuer a se concentrer sur le développement des principaux composants qui composent Electron, notamment Chromium, Node et V8. Bien que nous veillions à ne pas faire trop de promesses concernant les dates de publication, notre plan est de publier de nouvelles versions majeures d'Electron avec de nouvelles versions de ces composants environ tous les 2 mois.

Vous pouvez trouver la chronologie publique d'Electron ici.

Vous trouverez plus d’informations sur les changements futurs sur la page changements de rupture prévus.