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 ! You can install it with npm via npm install electron@latest or download it from our releases website. Lisez la suite pour plus de détails sur cette version et veuillez partagez vos commentaires et remarques !

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

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

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

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

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

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

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

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

FAQ​

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

La team Electron est excitée d'annoncer la sortie de Electron 19.0.0 ! You can install it with npm via npm install electron@latest or download it from our releases website. Lisez la suite pour plus de détails sur cette version et veuillez partagez vos commentaires et remarques !

Changement de le cadence de publication d'Electron​

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

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

What is happening?

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

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

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

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

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

How might this impact you?

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

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

What about existing data?

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

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

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

La team Electron est excitée d'annoncer la sortie de Electron 18.0.0 ! You can install it with npm via npm install electron@latest or download it from our releases website. Lisez la suite pour plus de détails sur cette version et veuillez partagez vos commentaires et remarques !

Changement de le cadence de publication d'Electron​

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

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

Changements notables​

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

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

L'équipe d'Electron est excitée de vous annoncer que nous allons participer au Google Summer of Code pour la première fois cette année!

Qu'est ce que le Google Summer of Code?​

Le Google Summer of Code (GSoC) est un programme de mentorat annuel qui rassemble plusieurs projets de logiciel open source avec des contributeurs potentiels. Récemment ouvert seulement pour les étudiants, n'importe qui ayant 18 ans et plus peut désormais s'inscrire pour le GSoC.

Pour plus d'informations, rendez-vous sur la page d'accueil du Summer of Code.

Comment s'inscrire ?​

Êtes-vous intéressé à collaborer avec Electron? Si vous êtes nouveau ou débutant dans la contribution de l'open source, nous vous invitons à postuler !

Dans le but d'être sélectionné comme contributeur Electron pour le Google Summer of Code, vous allez devoir soumettre une candidature. Les candidatures ouvriront le 4 avril 2002 et s'arrêterons le 19 avril 2022. Vous pouvez suivre les actualités et directives pour les candidatures du Google Summer of Code ici.

Envie de postuler ? Premièrement, regardez les cinq idées brouillons de projets que nous avons préparé. Toutes les idées listées sont actuellement ouvertes aux propositions. Nous acceptons également de nouvelles idées que nous n'avons pas proposées dans la liste des projets.

Votre candidature devra inclure :

• Votre proposition, avec un document écrit qui décrit en détail votre plan de ce que vous comptez achever au cours de cet été.
• Votre expérience en tant que développeur. Si vous avez un C.V, merci de l'inclure une copie, par ailleurs, parlez-nous de vos expériences passées en mettant l'accent sur vos expériences techniques pertinentes.

Un guide détaillé de ce qu'il faut soumettre dans le cadre de votre candidature Electron est ici.

Vous pouvez également lire le guide officiel pour les étudiants et contributeurs du GSoC afin d'obtenir de précieux conseils sur la préparation de votre candidature.

Si vous souhaitez discuter de proposition de projet ou si vous avez des questions, visitez notre canal Discord #gsoc-general !

Références​

• Guide de propositions d'Electron
• GitHub d'Electron
• Documents des idées de projet
• Guide pour les étudiants et contributeurs du GsoC

Electron 17.0.0 est disponible ! Cette version inclue les mises à jour vers Chromium 98, V8 9.8, et Node.js 16.13.0. Lisez la suite ci-dessous pour plus de détails !

La team Electron est excitée d'annoncer la sortie de Electron 17.0.0 ! You can install it with npm via npm install electron@latest or download it from our releases website. Lisez la suite pour plus de détails sur cette version et veuillez partagez vos commentaires et remarques !

Changement de le cadence de publication d'Electron​

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

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

Changements notables​

• Ajout de webContents.getMediaSourceId(), peut être utilisé avec getUserMedia pour obtenir un flux pour un contenu Web. #31204
• Déprécie webContents.getPrinters() et introduit webContents.getPrintersAsync(). #31023
• Dorénavant desktopCapturer.getSources n’est plus disponible que dans le processus principal. #30720

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

Spectron sera déprécié le 1er février 2022.

À partir de février 2022, Spectron sera officiellement déclaré obsolète par l'équipe d'Electron.

Pourquoi déprécier Spectron ?​

Bien que Spectron ait constamment publié de nouvelles versions pour chaque nouvelle version d’Electron, le projet a eu très peu de maintenance et d’améliorations depuis plus d’un an et n’a actuellement aucun mainteneur à temps plein. En plus avec la sortie du module remote du noyau Electron pour être mis dans un module externe avec Electron 14, Spectron devra subir une réécriture majeure pour continuer à fonctionner de manière fiable.

Après avoir examiné plusieurs options disponibles pour maintenir la maintenance de Spectron, l'équipe d'Electron a décidé de déprécier Spectron en 2022.

Chronologie de dépréciation​

Ce qui suit est notre calendrier de dépréciation prévu :

• De Novembre 2021 à Janvier 2022: L'équipe d'Electron continuera à accepter les pull requests de la communauté.
• janvier 2022: Une version finale de l’avertissement de la dépréciation de Spectron sera publiée.
• 1er février 2022: Le dépôt de Spectron sera marqué comme "archivé". Plus aucune demande de pull request ne sera acceptée.

Après le 1er février 2022, Electron conservera le dépôt Spectron indéfiniment, afin que d'autres puissent toujours effectuer des fork ou utiliser le code existant dans leurs projets. Nous espérons que cela permettra d' assurer une période de transition plus longue à tous les projets pouvant encore dépendre de Spectron.

Alternatives à Spectron​

Si vous utilisez actuellement Spectron dans votre projet et que vous souhaitez migrer vers une solution de test alternative, vous pouvez lire notre guide pour les tests automatisés ici.

Nous pouvons actuellement recommaner plusieurs autres alternatives à Spectron, notamment Playwright et WebDriverIO. Des tutoriels officiels pour chaque option peuvent être trouvés dans notre documentation de test automatisé.

Et maintenant ?​

L'équipe d'Electron vous remercie d'utiliser Spectron et Electron. Nous comprenons que beaucoup d'entre vous dépendent de Spectron pour tester leurs applications et voulons vous rendre cette transition la plus simple possible. Merci d'avoir choisi Electron !

Electron 16.0.0 est disponible ! Cette version inclue les mises à jour vers Chromium 96, V8 9.6, et Node.js 16.9.1. Lisez la suite ci-dessous pour plus de détails !

La team Electron est excitée d'annoncer la sortie de Electron 16.0.0 ! You can install it with npm via npm install electron@latest or download it from our releases website. Lisez la suite pour plus de détails sur cette version et veuillez partagez vos commentaires et remarques !

Changement de le cadence de publication d'Electron​

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

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

Changements notables​

• Prise en charge de l’API WebHID. #30213
• Ajout d'un paramètre de données à app.requestSingleInstanceLock pour le partage de données entre instances. #30891
• Transmission de la securityOrigin dans un nouveau champ de la propriété details du gestionnaire de requêtes d'autorisations multimédia. #31357
• Ajout de commandLine.removeSwitch. #30933

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

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!