Earlier today, the Electron team was alerted to several public CVEs recently filed against several notable Electron apps. The CVEs are related to two of Electron’s fuses - runAsNode and enableNodeCliInspectArguments - and incorrectly claim that a remote attacker is able to execute arbitrary code via these components if they have not been actively disabled.

We do not believe that these CVEs were filed in good faith. First of all, the statement is incorrect - the configuration does not enable remote code execution. Secondly, companies called out in these CVEs have not been notified despite having bug bounty programs. Lastly, while we do believe that disabling the components in question enhances app security, we do not believe that the CVEs have been filed with the correct severity. “Critical” is reserved for issues of the highest danger, which is certainly not the case here.

Anyone is able to request a CVE. While this is good for the overall health of the software industry, “farming CVEs” to bolster the reputation of a single security researcher is not helpful.

That said, we understand that the mere existence of a CVE with the scary critical severity might lead to end user confusion, so as a project, we’d like to offer guidance and assistance in dealing with the issue.

Comment cela pourrait-il avoir un impact pour moi?​

After reviewing the CVEs, the Electron team believes that these CVEs are not critical.

An attacker needs to already be able to execute arbitrary commands on the machine, either by having physical access to the hardware or by having achieved full remote code execution. This bears repeating: The vulnerability described requires an attacker to already have access to the attacked system.

Chrome, for example, does not consider physically-local attacks in their threat model:

We consider these attacks outside Chrome's threat model, because there is no way for Chrome (or any application) to defend against a malicious user who has managed to log into your device as you, or who can run software with the privileges of your operating system user account. Such an attacker can modify executables and DLLs, change environment variables like PATH, change configuration files, read any data your user account owns, email it to themselves, and so on. Such an attacker has total control over your device, and nothing Chrome can do would provide a serious guarantee of defense. This problem is not special to Chrome ­— all applications must trust the physically-local user.

The exploit described in the CVEs allows an attacker to then use the impacted app as a generic Node.js process with inherited TCC permissions. So if the app, for example, has been granted access to the address book, the attacker can run the app as Node.js and execute arbitrary code which will inherit that address book access. This is commonly known as a “living off the land” attack. Attackers usually use PowerShell, Bash, or similar tools to run arbitrary code.

Suis-je impacté?​

Par défaut, toutes les versions publiées d'Electron ont les fonctionnalités runAsNode et enableNodeCliInspectArguments activées. If you have not turned them off as described in the Electron Fuses documentation, your app is equally vulnerable to being used as a “living off the land” attack. Again, we need to stress that an attacker needs to already be able to execute code and programs on the victim’s machine.

Atténuation​

La façon la plus simple d'atténuer ce problème est de désactiver le fusible runAsNode dans votre application Electron. Le fuse runAsNode acitve ou désactive le respect de la variable d'environnement ELECTRON_RUN_AS_NODE. Please see the Electron Fuses documentation for information on how to toggle theses fuses.

Please note that if this fuse is disabled, then process.fork in the main process will not function as expected as it depends on this environment variable to function. Instead, we recommend that you use Utility Processes, which work for many use cases where you need a standalone Node.js process (like a Sqlite server process or similar scenarios).

Vous pouvez trouver plus d'informations sur les meilleures pratiques de sécurité que nous recommandons pour les applications Electron dans notre Liste de contrôle de sécurité.

Electron 28.0.0 est disponible ! Il inclut des mises à jour vers Chromium 120.0.6099.56, V8 12.0, et Node.js 18.18.2.

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

Si vous avez des commentaires, veuillez les partager avec nous sur [Twitter] (https://twitter.com/electronjs) ou Mastodon, ou joignez-vous à notre communauté [Discord] (https://discord.com/invite/electronjs)! Les bogues et les demandes de fonctionnalités peuvent être signalés dans l'[outil de suivi des problèmes] d’Electron (https://github.com/electron/electron/issues).

Changements notables​

Points clés​

• Support implémenté pour les modules ECMAScript ou ESM (Que sont les modules ECMAScript ? en apprendre plus ici. Cela inclut la prise en charge de ESM dans Electron proprement dit, ainsi que certains domaines tels que les points d'entrée de l'API UtilityProcess. Voir notre documentation sur le MES pour plus de détails.
• En plus de l'activation du support ESM dans Electron, Electron Forge supportera désormais également l'utilisation d'ESM pour empaqueter, compiler et développer des applications Electron. Vous pouvez profiter de ce support dans Forge v7.0.0 et au delà.

Changements de la Stack​

• Chromium 120.0.6099.56
  • Nouveau dans Chrome 119 et dans DevTools 119
  • Nouveau dans Chrome 120 et dans DevTools 120
• Node 18.18.2
  • Notes Node 18.18.0
  • Node 18.18.1 notes
  • Notes Node 18.18.2
• V8 12.0

Nouvelles fonctionnalités​

• Prise en charge ESM activée. #37535
  • Pour plus de détails, consultez la documentation ESM.
• Ajout de points d'entrée ESM à l'API UtilityProcess. #40047
• Ajout de plusieurs propriétés à l'objet display y compris detected, maximumCursorSize, et nativeOrigin. #40554
• Ajout du support de la variable d'environnement ELECTRON_OZONE_PLATFORM_HINT sous Linux. #39792

Changements majeurs avec rupture de compatibilité​

Comportement modifié : L'affectation à false de WebContents.backgroundThrottling affecte tous les WebContents de la BrowserWindow hote​

WebContents.backgroundThrottling défini à false désactivera la limitation des images dans l' BrowserWindow pour tous les WebContents qu'elle affichera.

Supprimé : BrowserWindow.setTrafficLightPosition(position)​

BrowserWindow.setTrafficLightPosition(position) a été supprimé, l'API BrowserWindow.setWindowButtonPosition(position) doit être utilisé à loa place qui pprend null à la place de { x: 0, y: 0 } pour réinitialiser la position à celle par défaut du système.

// Supprimé dans Electron 28
win.setTrafficLightPosition({ x: 10, y: 10 })
win.setTrafficLightPosition({ x: 0, y: 0 })

// A remplacer par
win.setWindowButtonPosition({ x: 10, y: 10 })
win.setWindowButtonPosition(null);

Supprimé : BrowserWindow.setTrafficLightPosition(position)​

BrowserWindow.getTrafficLightPosition() a été déprécié, l’API BrowserWindow.getWindowButtonPosition() doit être utilisée à la place, celle-ci retourne null au lieu de { x: 0, y: 0 } en absence de position personnalisée.

// Supprimé dans Electron 28
const pos = win.getTrafficLightPosition();
if (pos. === 0 && pos.y === 0) {
  // Aucune position personnalisée.
}

// Remplacer par
const ret = win. etWindowButtonPosition();
if (ret === null) {
  // Pas de position personnalisée.
}

Supprimé: ipcRenderer.sendTo()​

La méthode ipcRenderer.sendTo() a été supprimée. It should be replaced by setting up a MessageChannel between the renderers.

The senderId and senderIsMainFrame properties of IpcRendererEvent have been removed as well.

Supprimé : app.runningUnderRosettaTranslation​

The app.runningUnderRosettaTranslation property has been removed. Use app.runningUnderARM64Translation instead.

// Supprimé
console.log(app.runningUnderRosettaTranslation)
// A remplacer par
console.log(app.runningUnderARM64Translation);

Fin du support pour 25.x.y​

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

You can find Electron's public timeline here.

More information about future changes can be found on the Planned Breaking Changes page.

Réflexion à propos des améliorations et changements intervenu dans l’écosystème des développeurs d’Electron en 2023.

Au cours des derniers mois, nous avons concocté plusieurs changements dans l’écosystème Electron pour booster l’expérience des développeurs pour les applications Electron ! Voici un rapide aperçu des derniers ajouts en direct du siège d’Electron.

Forge Electron 7 et au-delà​

Electron Forge 7— nouvelle version majeure de notre outil tout-en-un pour l’empaquetage et la distribution des applications Electron, est maintenant disponible.

Alors que Forge 6 était une réécriture complète de la v5, la v7 a une portée plus réduite, mais contient toujours quelques modifications de rupture. À l’avenir, nous continuerons à publier des versions majeures de Forge car des modifications de rupture doivent être apportées.

Pour plus de détails, consultez la version 7.0.0 de Forge sur GitHub.

Dernières modifications​

• Switched to notarytool for macOS notarization: As of 2023-11-01, Apple sunset the legacy altool for macOS notarization, and this release removes it from Electron Forge entirely.
• Minimum Node.js increased to v16.4.0: With this release, we’ve set the minimum required Node.js version to 16.4.0.
• Dropped support for electron-prebuilt and electron-prebuilt-compile: electron-prebuilt was the original name for Electron’s npm module, but was replaced by electron in v1.3.1. electron-prebuilt-compile was an alternative to that binary that came with enhanced DX features, but was eventually abandoned as a project.

Points clés​

• Google Cloud Storage publisher : Dans le cadre de nos efforts pour mieux soutenir la mise à jour automatique statique, Electron Forge prend maintenant en charge la publication directement dans Google Cloud Storage!
• ESM forge.config.js support: Electron Forge prend désormais en charge les fichiers ESM `forge.config.js. (P.S. Nous attendons avec impatience le support des points d'entrée ESM dans Electron 28. )
• Les fabricants fonctionnent maintenant en parallèle: Dans Electron Forge 6, les makers s'exécutaient séquentiellement pour ✨ raisons historiques héritées ✨ . Since then, we’ve tested out parallelization for the Make step with no adverse side effects, so you should see a speed-up when building multiple targets for the same platform!

Amélioration des mises à jour automatiques pour stockage statique​

Squirrel.Windows and Squirrel.Mac are platform-specific updater technologies that back Electron’s built-in autoUpdater module. Both projects support auto updates via two methods:

• A Squirrel-compatible update server
• A manifest URL hosted on a static storage provider (e.g. AWS, Google Cloud Platform, Microsoft Azure, etc.)

The update server method has traditionally been the recommended approach for Electron apps (and provides additional customization of update logic), but it has a major downside—it requires apps to maintain their own server instance if they are closed-source.

On the other hand, the static storage method has always been possible, but was undocumented within Electron and poorly supported across Electron tooling packages.

With some great work from @MarshallOfSound, the update story for serverless automatic app updates has been drastically streamlined:

• Electron Forge’s Zip and Squirrel.Windows makers can now be configured to output autoUpdater-compatible update manifests.
• A new major version of update-electron-app (v2.0.0) can now read these generated manifests as an alternative to the update.electronjs.org server.

Once your Makers and Publishers are configured to upload update manifests to cloud file storage, you can enable auto updates with only a few lines of configuration:

const { updateElectronApp, UpdateSourceType } = require('update-electron-app');

updateElectronApp({
  updateSource: {
    type: UpdateSourceType.StaticStorage,
    baseUrl: `https://my-manifest.url/${process.platform}/${process.arch}`,
  },
});

L’univers étendu « @electron/​

Au débuts d'Electron, la communauté a publié de nombreux packages pour améliorer l’expérience de développement, d’empaquetage et de distribution d’applications Electron. Au fil du temps, bon nombre de ces paquets ont été incorporés dans l'organisation GitHub d'Electron, l'équipe principale assumant le fardeau de la maintenance.

En 2022, nous avons commencé à unifier tous ces outils sous l’espace de noms « @electron/» sur npm. Ce changement signifie que les paquets qui étaient dans « electron-foo » sont maintenantsur npm dans « @electron/foo » et les dépôts qui étaient nommés « electron/electron-foo » sont maintenant « electron/foo » sur GitHub. Ces changements aident à délimiter clairement les projets initiaux des projets du userland. Cela inclut de nombreux paquets couramment utilisés, tels que:

• @electron/asar
• @electron/fuses
• @electron/get
• @electron/notarize
• @electron/osx-sign
• @electron/packager
• @electron/rebuild
• @electron/remote
• @electron/symbolicate-mac
• @electron/universal

Going forward, all first-party packages we release will also be in the @electron/ namespace. There are two exceptions to this rule:

• Electron core will continue to be published under the electron package.
• Electron Forge will continue to publish all of its monorepo packages under the @electron-forge/ namespace.

Introduction à @electron/windows-sign​

À partir du 2023-06-01, les normes de l’industrie ont commencé à exiger que les clés des certificats de signature de code Windows soient stockées sur du matériel conforme à la FIPS.

En pratique, cela signifie que la signature de code est devenue beaucoup plus compliquée pour les applications qui compilent et signet des environnements d'intégration continue, car de nombreux outils Electron prennent un fichier de certificat et un mot de passe comme paramètres de configuration et tentent de signer à partir de là en utilisant une logique codée en dur.

This situation has been a common pain point for Electron developers, which is why we have been working on a better solution that isolates Windows code signing into its own standalone step, similar to what @electron/osx-sign does on macOS.

In the future, we plan on fully integrating this package into the Electron Forge toolchain, but it currently lives on its own. The package is currently available for installation at npm install --save-dev @electron/windows-sign and can used programmatically or via CLI.

Veuillez si vous le pouvez l’essayer et nous faire part de vos commentaires dans l’outil de suivi des problèmes de repo!

Et ensuite ?​

We'll be entering our annual December quiet period next month. While we do, we'll be thinking about how we can make the Electron development experience even better in 2024.

Is there anything you'd like to see us work on next? Signalez-le nous!

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!

Electron 27.0.0 est disponible ! Cette version inclut les mises à jour vers Chromium 118.0.5993.32, V8 11.8, et Node.js 18.17.1.

L’équipe Electron est heureuse d’annoncer la sortie d’Electron 27.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.

Si vous avez des commentaires, veuillez nous les partager sur Twitter ou Mastodon, ou rejoignez 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 118.0.5993.32
  • Nouveautés de Chrome 118
  • Nouveautés de DevTools 118
• Node.js 18.17.1
  • Article de blog sur Node 18.17.1
  • Article de blog sur Node 18.17.0
• V8 11.8

Changements majeurs avec rupture de compatibilité​

Supprimé: support de macOS 10.13 / 10.14​

macOS 10.13 (High Sierra) et macOS 10.14 (Mojave) ne sont plus pris en charge par Chromium.

Les anciennes versions d'Electron continueront à fonctionner sur ces systèmes d'exploitation, mais macOS 10. 3 (High Sierra) ou plus récent sera nécessaire pour exécuter Electron v20.0.0 et supérieur.

Déprécié : ipcRenderer.sendTo()​

La méthode ipcRenderer.sendTo() a été dépréciée. Elle devra être remplacée par la mise en place d'un MessageChannel entre les moteurs de rendu.

Les propriétés senderId et senderIsMainFrame de IpcRendererEvent ont également été dépréciées.

Supprimé: les événements du color scheme dans systemPreferences​

Les événements suivants de systemPreferences ont été supprimés:

• inverted-color-scheme-changed
• high-contrast-color-scheme-changed

Utilisez à la place le nouvel événement updated du module nativeTheme.

// Supprimé
systemPreferences.on('inverted-color-scheme-changed', () => {
  /* ... */
});
systemPreferences.on('high-contrast-color-scheme-changed', () => {
  /* ... */
});

// A remplacer par
nativeTheme.on('updated', () => {
  /* ... */
});

Supprimé : webContents.getPrinters​

La méthode webContents.getPrinters a été supprimée. Utilisez webContents.getPrintersAsync à la place.

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

// A Supprimer
console.log(w.webContents.getPrinters());
//Et remplacer par
w.webContents.getPrintersAsync().then((printers) => {
  console.log(printers);
});

Supprimé: systemPreferences.{get,set}AppLevelAppearance et systemPreferences.appLevelAppearance​

Les méthodes systemPreferences.getAppLevelAppearance et systemPreferences.setAppLevelAppearance sont obsolètes et supprimées, ainsi que la propriété systemPreferences.appLevelAppearance. Utiliser l'Api nativeTheme à la place .

// A supprimer
systemPreferences.getAppLevelAppearance();
// Et remplacer par
nativeTheme.shouldUseDarkColors;

// A supprimer
systemPreferences.appLevelAppearance;
// Et remplacer par
nativeTheme.shouldUseDarkColors;

// A supprimer
systemPreferences.setAppLevelAppearance('dark');
// Et remplacer par
nativeTheme.themeSource = 'dark';

Supprimé: La valeur alternate-selected-control-text de systemPreferences.getColor​

La valeur alternate-selected-control-text pour systemPreferences.getColor a été supprimée. Utilisez selected-content-background à la place.

// Supprimé
systemPreferences.getColor('alternate-selected-control-text');
// Remplacé par
systemPreferences.getColor('selected-content-background');

Nouvelles fonctionnalités​

• Ajout des paramètres de transparence d’accessibilité de l’application #39631
• Ajout de la prise en charge des API d’extension chrome.scripting#39675
• Activation de WaylandWindowDecorations par défaut #39644

Fin du support pour 24.x.y​

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

Fin du support pour 22.x.y​

Un peu plus tôt cette année, l’équipe Electron a prolongé la date de fin de vie prévue de l’Electron 22 du 30 mai 2023 au 10 octobre 2023, afin de correspondre au support étendu de Chrome pour Windows 7/8/8.1 (voir Farewell, Windows 7/8/8.1 pour plus de détails).

Electron 22.x. y a atteint sa fin du support conformément à la politique de support du projet et à cette extension de support. Cela ramènera le support aux trois dernières versions majeures stables et mettra fin au support officiel de Windows 7/8/8.1.

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.

Plus d’une semaine s’est écoulée depuis que CVE-2023-4863 : Heap buffer overflow in WebP a été rendu public, entraînant une vague de nouvelles versions des webp de rendu logiciel : macOS, iOS, Chrome, Firefox et diverses distributions Linux ont tous reçu des mises à jour. Cela fait suite aux enquêtes menées par Citizen Lab, qui a découvert qu’un iPhone utilisé par une « organisation de la société civile basée à Washington DC » était attaqué à l’aide d’un exploit sans clic dans iMessage.

Pour Electron, nous sommes également passé à l’action et a publié de nouvelles versions le jour même : Si votre application affiche du contenu fourni par l’utilisateur, vous devez mettre à jour votre version d’Electron - v27.0.0-beta.2, v26.2.1, v25.8.1, v24.8.3 et v22.3.24 contiennent toutes une version corrigée de libwebp, la bibliothèque responsable du rendu des images webp.

Maintenant que nous sommes tous nouvellement conscients qu’une interaction aussi innocente que « le rendu d'une image » soit une activité potentiellement dangereuse, nous voulons profiter de cette occasion pour rappeler à tous que Electron est livré avec un bac à sable des processus qui limitera le rayon d’action d'une éventuelle grosse attaque - quelle qu’elle soit.

Le bac à sable était disponible depuis Electron v1 et activé par défaut dans v20, mais nous savons que de nombreuses applications (en particulier celles qui existent depuis un certain temps) peuvent avoir un sandbox: false quelque part dans leur code – ou un nodeIntegration: true, qui désactive également la sandbox lorsqu’il n’y a pas de paramètre sandbox explicite. C’est compréhensible : Si vous êtes avec nous depuis longtemps, vous avez probablement apprécié le pouvoir de lancer un require("child_process") ou un require("fs") dans le même code qui exécute votre HTML/CSS.

Avant de parler de comment migrer vers le bac à sable, voyons d’abord pourquoi vous le souhaitez.

The sandbox puts a hard cage around all renderer processes, ensuring that no matter what happens inside, code is executed inside a restricted environment. As a concept, it's a lot older than Chromium, and provided as a feature by all major operating systems. Electron's and Chromium's sandbox build on top of these system features. Even if you never display user-generated content, you should consider the possibility that your renderer might get compromised: Scenarios as sophisticated as supply chain attacks and as simple as little bugs can lead to your renderer doing things you didn't fully intend for it to do.

The sandbox makes that scenario a lot less scary: A process inside gets to freely use CPU cycles and memory — that’s it. Processes cannot write to disk or display their own windows. In the case of our libwep bug, the sandbox makes sure that an attacker cannot install or run malware. In fact, in the case of the original Pegasus attack on the employee’s iPhone, the attack specifically targeted a non-sandboxed image process to gain access to the phone, first breaking out of the boundaries of the normally sandboxed iMessage. When a CVE like the one in this example is announced, you still have to upgrade your Electron apps to a secure version — but in the meantime, the amount of damage an attacker can do is limited dramatically.

Migrating a vanilla Electron application from sandbox: false to sandbox: true is an undertaking. I know, because even though I have personally written the first draft of the Electron Security Guidelines, I have not managed to migrate one of my own apps to use it. That changed this weekend, and I recommend that you change it, too.

There are two things you need to tackle:

1. If you’re using Node.js code in either preload scripts or the actual WebContents, you need to move all that Node.js interaction to the main process (or, if you are fancy, a utility process). Given how powerful renderers have become, chances are high that the vast majority of your code doesn’t really need refactoring.

   Consult our documentation on Inter-Process Communication. In my case, I moved a lot of code and wrapped it in ipcRenderer.invoke() and ipcMain.handle(), but the process was straightforward and quickly done. Be a little mindful of your APIs here - if you build an API called executeCodeAsRoot(code), the sandbox won't protect your users much.

2. Since enabling the sandbox disables Node.js integration in your preload scripts, you can no longer use require("../my-script"). In other words, your preload script needs to be a single file.

   There are multiple ways to do that: Webpack, esbuild, parcel, and rollup will all get the job done. I used Electron Forge’s excellent Webpack plugin, users of the equally popular electron-builder can use electron-webpack.

All in all, the entire process took me around four days — and that includes a lot of scratching my head at how to wrangle Webpack’s massive power, since I decided to use the opportunity to refactor my code in plenty of other ways, too.

Electron 26.0.0 est disponible ! Cette version inclut les mises à jour vers Chromium 116.0.5845.62, V8 11.2, et Node.js 18.16.1. Lisez la suite ci-dessous pour plus de détails !

L’équipe Electron est heureuse d’annoncer la sortie d’Electron 26.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 116.0.5845.62
  • Nouveautés de Chrome 116
  • Nouveautés de DevTools 116
• Node.js 18.16.1
  • Article de blog sur Node 18.16.1
• V8 11.2

Changements majeurs avec rupture de compatibilité​

Déprécié : webContents.getPrinters​

La méthode webContents.getPrinters a été dépréciée. Utilisez webContents.getPrintersAsync à la place.

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

// Déprécié
console.log(w.webContents.getPrinters());
// Remplacer par
w.webContents.getPrintersAsync().then((printers) => {
  console.log(printers);
});

Déprécié: systemPreferences.{get,set}AppLevelAppearance and systemPreferences.appLevelAppearance​

Les méthodes systemPreferences.getAppLevelAppearance et systemPreferences.setAppLevelAppearance sont obsolètes, ainsi que la propriété systemPreferences.appLevelAppearance. Utiliser l'Api nativeTheme à la place .

// Déprécié
systemPreferences.getAppLevelAppearance();
// Remplacer par
nativeTheme.shouldUseDarkColors;

// Déprécié
systemPreferences.appLevelAppearance;
// Remplacer par
nativeTheme.shouldUseDarkColors;

// Déprécié
systemPreferences.setAppLevelAppearance('dark');
// Remplacer par
nativeTheme.themeSource = 'dark';

Déprécié: valeur alternate-selected-control-text pour systemPreferences.getColor​

Déprécié: la valeur alternate-selected-control-text pour systemPreferences.getColor. Utilisez selected-content-background à la place.

// Déprécié
systemPreferences.getColor('alternate-selected-control-text');
// A Remplacer par
systemPreferences.getColor('selected-content-background');

Nouvelles fonctionnalités​

• Added safeStorage.setUsePlainTextEncryption and safeStorage.getSelectedStorageBackend api. #39107
• Added safeStorage.setUsePlainTextEncryption and safeStorage.getSelectedStorageBackend api. #39155
• Added senderIsMainFrame to messages sent via ipcRenderer.sendTo(). #39206
• Added support for flagging a Menu as being keyboard initiated. #38954

Fin du support pour 23.x.y​

Electron 23.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 25.0.0 est disponible ! Cette version inclut les mises à jour vers Chromium 114, V8 11.4, et Node.js 18.15.0. Lisez la suite ci-dessous pour plus de détails !

L’équipe Electron est heureuse d’annoncer la sortie d’Electron 25.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​

Points clés​

• Implémentation de net.fetch dans le module net d’Electron, en utilisant la pile réseau de Chromium. Ceci diffère de fetch() de Node, qui utilise la pile HTTP de Node.js. Pour plus de détails, voir 6986 et 36733.
• Ajout de protocol.handle, remplaçant et dépréciant protocol.{register,intercept}{String,Buffer,Stream,Http,File}Protocol. #36674
• Prise en charge étendue d'Electron 22, afin de correspondre au plan de dépréciation de chromium et de Microsoft Windows 7/8/8.1 . Voir les détails supplémentaires à la fin de ce billet.

Changements de la Stack​

• Chromium 114
  • Nouveautés de Chrome 114
  • Nouveautés de Chrome 113
  • Nouveautés de DevTools 114
  • Nouveautés de DevTools 113
• Node.js 18.15.0
  • Article de blog sur Node 18.15.0
• V8 11.4

Changements majeurs avec rupture de compatibilité​

Déprécié : protocol.{register,intercept}{Buffer,String,Stream,File,Http}Protocol​

Les méthodes protocol.register*Protocol et protocol.intercept*Protocol ont étés remplacées par protocol.handle.

La nouvelle méthode peut soit enregistrer un nouveau protocole ou intercepter un protocole existant, les réponses peuvent être de n'importe quel type.

// Déprécié dans Electron 25
protocol.registerBufferProtocol('some-protocol', () => {
  callback({ mimeType: 'text/html', data: Buffer.from('<h5>Response</h5>') });
});

// Remplacé par
protocol.handle('some-protocol', () => {
  return new Response(
    Buffer.from('<h5>Response</h5>'), // Peut aussi être une chaîne de caractères ou ReadableStream.
    { headers: { 'content-type': 'text/html' } }
  );
});

// Déprécié dans Electron 25
protocol.registerHttpProtocol('some-protocol', () => {
  callback({ url: 'https://electronjs.org' });
});

// Remplacé par
protocol.handle('some-protocol', () => {
  return net.fetch('https://electronjs.org');
});

// Déprécié dans Electron 25
protocol.registerFileProtocol('some-protocol', () => {
  callback({ filePath: '/path/to/my/file' });
});

// Remplacé par
protocol.handle('some-protocol', () => {
  return net.fetch('file:///path/to/my/file');
});

Déprécié : BrowserWindow.setTrafficLightPosition(position)​

BrowserWindow.setTrafficLightPosition(position) a été déprécié, l'API BrowserWindow.setWindowButtonPosition(position) doit être utilisée à la place et prend comme paramètres null au lieu de { x: 0, y: 0 } pour réinitialiser la position à celle par défaut du système.

// Déprécié dans Electron 25
win.setTrafficLightPosition({ x: 10, y: 10 });
win.setTrafficLightPosition({ x: 0, y: 0 });

// Remplacé par
win.setWindowButtonPosition({ x: 10, y: 10 });
win.setWindowButtonPosition(null);

Déprécié : BrowserWindow.getTrafficLightPosition()​

BrowserWindow.getTrafficLightPosition() a été déprécié, l’API BrowserWindow.getWindowButtonPosition() doit être utilisée à la place, elle retourne null au lieu de { x: 0, y: 0 } en absence de position personnalisée.

// Deprecated in Electron 25
const pos = win.getTrafficLightPosition();
if (pos.x === 0 && pos.y === 0) {
  // No custom position.
}

// A Remplacer par
const ret = win.getWindowButtonPosition();
if (ret === null) {
  // Aucune position personalisée.
}

Nouvelles fonctionnalités​

• Ajout de net.fetch(). #36733
  • net.fetch prend en charge les requêtes vers les URLS de type file: ainsi que les protocoles personnalisés enregistrés avec protocol.register*Protocol. #36606
• Ajout des API BrowserWindow.set/getWindowButtonPosition. #37094
• Ajout de protocol.handle, remplaçant et dépréciant protocol.{register,intercept}{String,Buffer,Stream,Http,File}Protocol. #36674
• Ajout de l'événement will-frame-navigate aux webContents et balise <webview> , qui se déclenche chaque fois qu'une image dans la hiérarchie des images tente de naviguer. #34418
• Ajout d'informations de l''initiateur aux événements du navigateur. Cette information permet de distinguer un window.open d'une frame parent causant une navigation d'une navigation initiée par un enfant. #37085
• Ajout de net.resolveHost qui résout les hôtes en utilisant l'objet defaultSession . #38152
• Ajout de l'événement 'did-resign-active' à app. #38018
• Ajout de plusieurs options de taille de page standard à webContents.print(). #37159
• Ajout du drapeau enableLocalEcho à la callback ses.setDisplayMediaRequestHandler() du gestionnaire de session pour permettre la reprise dans le flux de sortie local d'entrée audio distante lorsque audio est un WebFrameMain. #37315
• Ajout des informations de gestion thermique à powerMonitor. #38028
• Permet de passer un chemin absolu à l'API session.fromPath() . #37604
• Expose l'événement audio-state-changed sur webContents. #37366

Support continu 22.x.y​

Comme indiqué dans Adieu, Windows 7/8/8., Electron 22 (Chromium 108) la date prévue de fin de vie sera prolongée du 30 mai 2023 au 10 octobre 2023. L’équipe Electron continuera à rétroporter sur Electron 22 tous les correctifs de sécurité qui font partie de ce programme jusqu’au 10 octobre 2023. La date de prise en charge d'octobre suit les dates de prise en charge étendue de Chromium et de Microsoft. À partir du 11 octobre, l'équipe d'Électron limitera le support aux trois dernières versions majeures, celles ci ne prendront plus en charge Windows 7/8/8.1.

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 24.0.0 est disponible ! Cette version inclut les mises à jour vers Chromium 112.0.5615.49, V8 11.2, et Node.js 18.14.0. Lisez la suite ci-dessous pour plus de détails !

L’équipe Electron est heureuse d’annoncer la sortie d’Electron 24.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 112.0.5615.49
  • Nouveautés de Chrome 112
  • Nouveautés de Chrome 111
  • Nouveautés de DevTools 112
  • Nouveautés de DevTools 111
• Node.js 18.14.0
  • Article de blog sur Node 18.14.0
• V8 11.2

Changements majeurs avec rupture de compatibilité​

API modifiée : nativeImage.createThumbnailFromPath(path, size)​

Le paramètre maxSize a été changé en size pour refléter que la taille passée sera la taille que la miniature a créée. Auparavant, Windows ne redimensionnerait pas l’image si elle était plus petite que maxSize, et macOS définissait toujours la taille à maxSize. Désormais, le comportement est le même sur toutes les plateformes.

// a 128x128 image.
const imagePath = path.join('path', 'to', 'capybara.png');

// Mise à l'échelle d'une image plus petite.
const upSize = { width: 256, height: 256 };
nativeImage.createThumbnailFromPath(imagePath, upSize).then((result) => {
  console.log(result.getSize()); // { width: 256, height: 256 }
});

// Mise à l'échelle d'une image plus grande.
const downSize = { width: 64, height: 64 };
nativeImage.createThumbnailFromPath(imagePath, downSize).then((result) => {
  console.log(result.getSize()); // { width: 64, height: 64 }
});

Nouvelles fonctionnalités​

• Ajout de la possibilité de filtrer les cookies HttpOnly avec cookies.get(). #37365
• Ajout de logUsage aux options shell.openExternal(), permettant ainsi de passer l’indicateur SEE_MASK_FLAG_LOG_USAGE à ShellExecuteEx sous Windows. Le drapeau SEE_MASK_FLAG_LOG_USAGE indique un lancement initié par l’utilisateur qui permet de suivre les programmes fréquemment utilisés et d’autres comportements. #37291
• Ajout de types au filtre de webRequest, ajoutant la possibilité de filtrer les requêtes que vous écoutez. #37427
• Ajout du nouvel événement devtools-open-url à webContents permettant aux développeurs d’ouvrir de nouvelles fenêtres avec eux. #36774
• Ajout de plusieurs options de taille de page standard à webContents.print(). #37265
• Ajout du drapeau enableLocalEcho à la callback ses.setDisplayMediaRequestHandler() du gestionnaire de session pour permettre la reprise dans le flux de sortie local d'entrée audio distante lorsque audio est un WebFrameMain. #37528
• Permet de transmettre à inAppPurchase.purchaseProduct()un nom d’utilisateur spécifique à une application. #35902
• window.invalidateShadow() pour effacer les artefacts visuels résiduels sur macOS. #32452
• L’optimisation de l’ensemble du programme est maintenant activée par défaut dans le fichier de configuration de node d'Electron, permettant au compilateur d’effectuer des opimisations avec les informations de tous les modules d’un programme par opposition à une base par module (compilation). #36937
• SystemPreferences::CanPromptTouchID (macOS) prend désormais en charge Apple Watch. #36935

Fin du support pour 21.x.y​

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

Comme indiqué dans Adieu, Windows 7/8/8., Electron 22 (Chromium 108) la date prévue de fin de vie sera prolongée du 30 mai 2023 au 10 octobre 2023. L’équipe Electron continuera à rétroporter sur Electron 22 tous les correctifs de sécurité qui font partie de ce programme jusqu’au 10 octobre 2023.

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.

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 ) !