Electron 31.0.0 est disponible ! It includes upgrades to Chromium 126.0.6478.36, V8 12.6, and Node 20.14.0.

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

• Extended WebContentsView to accept pre-existing webContents object. #42319
• Added support for NODE_EXTRA_CA_CERTS. #41689
• Updated window.flashFrame(bool) to flash continuously on macOS. #41391
• Removed WebSQL support #41868
• nativeImage.toDataURL will preserve PNG colorspace #41610
• Extended webContents.setWindowOpenHandler to support manual creation of BrowserWindow. #41432

Changements de la Stack​

• Chromium126.0.6478.36
  • New in 126
  • New in 125
• Node 20.14.0
  • Node 20.14.0 blog post
• V8 12.6

Electron 31 upgrades Chromium from 124.0.6367.49 to 126.0.6478.36, Node from 20.11.1 to 20.14.0, and V8 from 12.4 to 12.6.

Nouvelles fonctionnalités​

• Added clearData method to Session. #40983
  • Added options parameter to Session.clearData API. #41355
• Added support for Bluetooth ports being requested by service class ID in navigator.serial. #41638
• Added support for Node's NODE_EXTRA_CA_CERTS environment variable. #41689
• Extended webContents.setWindowOpenHandler to support manual creation of BrowserWindow. #41432
• Implemented support for the web standard File System API. #41419
• Extended WebContentsView to accept pre-existing WebContents instances. #42319
• Added a new instance property navigationHistory on webContents API with navigationHistory.getEntryAtIndex method, enabling applications to retrieve the URL and title of any navigation entry within the browsing history. #41577 ^{(Also in 29, 30)}

Changements majeurs avec rupture de compatibilité​

Removed: WebSQL support​

Chromium has removed support for WebSQL upstream, transitioning it to Android only. See Chromium's intent to remove discussion for more information.

Behavior Changed: nativeImage.toDataURL will preseve PNG colorspace​

PNG decoder implementation has been changed to preserve colorspace data. The encoded data returned from this function now matches it.

See crbug.com/332584706 for more information.

Behavior Changed: win.flashFrame(bool) will flash dock icon continuously on macOS​

This brings the behavior to parity with Windows and Linux. Prior behavior: The first flashFrame(true) bounces the dock icon only once (using the NSInformationalRequest level) and flashFrame(false) does nothing. New behavior: Flash continuously until flashFrame(false) is called. This uses the NSCriticalRequest level instead. To explicitly use NSInformationalRequest to cause a single dock icon bounce, it is still possible to use dock.bounce('informational').

Fin du support pour 28.x.y​

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

Electron 30.0.0 est disponible ! It includes upgrades to Chromium 124.0.6367.49, V8 12.4, and Node.js 20.11.1.

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

• ASAR Integrity fuse now supported on Windows (#40504)
  • Existing apps with ASAR Integrity enabled may not work on Windows if not configured correctly. Apps using Electron packaging tools should upgrade to @electron/packager@18.3.1 or @electron/forge@7.4.0.
  • Take a look at our ASAR Integrity tutorial for more information.
• Added WebContentsView and BaseWindow main process modules, deprecating & replacing BrowserView (#35658). Learn more about how to migrate from BrowserView to WebContentsView in this blog post.
  • BrowserView is now a shim over WebContentsView and the old implementation has been removed.
  • See our Web Embeds documentation for a comparison of the new WebContentsView API to other similar APIs.
• Implemented support for the File System API (#41827)

Changements de la Stack​

• Chromium 124.0.6367.49
  • Nouveau dans Chrome 124 et dans DevTools 124
  • Nouveau dans Chrome 123 et dans DevTools 123
• Node 20.11.1
  • Node 20.11.1 notes
• V8 12.4

Electron 30 upgrades Chromium from 122.0.6261.39 to 124.0.6367.49, Node from 20.9.0 to 20.11.1, and V8 from 12.2 to 12.4.

Nouvelles fonctionnalités​

• Added a transparent webpreference to webviews. (#40301)
• Added a new instance property navigationHistory on webContents API with navigationHistory.getEntryAtIndex method, enabling applications to retrieve the URL and title of any navigation entry within the browsing history. (#41662)
• Added new BrowserWindow.isOccluded() method to allow apps to check occlusion status. (#38982)
• Added proxy configuring support for requests made with the net module from the utility process. (#41417)
• Added support for Bluetooth ports being requested by service class ID in navigator.serial. (#41734)
• Added support for the Node.js NODE_EXTRA_CA_CERTS CLI flag. (#41822)

Changements majeurs avec rupture de compatibilité​

Behavior Changed: cross-origin iframes now use Permission Policy to access features​

Cross-origin iframes must now specify features available to a given iframe via the allow attribute in order to access them.

See documentation for more information.

Removed: The --disable-color-correct-rendering command line switch​

This switch was never formally documented but its removal is being noted here regardless. Chromium itself now has better support for color spaces so this flag should not be needed.

Behavior Changed: BrowserView.setAutoResize behavior on macOS​

In Electron 30, BrowserView is now a wrapper around the new WebContentsView API.

Previously, the setAutoResize function of the BrowserView API was backed by autoresizing on macOS, and by a custom algorithm on Windows and Linux. For simple use cases such as making a BrowserView fill the entire window, the behavior of these two approaches was identical. However, in more advanced cases, BrowserViews would be autoresized differently on macOS than they would be on other platforms, as the custom resizing algorithm for Windows and Linux did not perfectly match the behavior of macOS's autoresizing API. The autoresizing behavior is now standardized across all platforms.

If your app uses BrowserView.setAutoResize to do anything more complex than making a BrowserView fill the entire window, it's likely you already had custom logic in place to handle this difference in behavior on macOS. If so, that logic will no longer be needed in Electron 30 as autoresizing behavior is consistent.

Removed: params.inputFormType property on context-menu on WebContents​

The inputFormType property of the params object in the context-menu event from WebContents has been removed. Use the new formControlType property instead.

Supprimé : process.getIOCounters()​

Chromium has removed access to this information.

Fin du support pour 27.x.y​

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

Nous sommes heureux d'annoncer qu'Electron a été accepté en tant qu'organisation de mentorat pour la 20e édition du Google Summer of Code (GSoC) 2024 ! Le Google Summer of Code est un programme mondial visant à amener de nouveaux contributeurs à participer au développement de logiciels libres.

Pour plus de détails sur le programme, consultez la page d'accueil de Google Summer of Code.

À propos de nous​

Electron est un framework JavaScript pour la construction d'applications de bureau multi-plateformes en utilisant les technologies web. Le framework cœur d'Electron est un exécutable binaire compilé avec Chromium et Node.js, et est principalement écrit en C++.

En dehors du cœur d'Electron, nous travaillons également sur une variété de projets pour aider à soutenir l'organisation Electron, comme :

• Outil de distribution de l'utilisateur final (par exemple Electron Forge et update.electronjs.org).
• Matériaux d'apprentissage pour les développeurs d'Electron (par exemple electronjs.org et Electron Fiddle).
• Outils internes pour rationaliser la productivité des développeurs (par exemple Electron Build Tools et Sheriff).

En tant que contributeur du Summer of Code, vous seriez en train de collaborer avec certains des principaux contributeurs d'Electron sur l'un des nombreux projets sous github.com/electron parapluie.

Avant la demande​

Si vous n'êtes pas très familier avec Electron, nous vous recommandons de commencer par lire la documentation et d'essayer des exemples dans Electron Fiddle.

Pour en savoir plus sur la distribution des applications Electron, vous pouvez également jouer avec Electron Forge en créant un exemple d'application :

npm init electron-app@latest my-app

Après vous être familiarisé un peu avec le code, venez rejoindre la conversation sur le serveur Discord Electron.

Ébauche de votre proposition​

Êtes-vous intéressé à collaborer avec Electron? Premièrement, prenez le temps de regarder les sept idées de projets brouillons que nous avons préparé. Toutes les idées listées sont actuellement ouvertes aux propositions.

Vous avez une idée différente que vous aimeriez que nous prenions en considération ? Nous sommes également ouverts à l'acceptation de nouvelles idées que ne sont pas sur la liste de projet proposée, mais assurez-vous que votre approche est détaillée et détaillée. En cas de doute, nous vous recommandons de vous en tenir à nos idées énumérées.

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 curriculum vitae, veuillez en inclure une copie. Sinon, parlez nous de votre expérience technique passée.
  • Le manque d'expérience dans certains domaines ne vous disqualifiera pas, mais cela aidera nos mentors à élaborer un plan pour vous soutenir au mieux et s'assurer que votre projet d'été est couronné de succès.

Un guide détaillé de ce qu'il faut soumettre dans le cadre de votre demande Electron est ici. Soumettez des propositions directement sur le portail Google Summer of Code. Notez que les propositions envoyées à l'équipe Electron plutôt que soumises via le portail de candidature ne seront pas considérées comme une soumission finale.

Si vous voulez plus de conseils sur votre proposition ou si vous n'êtes pas certain de ce qu'il faut inclure, nous vous recommandons également de suivre le conseil officiel de Google Summer of Code en écrivant des propositions.

Les demandes sont ouvertes le 18 mars 2024 et fermées le 2 avril 2024.

Questions?​

Si vous avez des questions que nous n'avons pas traitées dans le blog ou des demandes de renseignements pour votre projet de proposition, veuillez nous envoyer un email à summer-of-code@electronjs. rg ou vérifiez GSoC FAQ!

Ressources​

• Liste des idées d'Electron Google Summer of Code 2024
• [Guide du contributeur Electron Google Summer of Code 2024] (https://electronhq.notion.site/Electron-GSoC-2024-Contributor-Guidance-f1f4de7a0d9a4664a96c8d4dd70cb208?pvs=4)
• Google Summer of Code Student/Contributeur Guide

Electron 29.0.0 est disponible ! Comprend des mises à niveaux vers et Node.js.

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

• Added a new top-level webUtils module, a renderer process module that provides a utility layer to interact with Web API objects. The first available API in the module is webUtils.getPathForFile. Electron's previous File.path augmentation was a deviation from web standards; this new API is more in line with current web standards behavior.

Changements de la Stack​

• Chromium 122.0.6261.39
  • Nouveau dans Chrome 122 et dans DevTools 122
  • Nouveau dans Chrome 121 et dans DevTools 121
• Node 20.9.0
  • Node 20.9.0 notes
  • Node 20.0.0 notes
• V8 12.2

Electron 29 upgrades Chromium from 120.0.6099.56 to 122.0.6261.39, Node from 18.18.2 to 20.9.0, and V8 from 12.0 to 12.2.

Nouvelles fonctionnalités​

• Added new webUtils module, a utility layer to interact with Web API objects, to replace File.path augmentation. #38776
• Added net module to utility process. #40890
• Added a new Electron Fuse, grantFileProtocolExtraPrivileges, that opts the file:// protocol into more secure and restrictive behaviour that matches Chromium. #40372
• Added an option in protocol.registerSchemesAsPrivileged to allow V8 code cache in custom schemes. #40544
• Migrated app.{set|get}LoginItemSettings(settings) to use Apple's new recommended underlying framework on macOS 13.0+. #37244

Changements majeurs avec rupture de compatibilité​

Comportement changement : ipcRenderer ne peut plus être envoyée vers contextBridge​

Attempting to send the entire ipcRenderer module as an object over the contextBridge will now result in an empty object on the receiving side of the bridge. This change was made to remove / mitigate a security footgun. You should not directly expose ipcRenderer or its methods over the bridge. Instead, provide a safe wrapper like below:

contextBridge.exposeInMainWorld('app', {
  onEvent: (cb) => ipcRenderer.on('foo', (e, ...args) => cb(args)),
});

Removed: renderer-process-crashed event on app​

The renderer-process-crashed event on app has been removed. Use the new render-process-gone event instead.

// Removed
app.on('renderer-process-crashed', (event, webContents, killed) => {
  /* ... */
});

// Replace with
app.on('render-process-gone', (event, webContents, details) => {
  /* ... */
});

Removed: crashed event on WebContents and <webview>​

The crashed events on WebContents and <webview> have been removed. Use the new render-process-gone event instead.

// Removed
win.webContents.on('crashed', (event, killed) => {
  /* ... */
});
webview.addEventListener('crashed', (event) => {
  /* ... */
});

// Replace with
win.webContents.on('render-process-gone', (event, details) => {
  /* ... */
});
webview.addEventListener('render-process-gone', (event) => {
  /* ... */
});

Removed: gpu-process-crashed event on app​

The gpu-process-crashed event on app has been removed. Use the new child-process-gone event instead.

// Removed
app.on('gpu-process-crashed', (event, killed) => {
  /* ... */
});

// Replace with
app.on('child-process-gone', (event, details) => {
  /* ... */
});

Fin du support pour 26.x.y​

Electron 26.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 ?​

Did you know that Electron recently added a community Request for Comments (RFC) process? Si vous voulez ajouter une fonctionnalité à la structure, RFCs cela peut être un outil utile. Vous pouvez aussi voir les prochains changement en cours de discussion dans demande d'extraction. Pour en apprendre plus, vérifier notre [Introduction electron/rfc] (https://www.electronjs.org/blog/rfcs) article de blog, ou vérifier le README du [electron/rfcs] (https://www.github.com/electron/rfcs) dépôt directement.

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

Electron’s API Working Group is adopting an open Requests for Comments (RFC) process to help shepherd larger changes to Electron core.

Why RFCs?​

In short, we want to smooth out the process of landing significant changes to Electron core.

Currently, new code changes are mostly discussed through issues and pull requests on GitHub. For most changes to Electron, this is a good system. Many bug fixes, documentation changes, and even new features are straightforward enough to review and merge asynchronously through standard GitHub flows.

For changes that are more significant—for instance, large API surfaces or breaking changes that would affect the majority of Electron apps—it makes sense for review to happen at the ideation stage before most of the code is written.

This process is designed to be open to the public, which will also make it easier for the open source community at large to give feedback on potential changes before they land in Electron.

Comment ça marche ?​

The entire RFC process lives in the electron/rfcs repository on GitHub. The steps are described in detail in the repository README.

In brief, an RFC is Proposed once a PR is made to the electron/rfcs repository. A Proposed RFC becomes:

• Active when the PR is merged into the main branch of the repository, which means that Electron maintainers are amenable to an implementation in electron/electron, or
• Declined if the PR is ultimately rejected.

An Active RFC is Completed if the implementation has been merged into electron/electron.

Who can participate?​

Anyone in the Electron community can submit RFCs or leave feedback on the electron/rfcs repository!

• To see the list of active RFCs, refer to the text folder in the repository.
• To leave feedback on proposed RFCs, check out the list of open PRs.
• To submit a new RFC, check out the repo’s README and the RFC template.

We wanted to make this process a two-way dialogue and encourage community participation to get a diverse set of opinions from Electron apps that might consume these APIs in the future. If you’re interested in leaving feedback on currently proposed RFCs, the Electron maintainers have already created a few:

• Electron C APIs
• Preload Realm for Service Workers

Credits​

Electron's RFC process was modeled on many established open source RFC processes. Inspiration for many ideas and major portions of copywriting go to:

• emberjs/rfcs
• reactjs/rfcs
• rust-lang/rfcs
• tauri-apps/rfcs
• vuejs/rfcs
• yarnpkg/rfcs

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​

• Passé à notarytool pour la macOS notarization : À partir de 2023-11-01, Apple sunset l''ancien altool pour la macOS notarization, et cette version le retire d'Electron Forge entièrement.
• Node.js minimum augmenté à v16.4.0 : Avec cette version, nous avons défini la version minimale requise de Node.js à 16.4.0.
• Abandonné le support de electron-prebuilt et electron-prebuilt-compile: electron-prebuilt était le nom original du module npm d'Electron, mais a été remplacé par electron dans la v1.3.1. electron-prebuilt-compile était une alternative à ce binaire qui apportait des fonctionnalités DX améliorées, mais fut finalement abandonné en tant que projet.

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 ✨ . Depuis, nous avons testé la parallélisation de l'étape Make sans effets secondaires négatifs, donc vous devriez voir une accélération lors de la construction de plusieurs cibles pour la même plateforme !

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

Squirrel.Windows et Squirrel.Mac sont des technologies de mise à jour spécifiques à la plate-forme qui soutiennent le module autoUpdater intégré d'Electron. Les deux projets prennent en charge les mises à jour automatiques via deux méthodes :

• Un serveur de mise à jour compatible avec Squirrel
• Un manifest URL est hébergée sur un fournisseur de stockage statique (ex : AWS, Google Cloud Platform, Microsoft Azure, etc.)

La méthode du serveur de mise à jour a traditionnellement été l'approche recommandée pour les applications Electron (et fournit une personnalisation supplémentaire de la logique de mise à jour), mais il a un inconvénient majeur — il faut que les applications maintiennent leur propre instance de serveur si elles sont fermées.

D'un autre côté, la méthode de stockage statique a toujours été possible, mais n'a pas été documentée dans Electron et mal supportée dans les paquets d'outillage d'Electron.

Avec un excellent travail de @MarshallOfSound, l'histoire de mise à jour pour les mises à jour automatiques des applications sans serveur a été considérablement rationalisée :

• Les créateurs de Zip et Squirrel.Windows d'Electron Forge peuvent maintenant être configurés pour afficher les événements de mise à jour compatibles avec autoUpdater.
• Une nouvelle version majeure de update-electron-app (v2.0.0) peut maintenant lire ces manifestes générés comme alternative au serveur update.electronjs.org.

Une fois que vos Makers et Publishers sont configurés pour télécharger des manifestes de mise à jour vers le stockage de fichiers dans le cloud, vous pouvez activer les mises à jour automatiques avec seulement quelques lignes de 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

Pour aller de l'avant, tous les paquets de première partie que nous publions seront également dans l'espace de noms @electron/. Il y a deux exceptions à cette règle :

• Le noyau d'Electron continuera d'être publié dans le paquet electron.
• Electron Forge continuera à publier tous ses paquets monorepo dans l'espace de noms @electron-forge/.

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.

Cette situation a été un point de douleur courant pour les développeurs d'Electron, c'est pourquoi nous avons travaillé sur une meilleure solution qui isole la signature du code Windows dans sa propre étape autonome. similaire à ce que @electron/osx-sign fait sur macOS.

Dans le futur, nous prévoyons d'intégrer complètement ce paquet dans la toolchain d'Electron Forge, mais il vit tout seul. Le paquet est actuellement disponible pour l'installation à npm install --save-dev @electron/windows-sign et peut être utilisé par programmation ou 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 ?​

Nous entrerons dans notre période annuelle de repos de décembre le mois prochain. Pendant que nous le faisons, nous réfléchirons à la manière dont nous pouvons améliorer l'expérience de développement d'Electron en 2024.

Y a-t-il quelque chose que vous aimeriez que nous fassions travailler sur la suite ? 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.