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

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 normalement.

Ce qui sera différent en Décembre​

1. Les dernières versions de la branche stable de l'année 2024, dont Electron 31, 32 et 33, auront lieu la semaine du 1er décembre. Il n'y aura pas de nouvelles sorties prévues en décembre.
2. Pas de sorties Nightly et Alpha pour les deux dernières semaines de décembre.
3. À quelques exceptions près, il n'y aura pas de ré-éxamen de pull request ni de merge.
4. Aucune mise à jour de suivi de tickets sur aucun dépôt.
5. Aucune aide de débogage de la part des mainteneurs sur Discord.
6. Aucune mise à jour du contenu des réseaux sociaux.

On se revoit en 2025!

L'équipe du projet Electron fera une pause pour le mois de décembre 2023 et reviendra gonflée à bloc en janvier 2024.

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 normalement.

Ce qui sera différent en Décembre​

1. Electron 28.0.0 sortira le 5 décembre. Pour la suite, il n'y aura pas de nouvelles versions stables avant Janvier.
2. Pas de sorties Nightly et Alpha pour les deux dernières semaines de décembre.
3. À quelques exceptions près, il n'y aura pas de ré-éxamen de pull request ni de merge.
4. Aucune mise à jour de suivi de tickets sur aucun dépôt.
5. Aucune aide de débogage de la part des mainteneurs sur Discord.
6. Aucune mise à jour du contenu des réseaux sociaux.

A l'avenir​

Nous expérimentons cette période silencieuse depuis maintenant trois ans et l'équilibre entre un mois de repos et le maintien le reste du temps de notre cadence normale de sorties de version nous a plutôt réussi. Nous avons donc décidé d'inclure cette procédure à notre calendrier de publication. Cependant nous emettrons toujours un rappel lors de la dernière version stable de chaque année civile.

On se revoit en 2024!

Le premier commit dans le dépôt electron/electron date du 13 mars 2013¹.

10 ans et 27 147 commits supplémentaires de 1192 contributeurs uniques plus tard, Electron est devenu l'un des frameworks les plus populaires pour la construction d'applications de bureau aujourd'hui. Ce étape importante est l'occasion parfaite de célébrer et de réfléchir au parcours effectué jusqu’à maintenant, et de partager ce que nous avons appris au fil du temps.

Nous ne serions pas ici aujourd’hui sans tous ceux qui ont consacré leur temps et leurs efforts à ce projet. Bien que les commits de code source soient toujours les contributions les plus visibles, nous devons également saluer les efforts des personnes qui signalent les bogues, tiennent à jour les modules d’utilisateur, fournissent de la documentation et des traductions, et participent à la communauté Electron à travers le cyberespace. Chaque contribution est inestimable pour nous en tant que responsables.

Avant de continuer avec le reste du billet : un grand merci. ❤️

Comment en sommes-nous arrivés là?​

Atom Shell a été construit pour être la colonne vertébrale de l’éditeur Atom de GitHub, présenté au public en version bêta en avril 2014. Construit en partant de zéro comme une alternative aux framework de bureau basé sur le web disponibles à l’époque (node-webkit et Chrome Embedded Framework). Son aspect le plus remarquable etait d' intégrer Node.js et Chromium pour fournir un environnement d’exécution de bureau puissant aux technologies web.

En moins d’un an, Atom Shell a commencé à voir une croissance très importante en terme de capacités et de popularité. Les grandes entreprises, les startups et les développeurs individuels ont commencé à l'utiliser pour construire des applications (parmi les premiers utilisateurs figurent Slack, GitKraken et WebTorrent), et le projet a été renommé judicieusement Electron.

A partir de ce moment, Electron a démarré sur les chapeaux de roue et ne s'est jamais arrêté. Voici un aperçu de notre decompte hebdomadaire de téléchargements au fil du temps, c'est une gracieuseté de npmtrends.com :

Electron v1 a été publié en 2016, promettant une meilleure stabilité de l'API et de meilleurs outils et documentation. Electron v2 a été publié en 2018 et a introduit le versionnage sémantique, ce qui permet aux développeurs d'Electron de garder une trace du cycle de publication.

Avec Electron v6, nous sommes passés à une cadence régulière de 12 semaines pour s'aligner sur celle de Chromium. Cette décision a été un changement de mentalité pour le projet, le fait d'avoir la version Chromium la plus à jour passant d'un souhait à une priorité. Cela a réduit la dette technologique entre les mises à niveau, ce qui nous a permis de garder Electron à jour et sécurisé.

Depuis lors, la machine tourne bien avec une nouvelle version Electron publiée le même jour que Chromium pour chaque version stable. Lorsque Chromium a accéléré sa cadence de libération en passant à 4 semaines en 2021, nous avons modifié sans problème la notre en conséquence.

Nous sommes maintenant à Electron v23 et nous sommes toujours dédiés à construire le meilleur runtime pour créer des applications de bureau multiplateformes. Même avec l'explosion du nombre d'outils de développement JavaScript ces dernières années, Electron est resté un pilier stable et éprouvé de la conception d'application pour bureau. Les applications Electron sont omniprésentes de nos jours : vous pouvez programmer avec Visual Studio Code, concevoir avec Figma, communiquez avec Slack, et prendre des notes avec Notion (entre autres choses). Nous sommes incroyablement fiers de ce résultat et nous sommes reconnaissants envers tous ceux qui ont rendus ce projet possible.

Qu’avons-nous appris en cours de route?​

Le chemin pour atteindre cette décennie a été long et sinueux. Voici quelques éléments clés qui nous ont aidés à gérer ce grand projet open source de façon durable.

Redimensionnement de la prise de décision répartie avec un modèle de gouvernance​

Un des défis que nous avons dû surmonter était de gérer la direction à long terme du projet lorsque la popularité d'Electron a explosé. Comment gérer le projet avec une équipe de quelques dizaines d’ingénieurs répartis dans différentes entreprises, dans différents pays et sous différents fuseaux horaires?

Dans les premiers temps, le groupe de mainteneurs d’Electron s'est fié à une coordination informelle, qui était rapide et légere pour les petits projets, mais ne pouvait pas s'adapter à une collaboration plus large. En 2019, nous sommes passés à un modèle de gouvernance avec différents groupes de travail ayant des domaines de responsabilité officiels. Cela a été déterminant pour la rationalisation des processus et l’attribution de de certaines parties du projet à des responsables spécifiques. Voici, de nos jours, la répartition des responsabilités des groupes de travail (GT):

• Assurer la publication des versions d'Electron (Releases WG)
• Mettre à jour Chromium et Node.js (Upgrades WG)
• Surveiller la conception de l'API publique (API WG)
• Garder Electron sécurisé (Security WG)
• Gérer le site Web, la documentation et l'outillage (Ecosystem WG)
• Sensibiliser les communautés et les entreprises (Outreach WG)
• Effectuer la modération de la communauté (Community & Safety WG)
• Maintenir notre infrastructure de compilation, nos outils pour les mainteneurs et nos services de cloud (Infrastructure WG)

À peu près en même temps que nous adoptions le modèle de gouvernance, nous avons également transféré la propriété d’Electron de GitHub à la Fondation OpenJS. Bien que l'équipe de base initiale travaille toujours chez Microsoft aujourd'hui, elle ne représente qu'une partie d'un groupe plus large de collaborateurs qui forment la gouvernance d'Electron.²

Bien que ce modèle ne soit pas parfait, il nous a convenu même pendant la traversée d'une pandémie mondiale et de vents macroéconomiques contraires . Pour le futur, nous prévoyons de réorganiser la charte de gouvernance pour qu'elle nous guide tout au long de la deuxième décennie d'Electron.

Communauté​

La partie communautaire d'un projet open source est un peu compliquée à gérer, surtout lorsque votre équipe de sensibilisation est composée d’une douzaine d’ingénieurs en trench indiquant « community manager ». Cela dit, étant un grand projet open source signifie d'avoir un gran nombre d'utilisateurs, et l'exploitation de leur énergie disponible pour Electron pour construise un écosystème utilisateur est un élément crucial pour le maintien de la santé du projet.

Qu’avons-nous fait pour renforcer notre présence communautaire?

Construction de communautés virtuelles​

• En 2020, nous avons lancé notre serveur communautaire Discord. Nous avions auparavant une section dans le forum d’Atom, mais avons décidé d’avoir une plateforme de messagerie plus informelle pour avoir un espace de discussion entre responsables et développeurs Electron ainsi que pour l’aide générale au débogage.
• En 2021, nous avons créé le groupe d'utilisateurs Electron China avec l'aide de @BlackHole1. Ce groupe a contribué à la croissance du nombre d'utilsateurs d’Electron de la scène technologique qui est en plein essor en Chine, leur offrant un espace pour collaborer sur des idées et discuter d’électron en dehors des espaces de langue anglaise. Nous aimerions également remercier cnpm pour leur travail de support des publications nocturnes d'Electron dans leur miroir chinois de npm.

Participation à des programmes open source à haute visibilité​

• Nous célébrons Hacktoberfest chaque année depuis 2019. Hacktoberfest est une célébration annuelle de l'open source organisée par DigitalOcean, et nous recevons chaque année des dizaines de contributeurs enthousiastes cherchant à se démarquer dans le domaine du logiciel libre.
• En 2020, nous avons participé à la première de Google Season of Docs, où nous avons travaillé avec @bandantonio pour retravailler le nouveau flux de tutoriels utilisateur d'Electron.
• En 2022, pour la première fois, nous avons encadré un étudiant pour son Google Summer of Code . @aryanshridhar did some awesome work to refactor Electron Fiddle's core version loading logic and migrate its bundler to webpack.

Automatisation maximale!​

Aujourd'hui, la gouvernance d'Electron compte environ 30 responsables actifs. Moins de la moitié d'entre nous sont des contributeurs à temps plein, ce qui implique beaucoup de travail. Quelle est notre astuce pour que tout fonctionne sans heurts ?: Notre devise est que les ordinateurs sont bon marché, et que le temps humain coûte cher. En tant qu’ingénieurs typiques, nous avons développé une suite d’outils de soutien automatisés pour nous rendre la vie plus facile.

Not Goma​

Le cœur de la base de code Electron est un mastodonte de code C++, et les temps de compilation ont toujours été un facteur limitant pour la rapidité avec laquelle nous pouvons livrer des corrections de bugs et de nouvelles fonctionnalités. En 2020, nous avons déployé Not Goma, un backend personnalisé spécifique à Electron pour le service de compilation distribué Goma de Google. Ne pas Goma traite les demandes de compilation des machines de l'utilisateur autorisé et distribue le processus sur des centaines de cœurs dans le backend. Il met également en cache le résultat de la compilation de sorte que quelqu'un d'autre compilant les mêmes fichiers n'aura besoin que de télécharger le résultat pré-compilé.

Depuis le lancement de Not Goma, les temps de compilation pour les responsables sont passés de plusieurs heures à quelques minutes. Une connexion internet stable est devenue la condition minimale pour que les contributeurs compilent Electron!

Authentification continue​

L'authentification continue à plusieurs facteurs(CFA) est une couche d'automatisation autour du système d'authentification à deux facteurs (2FA) de npm que nous avons combinée combinons avec semantic release afin de gérer les publications sécurisées et automatisées de nos différents paquets @electron/ npm.

Alors que le versionnage sémantique automatise déjà le processus de publication des paquets npm, il faut désactiver authentification à deux facteurs ou passage d’un jeton secret qui contourne cette restriction.

Nous avons conçu le CFA pour fournir un mot de passe à usage unique (TOTP) pour les tâches de CI arbitraires, nous permettant ainsi d’exploiter l’automatisation du versionage sémantique tout en conservant la sécurité supplémentaire de l'authentification à deux facteurs.

Nous utilisons CFA avec une intégration frontale Slack, permettant aux responsables de valider la publication des paquets de n’importe quel appareil qu’ils ont Slack, tant qu’ils ont leur générateur TOTP à portée de main.

Sheriff​

Sheriff est un outil open source que nous avons écrit pour automatiser la gestion des permissions à travers GitHub, Slack et Google Workspace.

L'apport de sheriff vient du fait que la gestion des autorisations devrait être un processus transparent. Il utilise un seul fichier de configuration YAML désignant les autorisations pour tous les services énumérés ci-dessus. Avec Sheriff, obtenir le statut de collaborateur sur un dépôt ou créer une nouvelle liste de diffusion est aussi simple que faire approuver et fusionner un Push request.

Sheriff a également un journal d'audit publie vers Slack, avertissant les administrateurs lorsque des activités suspectes se produisent n'importe où dans l'organisation Electron.

… et tous nos robots de GitHub​

GitHub est une plate-forme avec une extensibilité API riche et un robot de framework d'application appelé Probot. Pour nous aider à nous concentrer sur les parties les plus créatives de notre travail, nous avons construit une suite de robots moins conséquents nous aidant à faire le sale boulot pour nous. Voici quelques exemples :

• Sudowoodo automatise le processus de publication da A à Z, du lancement des compilations au téléchargement des ressources de publication sur GitHub et npm.
• Trop automatise le processus de rétroportage d' Electron en essayantr de choisir des correctifs sur mesure pour les branches de diffusion précédentes en fonction des étiquettes PR de GitHub.
• Rouleau automatise les mises à jour en cours des dépendances Chromium et Node.js d'Electron.
• Cation est notre robot de vérification de l’état des Pull Request.

Dans l'ensemble, notre petite famille de bots nous a donné un énorme coup de pouce pour améliorer la productivité des développeurs!

Et ensuite ?​

Alors que nous entrons dans la deuxième décennie de notre projet, vous vous demanderez peut-être : que va t-il se passer maintenant pour Electron?

Nous allons demeurer en phase avec la cadence de sortie de Chromium, libérant de nouvelles versions majeures d'Electron toutes les 8 semaines en conservant les mises à jour relatives aux nouvautés les plus importants du web et de Node.js tout en maintenant la stabilité et la sécurité pour les applications de niveau entreprise.

Nous présentons généralement les initiatives à venir quand elles deviennent concrètes. Si vous voulez rester au courant des versions, des fonctionnalités et des mises à jour générales du projet, vous pouvez lire notre blog et nous suivre sur les médias sociaux (Twitter et Mastodon ) !

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.

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 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 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.

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

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. No new Beta or Stable releases in December. No Nightly releases for the last two weeks of December.
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?​

In short, while maintainers are happy and engaged with the project, THE WORLD IS TIRED. December is a quiet month for most companies, so we want to give our maintainers a chance to recharge. Nous encourageons les autres projets à envisager des mesures similaires.

Should I be worried about the future of Electron?​

Non. We are able to take this step because the project is in good shape. Tout le monde attend 2022 avec impatience, et nous nous attendons à de bonnes choses à venir!

A partir de Septembre 2021, Electron publiera une nouvelle version majeure et stable toutes les 8 semaines.

En 2019, Electron est passé à un cycle d'une publication toute les 12 semaines pour correspondre au cycle de publication de 6 semaines de Chromium. Récemment, Chrome et Microsoft ont annoncé des changements qui nous ont fait reconsidérer la cadence actuelle des versions d'Electron:

1. Chromium prévoit de publier une release toutes les 4 semaines et ce à partir de Chrome 94 le 21 septembre 2021. Cette cadence de version ajoute également une nouvelle option Extended Stable toutes les 8 semaines, qui contiendra toutes les corrections de sécurité mises à jour.

2. Le Microsoft Store nécessitera que les applications basées sur Chrome ne soient pas plus anciennes que de 2 versions majeures. Par exemple, si la dernière version majeure de Chromium est 85, tout navigateur basé sur Chromium doit être au moins sur Chromium version 83 ou supérieure. Cette règle inclut les applications Electron.

À partir de septembre 2021, Electron sortira une nouvelle version stable majeure toutes les 8 semaines, pour correspondre aux 8 semaines des versions stables de Chromium.

Notre première version avec Chromium Extended Stable sera Electron 15 le 21 septembre 2021.

Sachant que le changement de cadence de publication aura un impact sur d'autres applications en aval, nous voulions le faire savoir à notre communauté de développeurs le plus tôt possible. Pour en savoir plus, voyez notre calendrier de publication 2021.

Electron 15: Alpha Temporaire​

Given that our original Electron 15 release targeted a non-Extended Stable version (Chromium's Extended Stable versions are based on their even-numbered versions), we needed to change our original target release date. However, an Electron app must use the most recent 2 major versions of Chromium to be accepted to the Microsoft Store, which made waiting for two Chromium versions untenable.

With these two requirements, our team faced a timing dilemma. Moving Electron 15 to include Chromium M94 would allow app developers to get on the very first Extended Stable version of Chromium; however, it would also shorten the beta-to-stable cycle to only 3 weeks.

To help with this switchover, Electron will offer a temporary alpha build, only for the Electron 15 release. This alpha build will allow developers more time to test and plan for an Electron 15 release, with a more stable build than our current nightlies.

The alpha channel build will ship for Electron 15 on July 20th, 2021. It will transition to a beta release on September 1st, 2021 with a stable release target of September 21st, 2021. Subsequent Electron releases will not have alpha releases.

Plan de diffusion pour 2021​

Voici notre calendrier de publication pour 2021 :

Adding the alpha channel extends the development time before Electron 15's launch from 3 weeks to 9 weeks - closer to our new 8 week cycle, while still meeting the requirements for Windows Store submission.

To further help app developers, for the remainder of 2021 until May 2022, we will also be extending our supported versions policy from the latest 3 versions to the latest 4 versions of Electron. That means that even if you can't immediately alter your upgrade schedule, older versions of Electron will still receive security updates and fixes.

Tenir compte des préoccupations​

Il y a une raison pour laquelle nous publions ce post bien avant que ce changement de cycle de publication ne soit prévu. Nous savons qu’un cycle de sortie plus rapide aura un impact réel sur les applications Electron - et certaines peuvent déjà amener à considérer notre cadence de sortie majeure agressive.

Nous avons tenté de répondre aux préoccupations communes ci-dessous :

❓ Pourquoi même faire ce changement ? Pourquoi ne pas garder la cadence de la sortie de 12 semaines ?​

To deliver the most up-to-date versions of Chromium in Electron, our schedule needs to track theirs. More information around Chromium's release cycle can be found here.

Additionally, the current 12 week release cadence would be untenable with the Microsoft Store's new submission requirements. Even apps on the latest stable version of Electron would experience a roughly two week period where their app may be rejected under the new security requirements.

Every new Chromium release contains new features, bug fixes / security fixes, and V8 improvements. We want you, as app developers, to have these changes in a timely manner, so our stable release dates will continue to match every other Chromium stable release. As an app developer, you'll have access to new Chromium and V8 features and fixes sooner than before.

❓ Le calendrier de sortie des 12 semaines existantes se déplace déjà rapidement. Quelles mesures l'équipe prend-elle pour faciliter la mise à niveau ?​

One advantage of more frequent releases is having smaller releases. We understand that upgrading Electron's major versions can be difficult. We hope that smaller releases will introduce fewer major Chromium and Node changes, as well as fewer breaking changes, per release.

❓ Y aura-t-il une version alpha disponible pour les futures versions d'Electron ?​

There are no plans to support a permanent alpha release at this time. This alpha is only intended for Electron 15, as a way to help developers upgrade more easily in the shortened release period.

❓ Electron va-t-il étendre le nombre de versions supportées ?​

We will be extending our supported version policy from the latest three versions to the latest four versions of Electron until May 2022, with the release of Electron 19. After Electron 19 is released, we'll return to supporting the latest three major versions, as well as the beta and nightly releases.

Questions?​

📨 Si vous avez des questions ou des préoccupations, veuillez nous écrire à info@electronjs.org ou rejoindre notre Discord. Nous savons qu'il s'agit d'un changement qui aura un impact sur de nombreuses applications et développeurs, et vos commentaires sont très importants pour nous. Nous voulons avoir de vos nouvelles !