La team Electron est excitée d'annoncer la sortie de Electron 5.0.0 ! You can install it with npm via npm install electron@latest or download the tarballs from our releases page. Cette version inclue des mises à jour, des correctifs et de nouvelles fonctionnalités. On a hâte de voir vos prochaines créations avec cette version ! Continuez de lire pour plus de détails sur cette version, et s'il vous plaît, partagez vos commentaires et remarques !

Quoi de neuf ?​

Much of Electron's functionality is provided by the core components of Chromium, Node.js, and V8. Electron keeps up-to-date with these projects to provide our users with new JavaScript features, performance improvements, and security fixes. Each of these packages has a major version bump in Electron 5:

• Chromium 73.0.3683.119
  • New in 70
  • New in 71
  • New in 72
  • New in 73
• Node.js 12.0.0
  • Node 12 Blog Post
• V8 7.3.492.27.
  • New JS Features

Electron 5 also includes improvements to Electron-specific APIs. A summary of the major changes is below; for the full list of changes, check out the Electron v5.0.0 release notes.

Promisification​

Electron 5 continues Promisification initiative initiative to convert Electron's callback-based API to use Promises. These APIs were converted for Electron 5:

• app.getFileIcon
• contentTracing.getCategories
• contentTracing.startRecording
• contentTracing.stopRecording
• debugger.sendCommand
• Cookies API
• shell.openExternal
• webContents.loadFile
• webContents.loadURL
• webContents.zoomLevel
• webContents.zoomFactor
• win.capturePage

System colors access for macOS​

These functions were changed or added to systemPreferences to access macOS systems' colors:

• systemPreferences.getAccentColor
• systemPreferences.getColor
• systemPreferences.getSystemColor

Process memory information​

The function process.getProcessMemoryInfo has been added to get memory usage statistics about the current process.

Additional filtering for remote APIs​

To improve security in the remote API, new remote events have been added so that remote.getBuiltin, remote.getCurrentWindow, remote.getCurrentWebContents and <webview>.getWebContents can be filtered.

Multiple BrowserViews on BrowserWindow​

BrowserWindow now supports managing multiple BrowserViews within the same BrowserWindow.

Changements majeurs avec rupture de compatibilité​

Defaults for packaged apps​

Packaged apps will now behave the same as the default app: a default application menu will be created unless the app has one and the window-all-closed event will be automatically handled unless the app handles the event.

Mixed sandbox​

Mixed sandbox mode is now enabled by default. Renderers launched with sandbox: true will now be actually sandboxed, where previously they would only be sandboxed if mixed-sandbox mode was also enabled.

Security improvements​

The default values of nodeIntegration and webviewTag are now false to improve security.

Spellchecker now asynchronous​

The SpellCheck API has been changed to provide asynchronous results.

Deprecations​

The following APIs are newly deprecated in Electron 5.0.0 and planned for removal in 6.0.0:

Mksnapshot binaries for arm and arm64​

Les binaires natifs de mksnapshot pour arm et arm64 sont dépréciés et seront supprimés en 6. . 0. Des instantanés peuvent être créés pour les arm et arm64 à l’aide des binaires x64.

ServiceWorker APIs on WebContents​

Deprecated ServiceWorker APIs on WebContents in preparation for their removal.

• webContents.hasServiceWorker
• webContents.unregisterServiceWorker

Automatic modules with sandboxed webContents​

In order to improve security, the following modules are being deprecated for use directly via require and will instead need to be included via remote.require in a sandboxed webcontents:

• electron.screen
• child_process
• fs
• os
• path

webFrame Isolated World APIs​

webFrame.setIsolatedWorldContentSecurityPolicy,webFrame.setIsolatedWorldHumanReadableName, webFrame.setIsolatedWorldSecurityOrigin have been deprecated in favor of webFrame.setIsolatedWorldInfo.

Mixed sandbox​

enableMixedSandbox and the --enable-mixed-sandbox command-line switch still exist for compatibility, but are deprecated and have no effect.

End of support for 2.0.x​

Per our supported versions policy, 2.0.x has reached end of life.

Programme de feedback​

Nous continuons à utiliser notre Programme de Feedback de l'application pour les tests. Les projets qui participent à ce programme testent les bétas d'Electron sur leurs applications ; et en retour, les nouveaux bogues qu'ils trouvent sont priorisés pour la version stable. Si vous souhaitez participer ou en savoir plus, consultez notre blog sur le programme.

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. Bien que nous veillions à ne pas faire de promesses à propos des dates de publication, notre plan est la sortie de nouvelles versions majeures d'Electron avec de nouvelles versions de ces composants environ un trimestre. Le planning escompté de la version 6.0.0 planning défini les dates clés du cycle de vie de développement d'Electron 6. Aussi, regardez notre document de versioning pour plus d'informations sur le versioning dans Electron.

Pour des informations sur les changements de rupture prévus dans les versions à venir d'Electron, regardez notre documentation sur les changements de rupture planifiés.

If you're having trouble using a native Node.js addon with Electron 5.0, there's a chance it needs to be updated to work with the most recent version of V8.

Goodbye v8::Handle, Hello v8::Local​

In 2014, the V8 team deprecated v8::Handle in favor of v8::Local for local handles. Electron 5.0 includes a version of V8 that has finally removed v8::Handle for good, and native Node.js addons that still use it will need to be updated before they can be used with Electron 5.0.

The required code change is minimal, but every native Node module that still uses v8::Handle will fail to build with Electron 5.0 and will need to be modified. The good news is that Node.js v12 will also include this V8 change, so any modules that use v8::Handle will need to be updated anyway to work with the upcoming version of Node.

I maintain a native addon, how can I help?​

If you maintain a native addon for Node.js, ensure you replace all occurrences of v8::Handle with v8::Local. The former was just an alias of the latter, so no other changes need to be made to address this specific issue.

You may also be interested in looking into N-API, which is maintained separately from V8 as a part of Node.js itself, and aims to insulate native addons from changes in the underlying JavaScript engine. You can find more information in the N-API documentation on the Node.js website.

Help! I use a native addon in my app and it won't work!​

If you're consuming a native addon for Node.js in your app and the native addon will not build because of this issue, check with the author of the addon to see if they've released a new version that fixes the problem. If not, reaching out to the author (or opening a Pull Request!) is probably your best bet.

Pour la première fois, Electron est heureux de publier notre calendrier de publication à partir de la version 5. Il s’agit de notre première étape pour avoir une échéancière publique à long terme.

As mentioned in our v4.0.0 stable release blog post, we are planning to release approximately quarterly to maintain closer cadence with Chromium releases. Chromium releases a new version very quickly -- every 6 weeks.

Take a look at progression in Electron versus Chromium side-by-side:

In the last half of 2018, our top priority was releasing faster and catching up closer to Chromium. We succeeded by sticking to a predetermined timeline. Electron 3.0.0 and 4.0.0 were released in a 2-3 month timeline for each release. We are optimistic about continuing that pace in releasing 5.0.0 and beyond. With a major Electron release approximately every quarter, we're now keeping pace with Chromium's release cadence. Getting ahead of Chromium stable release is always a goal for us and we are taking steps towards that.

We would love to promise future dates like Node.js and Chromium do, but we are not at that place yet. We are optimistic that we will reach a long-term timeline in the future.

Dans cet esprit, nous prenons les premières mesures en publiant notre calendrier de publication pour la version 5.0.0. Vous pouvez trouver cela ici.

To help us with testing our beta releases and stabilization, please consider joining our App Feedback Program.

The Electron team is excited to announce that the stable release of Electron 4 is now available! You can install it from electronjs.org or from npm via npm install electron@latest. The release is packed with upgrades, fixes, and new features, and we can't wait to see what you build with them. Read more for details about this release, and please share any feedback you have as you explore!

Quoi de neuf ?​

A large part of Electron's functionality is provided by Chromium, Node.js, and V8, the core components that make up Electron. As such, a key goal for the Electron team is to keep up with changes to these projects as much as possible, providing developers who build Electron apps access to new web and JavaScript features. To this end, Electron 4 features major version bumps to each of these components; Electron v4.0.0 includes Chromium 69.0.3497.106, Node 10.11.0, and V8 6.9.427.24.

In addition, Electron 4 includes changes to Electron-specific APIs. You can find a summary of the major changes in Electron 4 below; for the full list of changes, check out the Electron v4.0.0 release notes.

Disabling the remote Module​

You now have the ability to disable the remote module for security reasons. The module can be disabled for BrowserWindows and for webview tags:

// BrowserWindow
new BrowserWindow({
  webPreferences: {
    enableRemoteModule: false
  }
})

// webview tag
<webview src="http://www.google.com/" enableremotemodule="false"></webview>

See the BrowserWindow and <webview> Tag documentation for more information.

Filtering remote.require() / remote.getGlobal() Requests​

This feature is useful if you don't want to completely disable the remote module in your renderer process or webview but would like additional control over which modules can be required via remote.require.

When a module is required via remote.require in a renderer process, a remote-require event is raised on the app module. You can call event.preventDefault() on the the event (the first argument) to prevent the module from being loaded. The WebContents instance where the require occurred is passed as the second argument, and the name of the module is passed as the third argument. The same event is also emitted on the WebContents instance, but in this case the only arguments are the event and the module name. In both cases, you can return a custom value by setting the value of event.returnValue.

// Control `remote.require` from all WebContents:
app.on('remote-require', function (event, webContents, requestedModuleName) {
  // ...
});

// Control `remote.require` from a specific WebContents instance:
browserWin.webContents.on(
  'remote-require',
  function (event, requestedModuleName) {
    // ...
  }
);

In a similar fashion, when remote.getGlobal(name) is called, a remote-get-global event is raised. This works the same way as the remote-require event: call preventDefault() to prevent the global from being returned, and set event.returnValue to return a custom value.

// Control `remote.getGlobal` from all WebContents:
app.on(
  'remote-get-global',
  function (event, webContents, requrestedGlobalName) {
    // ...
  }
);

// Control `remote.getGlobal` from a specific WebContents instance:
browserWin.webContents.on(
  'remote-get-global',
  function (event, requestedGlobalName) {
    // ...
  }
);

Pour plus d'informations, consultez la documentation suivante :

• remote.require
• remote.getGlobal
• app
• WebContents

JavaScript Access to the About Panel​

On macOS, you can now call app.showAboutPanel() to programmatically show the About panel, just like clicking the menu item created via {role: 'about'}. See the showAboutPanel documentation for more information

Controlling WebContents Background Throttling​

WebContents instances now have a method setBackgroundThrottling(allowed) to enable or disable throttling of timers and animations when the page is backgrounded.

let win = new BrowserWindow(...)
win.webContents.setBackgroundThrottling(enableBackgroundThrottling)

See the setBackgroundThrottling documentation for more information.

Changements majeurs avec rupture de compatibilité​

No More macOS 10.9 Support​

Chromium no longer supports macOS 10.9 (OS X Mavericks), and as a result Electron 4.0 and beyond does not support it either.

Single Instance Locking​

Previously, to make your app a Single Instance Application (ensuring that only one instance of your app is running at any given time), you could use the app.makeSingleInstance() method. Starting in Electron 4.0, you must use app.requestSingleInstanceLock() instead. The return value of this method indicates whether or not this instance of your application successfully obtained the lock. If it failed to obtain the lock, you can assume that another instance of your application is already running with the lock and exit immediately.

For an example of using requestSingleInstanceLock() and information on nuanced behavior on various platforms, see the documentation for app.requestSingleInstanceLock() and related methods and the second-instance event.

win_delay_load_hook​

When building native modules for windows, the win_delay_load_hook variable in the module's binding.gyp must be true (which is the default). If this hook is not present, then the native module will fail to load on Windows, with an error message like Cannot find module. See the native module guide for more information.

Deprecations​

The following breaking changes are planned for Electron 5.0, and thus are deprecated in Electron 4.0.

Node.js Integration Disabled for nativeWindowOpen-ed Windows​

Starting in Electron 5.0, child windows opened with the nativeWindowOpen option will always have Node.js integration disabled.

webPreferences Default Values​

When creating a new BrowserWindow with the webPreferences option set, the following webPreferences option defaults are deprecated in favor of new defaults listed below:

Please note: there is currently a known bug (#9736) that prevents the webview tag from working if contextIsolation is on. Keep an eye on the GitHub issue for up-to-date information!

Learn more about context isolation, Node integration, and the webview tag in the Electron security document.

Electron 4.0 will still use the current defaults, but if you don't pass an explicit value for them, you'll see a deprecation warning. To prepare your app for Electron 5.0, use explicit values for these options. See the BrowserWindow docs for details on each of these options.

webContents.findInPage(text[, options])​

The medialCapitalAsWordStart and wordStart options have been deprecated as they have been removed upstream.

Programme de feedback​

The App Feedback Program we instituted during the development of Electron 3.0 was successful, so we've continued it during the development of 4.0 as well. We'd like to extend a massive thank you to Atlassian, Discord, MS Teams, OpenFin, Slack, Symphony, WhatsApp, and the other program members for their involvement during the 4.0 beta cycle. To learn more about the App Feedback Program and to participate in future betas, check out our blog post about the program.

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. Bien que nous veillions à ne pas faire de promesses à propos des dates de publication, notre plan est la sortie de nouvelles versions majeures d'Electron avec de nouvelles versions de ces composants environ un trimestre. Consultez notre document de gestion des versions pour plus d’informations sur le contrôle de version dans Electron.

Pour des informations sur les changements de rupture prévus dans les versions à venir d'Electron, regardez notre documentation sur les changements de rupture planifiés.

The Electron team is excited to announce that the first stable release of Electron 3 is now available from electronjs.org and via npm install electron@latest! It's jam-packed with upgrades, fixes, and new features, and we can't wait to see what you build with them. Below are details about this release, and we welcome your feedback as you explore.

Release Process​

As we undertook development of v3.0.0, we sought to more empirically define criteria for a stable release by formalizing the feedback progress for progressive beta releases. v3.0.0 would not have been possible without our App Feedback Program partners, who provided early testing and feedback during the beta cycle. Thanks to Atlassian, Atom, Microsoft Teams, Oculus, OpenFin, Slack, Symphony, VS Code, and other program members for their work. If you'd like to participate in future betas, please mail us at info@electronjs.org.

Changes / New Features​

Major bumps to several important parts of Electron's toolchain, including Chrome v66.0.3359.181, Node v10.2.0, and V8 v6.6.346.23.

• [#12656] feat: app.isPackaged
• [#12652] feat: app.whenReady()
• [#13183] feat: process.getHeapStatistics()
• [#12485] feat: win.moveTop() to move window z-order to top
• [#13110] feat: TextField and Button APIs
• [#13068] feat: netLog API for dynamic logging control
• [#13539] feat: enable webview in sandbox renderer
• [#14118] feat: fs.readSync now works with massive files
• [#14031] feat: node fs wrappers to make fs.realpathSync.native and fs.realpath.native available

Modifications majeures de l'API​

• [#12362] feat: updates to menu item order control
• [#13050] refactor: removed documented deprecated APIs
  • See docs for more details
• [#12477] refactor: removed did-get-response-details and did-get-redirect-request events
• [#12655] feat: default to disabling navigating on drag/drop
• [#12993] feat: Node v4.x or greater is required use the electron npm module
• [#12008 #12140 #12503 #12514 #12584 #12596 #12637 #12660 #12696 #12716 #12750 #12787 #12858] refactor: NativeWindow
• [#11968] refactor: menu.popup()
• [#8953] feat: no longer use JSON to send the result of ipcRenderer.sendSync
• [#13039] feat: default to ignore command line arguments following a URL
• [#12004] refactor: rename api::Window to api::BrowserWindow
• [#12679] feat: visual zoom now turned off by default
• [#12408] refactor: rename app-command media-play_pause to media-play-pause

macOS​

• [#12093] feat: workspace notifications support
• [#12496] feat: tray.setIgnoreDoubleClickEvents(ignore) to ignore tray double click events.
• [#12281] feat: mouse forward functionality on macOS
• [#12714] feat: screen lock / unlock events

Windows​

• [#12879] feat: added DIP to/from screen coordinate conversions

Nota Bene: Switching to an older version of Electron after running this version will require you to clear out your user data directory to avoid older versions crashing. You can get the user data directory by running console.log(app.getPath("userData")) or see docs for more details.

Bug Fixes​

• [#13397] fix: issue with fs.statSyncNoException throwing exceptions
• [#13476, #13452] fix: crash when loading site with jquery
• [#14092] fix: crash in net::ClientSocketHandle destructor
• [#14453] fix: notify focus change right away rather not on next tick

MacOS​

• [#13220] fix: issue allowing bundles to be selected in <input file="type"> open file dialog
• [#12404] fix: issue blocking main process when using async dialog
• [#12043] fix: context menu click callback
• [#12527] fix: event leak on reuse of touchbar item
• [#12352] fix: tray title crash
• [#12327] fix: non-draggable regions
• [#12809] fix: to prevent menu update while it's open
• [#13162] fix: tray icon bounds not allowing negative values
• [#13085] fix: tray title not inverting when highlighted
• [#12196] fix: Mac build when enable_run_as_node==false
• [#12157] fix: additional issues on frameless windows with vibrancy
• [#13326] fix: to set mac protocol to none after calling app.removeAsDefaultProtocolClient
• [#13530] fix: incorrect usage of private APIs in MAS build
• [#13517] fix: tray.setContextMenu crash
• [#14205] fix: pressing escape on a dialog now closes it even if defaultId is set

Linux​

• [#12507] fix: BrowserWindow.focus() for offscreen windows

Other Notes​

• PDF Viewer is currently not working but is being worked on and will be functional once again soon
• TextField and Button APIs are experimental and are therefore off by default
  • They can be enabled with the enable_view_api build flag

Et maintenant ?

The Electron team continues to work on defining our processes for more rapid and smooth upgrades as we seek to ultimately maintain parity with the development cadences of Chromium, Node, and V8.

After more than four months of development, eight beta releases, and worldwide testing from many apps' staged rollouts, the release of Electron 2.0.0 is now available from electronjs.org.

Release Process​

Starting with 2.0.0, Electron's releases will follow semantic versioning. This means the major version will bump more often and will usually be a major update to Chromium. Patch releases should be more stable because they will contain only high-priority bug fixes.

Electron 2.0.0 also represents an improvement to how Electron is stabilized before a major release. Several large scale Electron apps have included 2.0.0 betas in staged rollouts, providing the best feedback loop Electron's ever had for a beta series.

Changes / New Features​

• Major bumps to several important parts of Electron's toolchain, including Chrome 61, Node 8.9.3, V8 6.1.534.41, GTK+ 3 on Linux, updated spellchecker, and Squirrel.
• In-app purchases are now supported on MacOS. #11292
• New API for loading files. #11565
• New API to enable/disable a window. #11832
• New API app.setLocale(). #11469
• New support for logging IPC messages. #11880
• New menu events. #11754
• Add a shutdown event to powerMonitor. #11417
• Add affinity option for gathering several BrowserWindows into a single process. #11501
• Add the ability for saveDialog to list available extensions. #11873
• Support for additional notification actions #11647
• The ability to set macOS notification close button title. #11654
• Add conditional for menu.popup(window, callback)
• Memory improvements in touchbar items. #12527
• Improved security recommendation checklist.
• Add App-Scoped Security scoped bookmarks. #11711
• Add ability to set arbitrary arguments in a renderer process. #11850
• Add accessory view for format picker. #11873
• Fixed network delegate race condition. #12053
• Drop support for the mips64el arch on Linux. Electron requires the C++14 toolchain, which was not available for that arch at the time of the release. We hope to re-add support in the future.

Modifications majeures de l'API​

• Removed deprecated APIs, including:
  • Changed menu.popup signature. #11968
  • Removed deprecated crashReporter.setExtraParameter #11972
  • Removed deprecated webContents.setZoomLevelLimits and webFrame.setZoomLevelLimits. #11974
  • Removed deprecated clipboard methods. #11973
  • Removed support for boolean parameters for tray.setHighlightMode. #11981

Bug Fixes​

• Changed to make sure webContents.isOffscreen() is always available. #12531
• Fixed BrowserWindow.getFocusedWindow() when DevTools is undocked and focused. #12554
• Fixed preload not loading in sandboxed render if preload path contains special chars. #12643
• Correct the default of allowRunningInsecureContent as per docs. #12629
• Fixed transparency on nativeImage. #12683
• Fixed issue with Menu.buildFromTemplate. #12703
• Confirmed menu.popup options are objects. #12330
• Removed a race condition between new process creation and context release. #12361
• Update draggable regions when changing BrowserView. #12370
• Fixed menubar toggle alt key detection on focus. #12235
• Fixed incorrect warnings in webviews. #12236
• Fixed inheritance of 'show' option from parent windows. #122444
• Ensure that getLastCrashReport() is actually the last crash report. #12255
• Fixed require on network share path. #12287
• Fixed context menu click callback. #12170
• Fixed popup menu position. #12181
• Improved libuv loop cleanup. #11465
• Fixed hexColorDWORDToRGBA for transparent colors. #11557
• Fixed null pointer dereference with getWebPreferences api. #12245
• Fixed a cyclic reference in menu delegate. #11967
• Fixed protocol filtering of net.request. #11657
• WebFrame.setVisualZoomLevelLimits now sets user-agent scale constraints #12510
• Set appropriate defaults for webview options. #12292
• Improved vibrancy support. #12157 #12171 #11886
• Fixed timing issue in singleton fixture.
• Fixed broken production cache in NotifierSupportsActions()
• Made MenuItem roles camelCase-compatible. #11532
• Improved touch bar updates. #11812, #11761.
• Removed extra menu separators. #11827
• Fixed Bluetooth chooser bug. Closes #11399.
• Fixed macos Full Screen Toggle menu item label. #11633
• Improved tooltip hiding when a window is deactivated. #11644
• Migrated deprecated web-view method. #11798
• Fixed closing a window opened from a browserview. #11799
• Fixed Bluetooth chooser bug. #11492
• Updated to use task scheduler for app.getFileIcon API. #11595
• Changed to fire console-message event even when rendering offscreen. #11921
• Fixed downloading from custom protocols using WebContents.downloadURL. #11804
• Fixed transparent windows losing transparency when devtools detaches. #11956
• Fixed Electron apps canceling restart or shutdown. #11625

macOS​

• Fixed event leak on reuse of touchbar item. #12624
• Fixed tray highlight in darkmode. #12398
• Fixed blocking main process for async dialog. #12407
• Fixed setTitle tray crash. #12356
• Fixed crash when setting dock menu. #12087

Linux​

• Better Linux desktop notifications. #12229 #12216 #11965 #11980
• Better GTK+ theme support for menus. #12331
• Exit gracefully on linux. #12139
• Use the app’s name as the tray icon's default tooltip. #12393

Windows​

• Added Visual Studio 2017 support. #11656
• Fixed passing of exception to the system crash handler. #12259
• Fixed hiding tooltip from minimized window. #11644
• Fixed desktopCapturer to capture the correct screen. #11664
• Fixed disableHardwareAcceleration with transparency. #11704

Et maintenant ?

The Electron team is hard at work to support newer versions of Chromium, Node, and v8. Expect 3.0.0-beta.1 soon!

A new major version of Electron is in the works, and with it some changes to our versioning strategy. As of version 2.0.0, Electron will strictly adhere to Semantic Versioning.

This change means you'll see the major version bump more often, and it will usually be a major update to Chromium. Patch releases will also be more stable, as they will now only contain bug fixes with no new features.

Incréments de version Majeure

• mises à jour de version Chromium
• Mises à jour de la version majeure de Node.js
• changement Electron qui altère l'API

Incréments de version mineure

• Mises à jour mineure de la version de Node.js
• changement Electron n'altérant pas l'API

Incréments de version de Correctifs

• Mises à jour des correctifs de Node.js
• mises à jour de correctifs Chromium
• Corrections de bugs d'Electron

Because Electron's semver ranges will now be more meaningful, we recommend installing Electron using npm's default --save-dev flag, which will prefix your version with ^, keeping you safely up to date with minor and patch updates:

npm install --save-dev electron

For developers interested only in bug fixes, you should use the tilde semver prefix e.g. ~2.0.0, which which will never introduce new features, only fixes to improve stability.

For more details, see electronjs.org/docs/tutorial/electron-versioning.

Au cours des deux dernières années, Electron a aidé des développeurs à créer des applications de bureau multiplateformes en utilisant HTML, CSS et JavaScript. Maintenant, nous sommes ravis de partager une étape majeure pour notre framework et pour la communauté qui l'a créé. La version d'Electron 1.0 est maintenant disponible sur electronjs.org.

Electron 1.0 représente un jalon majeur dans la stabilité et la maturité de l'API. Cette version vous permet de construire des applications qui agissent et se sentent vraiment natives sur Windows, Mac, et Linux. Construire des applications Electron est plus facile que jamais avec de nouvelles documentations, nouveaux outils et une nouvelle application pour vous guider à travers les API Electron.

Si vous êtes prêt à construire votre toute première application Electron, voici un guide de démarrage rapide pour vous aider à démarrer.

Nous sommes heureux de voir ce que vous construisez ensuite avec Electron.

Chemin d'Electron​

Nous avons libéré Electron lorsque nous avons lancé Atom il y a un peu plus de deux ans. Electron, alors connu sous le nom de Atom Shell, était le framework que nous avions construit sur Atom. À cette époque, Atom était la force motrice derrière les fonctionnements et les fonctionnalités qu'Electron a fourni en même temps que nous avons poussé à sortir la version initiale de Atom.

La conduite d'Electron est maintenant une communauté grandissante de développeurs et de sociétés qui construisent tout depuis email, chat, et Applications Git à Outils d'analyse SQL, clients torrent, et robots.

Au cours de ces deux dernières années, nous avons vu à la fois des entreprises et des projets open source choisir Electron comme base pour leurs applications. Juste au cours de l'année écoulée, Electron a été téléchargé plus de 1,2 million de fois. Faites une visite de quelques des incroyables applications Electron et ajoutez vos propres applications si elles ne sont pas déjà là.

Electron API Demos​

Along with the 1.0 release, we're releasing a new app to help you explore the Electron APIs and learn more about how to make your Electron app feel native. L'application Electron API Demos contient des extraits de code pour vous aider à démarrer votre application et des conseils sur l'utilisation efficace des API Electron.

Devtron​

We've also added a new extension to help you debug your Electron apps. Devtron est une extension open-source pour les outils de développement Chrome conçue pour vous aider à inspecter, débogage, et dépannage de votre application Electron.

Fonctionnalités​

• Require graph that helps you visualize your app's internal and external library dependencies in both the main and renderer processes
• IPC monitor that tracks and displays the messages sent and received between the processes in your app
• Event inspector that shows you the events and listeners that are registered in your app on the core Electron APIs such as the window, app, and processes
• App Linter that checks your apps for common mistakes and missing functionality

Spectron​

Enfin, nous publions une nouvelle version de Spectron, le framework de test d'intégration pour les applications Electron.

Spectron 3.0 has comprehensive support for the entire Electron API allowing you to more quickly write tests that verify your application's behavior in various scenarios and environments. Spectron est basé sur ChromeDriver et WebDriverIO donc il a également des API complètes pour la navigation de page, utilisateur entrée, et l'exécution JavaScript.

Communauté​

Electron 1.0 is the result of a community effort by hundreds of developers. Outside of the core framework, there have been hundreds of libraries and tools released to make building, packaging, and deploying Electron apps easier.

Il y a maintenant une nouvelle page communauté qui répertorie de nombreux outils Electron, applications, bibliothèques et frameworks en cours de développement. Vous pouvez également consulter les organisations Electron et Electron Userland pour voir certains de ces projets fantastiques.

New to Electron? Regardez la vidéo d'intro d'Electron 1.0 :

Electron 0.37 was recently released and included a major upgrade from Chrome 47 to Chrome 49 and also several new core APIs. This latest release brings in all the new features shipped in Chrome 48 and Chrome 49. This includes CSS custom properties, increased ES6 support, KeyboardEvent improvements, Promise improvements, and many other new features now available in your Electron app.

Quoi de neuf​

Propriétés personnalisées CSS​

Si vous avez utilisé des langages prétraités comme Sass et Less, vous êtes probablement familier avec les variables __, qui vous permettent de définir des valeurs réutilisables pour des choses comme les modèles de couleurs et les mises en page. Variables help keep your stylesheets DRY and more maintainable.

CSS custom properties are similar to preprocessed variables in that they are reusable, but they also have a unique quality that makes them even more powerful and flexible: they can be manipulated with JavaScript. Cette fonctionnalité subtile mais puissante permet des changements dynamiques aux interfaces visuelles tout en profitant de l'accélération matérielle du CSS, et réduit la duplication de code entre votre code frontend et vos feuilles de style.

For more info on CSS custom properties, see the MDN article and the Google Chrome demo.

Variables CSS en action​

Voyons un exemple de variable simple qui peut être ajusté en direct dans votre application.

:root {
  --awesome-color: #a5ecfa;
}

body {
  background-color: var(--awesome-color);
}

La valeur de la variable peut être récupérée et modifiée directement en JavaScript :

// Get the variable value ' #A5ECFA'
let color = window
  .getComputedStyle(document.body)
  .getPropertyValue('--awesome-color');

// Set the variable value to 'orange'
document.body.style.setProperty('--awesome-color', 'orange');

Les valeurs de la variable peuvent également être modifiées à partir de la section Styles des outils de développement pour un feedback rapide et des ajustements :

Propriété KeyboardEvent.code​

Chrome 48 added the new code property available on KeyboardEvent events that will be the physical key pressed independent of the operating system keyboard layout.

This should make implementing custom keyboard shortcuts in your Electron app more accurate and consistent across machines and configurations.

window.addEventListener('keydown', function (event) {
  console.log(`${event.code} was pressed.`);
});

Consultez cet exemple pour le voir en action.

Promise Rejection Events​

Chrome 49 added two new window events that allow you to be notified when an rejected Promise goes unhandled.

window.addEventListener('unhandledrejection', function (event) {
  console.log('A rejected promise was unhandled', event.promise, event.reason);
});

window.addEventListener('rejectionhandled', function (event) {
  console.log('A rejected promise was handled', event.promise, event.reason);
});

Consultez cet exemple pour le voir en action.

Mises à jour ES2015 en V8​

La version de V8 maintenant dans Electron incorpore 91 % de ES2015. Voici quelques ajouts intéressants que vous pouvez utiliser sans options ni pré-compilateurs :

Paramètres par défaut​

function multiply(x, y = 1) {
  return x * y;
}

multiply(5); // 5

Affectation par décomposition​

Chrome 49 added destructuring assignment to make assigning variables and function parameters much easier.

This makes Electron requires cleaner and more compact to assign now:

Browser Process Requires​

const { app, BrowserWindow, Menu } = require('electron');

Renderer Process Requires​

const { dialog, Tray } = require('electron').remote;

Autres exemples​

// Destructuring an array and skipping the second element
const [first, , last] = findAll();

// Destructuring function parameters
function whois({ displayName: displayName, fullName: { firstName: name } }) {
  console.log(`${displayName} is ${name}`);
}

let user = {
  displayName: 'jdoe',
  fullName: {
    firstName: 'John',
    lastName: 'Doe',
  },
};
whois(user); // "jdoe is John"

// Destructuring an object
let { name, avatar } = getUser();

Nouvelles API Electron​

A few of the new Electron APIs are below, you can see each new API in the release notes for Electron releases.

show and hide events on BrowserWindow​

These events are emitted when the window is either shown or hidden.

const { BrowserWindow } = require('electron');

let window = new BrowserWindow({ width: 500, height: 500 });
window.on('show', function () {
  console.log('Window was shown');
});
window.on('hide', function () {
  console.log('Window was hidden');
});

platform-theme-changed on app for OS X​

This event is emitted when the system’s Dark Mode theme is toggled.

const { app } = require('electron');

app.on('platform-theme-changed', function () {
  console.log(`Platform theme changed. In dark mode? ${app.isDarkMode()}`);
});

app.isDarkMode() pour OS X​

Cette méthode retourne true si le système est en Mode Sombre, ou false autrement.

scroll-touch-begin and scroll-touch-end events to BrowserWindow for OS X​

These events are emitted when the scroll wheel event phase has begun or has ended.

const { BrowserWindow } = require('electron');

let window = new BrowserWindow({ width: 500, height: 500 });
window.on('scroll-touch-begin', function () {
  console.log('Scroll touch started');
});
window.on('scroll-touch-end', function () {
  console.log('Scroll touch ended');
});

Since the beginning of Electron, starting way back when it used to be called Atom-Shell, we have been experimenting with providing a nice cross-platform JavaScript API for Chromium's content module and native GUI components. The APIs started very organically, and over time we have made several changes to improve the initial designs.

Now with Electron gearing up for a 1.0 release, we'd like to take the opportunity for change by addressing the last niggling API details. The changes described below are included in 0.35.x, with the old APIs reporting deprecation warnings so you can get up to date for the future 1.0 release. An Electron 1.0 won't be out for a few months so you have some time before these changes become breaking.

Deprecation warnings​

Par défaut, des avertissements s'afficheront si vous utilisez des API obsolètes. To turn them off you can set process.noDeprecation to true. To track the sources of deprecated API usages, you can set process.throwDeprecation to true to throw exceptions instead of printing warnings, or set process.traceDeprecation to true to print the traces of the deprecations.

New way of using built-in modules​

Les modules intégrés sont maintenant regroupés en un seul module, au lieu d'être séparés en modules indépendants, pour que vous puissiez les utiliser sans conflits avec d'autres modules :

var app = require('electron').app;
var BrowserWindow = require('electron').BrowserWindow;

The old way of require('app') is still supported for backward compatibility, but you can also turn if off:

require('electron').hideInternalModules();
require('app'); // throws error.

An easier way to use the remote module​

Because of the way using built-in modules has changed, we have made it easier to use main-process-side modules in renderer process. You can now just access remote's attributes to use them:

// New way.
var app = require('electron').remote.app;
var BrowserWindow = require('electron').remote.BrowserWindow;

Instead of using a long require chain:

// Old way.
var app = require('electron').remote.require('app');
var BrowserWindow = require('electron').remote.require('BrowserWindow');

Splitting the ipc module​

The ipc module existed on both the main process and renderer process and the API was different on each side, which is quite confusing for new users. We have renamed the module to ipcMain in the main process, and ipcRenderer in the renderer process to avoid confusion:

// Dans le processus principal .
var ipcMain = require('electron').ipcMain;

// In renderer process.
var ipcRenderer = require('electron').ipcRenderer;

And for the ipcRenderer module, an extra event object has been added when receiving messages, to match how messages are handled in ipcMain modules:

ipcRenderer.on('message', function (event) {
  console.log(event);
});

Standardizing BrowserWindow options​

The BrowserWindow options had different styles based on the options of other APIs, and were a bit hard to use in JavaScript because of the - in the names. They are now standardized to the traditional JavaScript names:

new BrowserWindow({ minWidth: 800, minHeight: 600 });

Following DOM's conventions for API names​

The API names in Electron used to prefer camelCase for all API names, like Url to URL, but the DOM has its own conventions, and they prefer URL to Url, while using Id instead of ID. We have done the following API renames to match the DOM's styles:

• Url is renamed to URL
• Csp is renamed to CSP

You will notice lots of deprecations when using Electron v0.35.0 for your app because of these changes. An easy way to fix them is to replace all instances of Url with URL.

Changes to Tray's event names​

The style of Tray event names was a bit different from other modules so a rename has been done to make it match the others.

• clicked is renamed to click
• double-clicked is renamed to double-click
• right-clicked is renamed to right-click