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 d'origine travailles encore chez Microsoft aujourd’hui, elle fait partie maintenant d'un groupe plus important de collaborateurs qui forment la gouvernance Electron.

Bien que ce modèle ne soit pas parfait, il nous a convenus à travers une pandémie mondiale et des vents contraires macroéconomiques. En avançant, nous prévoyons de réorganiser la charte de gouvernance afin de nous guider tout au long de la deuxième décennie d'Electron.

Communauté​

La partie communautaire de l’open source est compliquée, surtout lorsque votre équipe de sensibilisation est composée d’une douzaine d’ingénieurs en trench qui dit « 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 a fait un travail génial pour refactoriser la logique de chargement de la version principale de Fiddleet migrer son bundler vers webpack.

Automatisation d'un maximum de choses!​

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.

While semantic-release already automates the npm package publishing process, it requires turning off two-factor authentication or passing in a secret token that bypasses this restriction.

We built CFA to deliver a time-based one-time password (TOTP) for npm 2FA to arbitrary CI jobs, allowing us to harness the automation of semantic-release while keeping the additional security of two-factor authentication.

We use CFA with a Slack integration front-end, allowing maintainers to validate package publishing from any device they have Slack on, as long as they have their TOTP generator handy.

Sheriff​

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

Sheriff’s key value proposition is that permission management should be a transparent process. It uses a single YAML config file that designates permissions across all the above listed services. With Sheriff, getting collaborator status on a repo or creating a new mailing list is as easy as getting a PR approved and merged.

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 is a platform with rich API extensibility and a first-party bot application framework called Probot. To help us focus on the more creative parts of our job, we built out a suite of smaller bots that help do the dirty work for us. Here are a few examples:

• Sudowoodo automates the Electron release process from start to finish, from kicking off builds to uploading the release assets to GitHub and npm.
• Trop automates the backporting process for Electron by attempting to cherry-pick patches to previous release branches based on GitHub PR labels.
• Roller automates rolling upgrades of Electron’s Chromium and Node.js dependencies.
• 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 ) !

Electron 23.0.0 est disponible ! Cette version inclut les mises à jour vers Chromium 110, V8 11.0, et Node.js 18.12.1. De plus, la prise en charge de Windows 7/8/8.1 a été abandonnée. Lisez la suite ci-dessous pour plus de détails !

L’équipe Electron est heureuse d’annoncer la sortie d’Electron 23.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 110
  • Nouveautés de Chrome 110
  • Nouveautés de Chrome 109
  • Nouveautés de DevTools 110
  • Nouveautés de DevTools 109
• Node.js 18.12.1
  • Article de blog sur Node 18.12.1
• V8 11.0

Nouvelles fonctionnalités​

• Ajout de la propriété label aux objets de type Display . #36933
• Ajout de l'API app.getPreferredSystemLanguages() qui retourne les langues système de l'utilisateur. #36035
• Ajout de la prise en charge de l'API WebUSB. #36289
• Ajout de la prise en charge de SerialPort.forget() ainsi que le nouvel événement serial-port-revoked émis sur les objets Session lorsqu'une origine donnée est révoquée. #35310
• Ajout de la nouvelle API win.setHiddenInMissionControl pour permettre aux développeurs de désactiver Mission Control sur macOS. #36092

Abandon du support pour Windows 7/8/8.1​

Electron 23 ne prend plus en charge Windows 7/8/8.1. Electron suit la politique planifiée de dépréciation de Chromium, qui déprécie Windows 7/8/8. , ainsi que le support de Windows Server 2012 et 2012 R2 dans Chromium 109 (lire plus ici).

Modifications majeurs de l'API​

Vous trouverez ci-dessous les changements majeurs introduits dans Electron 23. Vous pouvez en savoir plus sur ces changements et sur les futurs sur la page Planned Breaking Changes.

Supprimé: Évènements BrowserWindow scroll-touch-*​

Les événements sscroll-touch-begin, scroll-touch-end and scroll-touch-edge qui étaient dépréciés sur BrowserWindow ont été supprimés. À la place, il faut désormais utiliser l'événement input-event nouvellement disponible sur WebContents.

// Supprimé dans Electron 23.0
-win.on('scroll-touch-begin', scrollTouchBegin)
-win.on('scroll-touch-edge', scrollTouchEdge)
-win.on('scroll-touch-end', scrollTouchEnd)

// A remplacer par
+win.webContents.on('input-event', (_, event) => {
+  if (event.type === 'gestureScrollBegin') {
+    scrollTouchBegin()
+  } else if (event.type === 'gestureScrollUpdate') +{
+    scrollTouchEdge()
+  } else if (event.type === 'gestureScrollEnd') {
+    scrollTouchEnd()
+  }
+})

Fin du support pour 20.x.y​

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

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.

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 22.0.0 est disponible ! Il inclut la nouvelle API utilityProcess , des mises à jour pour le support de Windows 7/8/8.1 et des mises à jour vers Chromium 108, V8 10.8et Node.js 16.17.1. Lisez la suite ci-dessous pour plus de détails !

L'équipe d'Electron est heureuse d'annoncer la sortie d'Electron 22.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 108
  • Nouveautés de Chrome 108
  • Nouveautés de Chrome 107
  • Nouveautés de DevTools 108
  • Nouveautés de DevTools 107
• Node.js 16.17.1
  • Article de blog sur Node 16.17.1
• V8 10.8

Nouveautés de cette version​

API UtilityProcess #36089​

Le nouveau module de processus principal UtilityProcess permet la création d'un processus léger fils de Chromium avec intégration Node tout en permettant la communication avec un moteur de rendu en bac à sable en utilisant MessageChannel. L’API a été conçue sur la base de child_process.fork de Node.js, avec comme différence principale que le point modulePath d’entrée doit être situé dans l'application empaquetée afin de n'autoriser que le chargement des scripts de confiance. De plus, le module empêche par défaut l'établissement de canaux de communication avec les moteurs de rendu , respectant ainsi le contrat stipulant que le processus principal est le seul processus de confiance de l'application.

Vous pourrez en savoir plus en suivant ce lien vers notre documentation: nouvelle API UtilityProcess .

Mise à jour de la prise en charge de Windows 7/8.1​

Electron 22 sera la dernière version majeure d'Electron à prendre en charge Windows 7/8/8.1. Electron suit la politique planifiée de dépréciation de Chromium, qui dépréciera le support de Windows 7/8/8.1 dans Chromium 109 (cliquez ici pour en savoir plus).

Windows 7/8/8.1 ne seront plus pris en charge dans les versions majeures d'Electron 23 et ultérieures.

Autres Modifications supplémentaires à signaler​

• Ajout de la prise en charge de l'appairage de code confidentiel Web Bluetooth sous Linux et Windows. #35416
• Ajout de LoadBrowserProcessSpecificV8Snapshot en tant que nouveau fuse qui permettra au processus main/navigateur de charger son instantané v8 depuis un fichier vers browser_v8_context_snapshot.bin. Tout autre processus utilisera le même chemin que celui utilisé aujourd'hui. #35266
• Ajout de WebContents.opener afin d'accéder à l'origine de l'ouverture de la fenêtre et de webContents.fromFrame(frame) pour obtenir le WebContents correspondant à une instance de WebFrameMain. #35140
• Ajout du support pour navigator.mediaDevices.getDisplayMedia via un nouveau gestionnaire de session, ses.setDisplayMediaRequestHandler. #30702

Modifications majeurs de l'API​

Vous trouverez ci-dessous les changements majeurs introduits dans Electron 22. Vous pouvez en savoir plus sur ces changements et sur les futurs sur la page Planned Breaking Changes.

Déprécié : webContents.incrementCapturerCount(stayHidden, stayAwake)​

webContents.incrementCapturerCount(stayHidden, stayAwake) a été déprécié. La gestion est maintenant automatiquement réalisée par webContents.capturePage lorsqu'une capture de page est terminée.

const w = new BrowserWindow({ show: false })

- w.webContents.incrementCapturerCount()
- w.capturePage().then(image => {
-   console.log(image.toDataURL())
-   w.webContents.decrementCapturerCount()
- })

+ w.capturePage().then(image => {
+   console.log(image.toDataURL())
+ })

Déprécié : webContents.decrementCapturerCount(stayHidden, stayAwake)​

webContents.decrementCapturerCount(stayHidden, stayAwake) a été déprécié. La gestion est maintenant automatiquement réalisée par webContents.capturePage lorsqu'une capture de page est terminée.

const w = new BrowserWindow({ show: false })

- w.webContents.incrementCapturerCount()
- w.capturePage().then(image => {
-   console.log(image.toDataURL())
-   w.webContents.decrementCapturerCount()
- })

+ w.capturePage().then(image => {
+   console.log(image.toDataURL())
+ })

Supprimé: événement WebContents new-window​

L'événement new-window de WebContents a été supprimé. Remplacé par webContents.setWindowOpenHandler().

- webContents.on('new-window', (event) => {
-   event.preventDefault()
- })

+ webContents.setWindowOpenHandler((details) => {
+   return { action: 'deny' }
+ })

Déprécié: les événements scroll-touch-* de BrowserWindow​

Les événements scroll-touch-begin, scroll-touch-end et scroll-touch-edge de BrowserWindow sont dépréciés. Il faut utiliser à la place l'événement input-event récemment disponible sur WebContents.

// Déprécié
- win.on('scroll-touch-begin', scrollTouchBegin)
- win.on('scroll-touch-edge', scrollTouchEdge)
- win.on('scroll-touch-end', scrollTouchEnd)

// Remplacés par
+ win.webContents.on('input-event', (_, event) => {
+   if (event.type === 'gestureScrollBegin') {
+     scrollTouchBegin()
+   } else if (event.type === 'gestureScrollUpdate') {
+     scrollTouchEdge()
+   } else if (event.type === 'gestureScrollEnd') {
+     scrollTouchEnd()
+   }
+ })

Fin du support pour 19.x.y​

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

Et pour la suite​

Le projet Electron fera une pause pour le mois de décembre 2022 et reviendra en janvier 2023. Plus d'informations peuvent être trouvées sur le blog A Quiet Place Part Ii (Dec'22).

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

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.

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.