Starting December 1, the Electron project will enter a quiet period before picking back up at full capacity in January 2026. For full details, see the Policies section below.

Since 2020, December has been a time for project maintainers to take a breather from regular maintenance duties in order to take a break or focus on heads-down work. This break helps us rest up and come back energized for the year to come.

That said, a month-long pause like this one is only achievable when an open-source project is in a healthy state—we’d like to thank all maintainers and external contributors for all of their continued efforts to keep the project moving. ❤️

Electron 39.0.0 has been released! It includes upgrades to Chromium 142.0.7444.52, V8 14.2, and Node 22.20.0.

The Electron team is excited to announce the release of Electron 39.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

If you have any feedback, please share it with us on Bluesky or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

ASAR Integrity graduates to stable​

A long-standing "experimental" feature -- ASAR integrity -- is now stable in Electron 39. When you enable this feature, it validates your packaged app.asar at runtime against a build-time hash to detect any tampering. If no hash is present or if there is a mismatch in the hashes, the app will forcefully terminate.

See the ASAR integrity documentation for full information on how on the feature works, on how to use it in your application, and how to use it in Electron Forge and Electron Packager.

In related news, Electron Packager v19 now enables ASAR by default. #1841

Electron 38.0.0 has been released! It includes upgrades to Chromium 140.0.7339.41, V8 14.0, and Node 22.16.0.

The Electron team is excited to announce the release of Electron 38.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

If you have any feedback, please share it with us on Bluesky or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Electron 37.0.0 has been released! It includes upgrades to Chromium 138, V8 13.8, and Node 22.16.0.

The Electron team is excited to announce the release of Electron 37.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

If you have any feedback, please share it with us on Bluesky or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Google Summer of Code Begins​

Our two Google Summer of Code contributors have started the program's coding period!

• @nilayarya is crafting a new Save/Restore Window State API in Electron core. The new APIs will provide a built-in, standardized way to handle window state persistence. See Nilay's in-progress RFC at electron/rfcs#16.
• @hitarth-gg is hard at work modernizing the long-dormant Devtron extension using Chrome Manifest V3 APIs. This project will provide tooling for developers to debug IPC communication, track event listeners, and visualize module dependencies in their Electron applications.

It has been an exciting couple of weeks for our GSOC participants, so stay tuned for more updates!

Notable Changes​

Smooth Corners: Native CSS Squircles​

Electron 37 introduces the custom -electron-corner-smoothing CSS property, which allows apps to create smoother rounded corners to match Apple's macOS design language. This feature originally landed in Electron 36, but we felt like it deserved a brighter spotlight.

Example with 100% Corner Smoothing

Code	Result
.box { width: 128px; height: 128px; border-radius: 24px; -electron-corner-smoothing: 100%; }

Unlike the standard border-radius property, which carves quarter-circle corners out of a rectangle, -electron-corner-smoothing smoothly transitions the curve into a squircle shape with a continuous perimeter.

You can adjust the smoothness using values from 0% to 100%, or use the system-ui value to match the operating system's style (60% on macOS and 0% otherwise). This design enhancement can be applied on borders, outlines, and shadows, giving your app a subtle layer of polish.

Electron 36.0.0 has been released! It includes upgrades to Chromium 136, V8 13.6, and Node 22.14.0.

The Electron team is excited to announce the release of Electron 36.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

If you have any feedback, please share it with us on Bluesky or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

Writing Tools Support​

In Electron 36, you can enable macOS system-level features like Writing Tools (spelling and grammar), Autofill, and Services menu items in your context menus. To do so, pass a WebFrameMain instance into the frame parameter for menu.popup().

import { BrowserWindow, Menu, WebFrameMain } from 'electron';

const currentWindow = BrowserWindow.getFocusedWindow();
const focusedFrame = currentWindow.webContents.focusedFrame;
const menu = Menu.buildFromTemplate([{ label: 'Copy', role: 'copy' }]);

menu.popup({
  window: currentWindow,
  frame: focusedFrame,
});

Electron 35.0.0 has been released! It includes upgrades to Chromium 134.0.6998.44, V8 13.5, and Node 22.14.0.

The Electron team is excited to announce the release of Electron 35.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

If you have any feedback, please share it with us on Bluesky or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

Service Worker Preload Scripts for Improved Extensions Support​

Originally proposed in RFC #8 by @samuelmaddock, Electron 35 adds the ability to attach a preload script to Service Workers. With Chrome's Manifest V3 Extensions routing a lot of work through extension service workers, this feature fills in a gap in Electron's support for modern Chrome extensions.

When registering a preload script programmatically at the Session level, you can now specifically apply it to Service Worker contexts with the ses.registerPreloadScript(script) API.

// Add our preload realm script to the session.
session.defaultSession.registerPreloadScript({
  // Our script should only run in service worker preload realms.
  type: 'service-worker',
  // The absolute path to the script.
  script: path.join(__dirname, 'extension-sw-preload.js'),
});

Furthermore, IPC is now available between Service Workers and their attached preload scripts via the ServiceWorkerMain.ipc class. The preload script will still use the ipcRenderer module to communicate with its Service Worker. See the original RFC for more details.

This feature was preceded by many other changes that laid the groundwork for it:

• #45329 redesigned the Session module's preload APIs to support registering and unregistering individual preload scripts.
• #45229 added the experimental contextBridge.executeInMainWorld(executionScript) script to evaluate JavaScript in the main world over the context bridge.
• #45341 added the ServiceWorkerMain class to interact with Service Workers in the main process.

Electron has once again been accepted as a mentoring organization for Google Summer of Code (GSoC) 2025! Google Summer of Code is a global program focused on bringing new contributors into open source software development.

For more details about the program, visit Google’s Summer of Code homepage.

About us​

Electron is a JavaScript framework for building cross-platform desktop applications using web technologies. The core Electron framework is a compiled binary executable built with Chromium and Node.js, and is mostly written in C++.

Outside of the Electron core repository, we also maintain several projects to support the Electron ecosystem, including:

• Tools for end-user distribution (e.g. Electron Forge and update.electronjs.org).
• Learning materials for Electron developers (e.g. electronjs.org and Electron Fiddle).
• Internal tools to enhance developer productivity (e.g. Electron Build Tools and Sheriff).

As a GSoC contributor, you will have the opportunity to collaborate with some of Electron’s core contributors on one of many projects under the github.com/electron umbrella.

Before applying​

If you aren’t very familiar with Electron, we would recommend you start by reading the documentation and trying out some of the examples in Electron Fiddle.

To learn more about distributing Electron apps, try creating a sample application with Electron Forge:

npm init electron-app@latest my-app

After familiarizing yourself with the code a bit, come join the conversation on the Electron Discord server.

Project contributions​

We encourage you to take a look at any repositories that are relevant to the project ideas you are interested in. One way of doing your research is to make contributions by reporting bugs, triaging existing issues, or submitting pull requests. Doing so is an effective way of getting hands-on practice with our codebases, but is not mandatory for proposal submissions. A well-crafted proposal should be able to demonstrate your understanding of the code without needing to refer to past contributions.

Here are a few tips if you are looking to contribute to Electron before submitting your proposal:

1. Please provide descriptive issue or PR descriptions when submitting contributions. Regardless of the code itself, putting effort into the written part of a contribution shows us that you can be an effective communicator in a collaborative environment.
2. PRs are always welcome for open issues. You do not need to comment on an issue asking a maintainer if you can be assigned to it. Note that we still encourage you to discuss potential solutions on an issue if you need to refine an idea for a solution, but comments strictly asking if you can work on something are redundant and add noise to the issue tracker.
3. Low-effort project contributions (e.g. invalid issue reports, trivial wording changes in a repo README, or minor stylistic changes to front-end code) will negatively impact your final proposal, as they take up limited maintainer time and do not provide any net benefit to the Electron project.
4. While AI coding assistants can be an effective tool for debugging and understanding new concepts, we highly discourage contributions that are copy/pasted directly from AI-generated output. These often turn out to be of low quality, and it's often more effort for maintainers to clean up code generated from an LLM than for us to just reject a PR altogether.

Crafting your proposal​

Interested in collaborating with Electron? First, check out the seven project idea drafts we have prepared. All listed ideas are open for proposals.

If you have a unique idea not on the list, we are open to considering it, but ensure your proposal is detailed and thoroughly outlined. When in doubt, we recommend sticking with our listed ideas.

Your application should include:

• A detailed proposal outlining what you plan to achieve over the summer.
• Your background as a developer. If you have a resume, please include a copy. Otherwise, tell us about your past technical experience.
  • Lack of experience in certain areas won’t disqualify you, but it will help our mentors work out a plan to best support you and make sure your summer project is successful.

A detailed guide of what to submit as part of your Electron application is here. Submit proposals directly to the Google Summer of Code portal. Proposals emailed to the Electron team will not be considered as final submissions.

For more guidance on your proposal, we recommend you follow the official Google Summer of Code proposal writing advice here.

Applications open on March 24th, 2025 and close on April 8th, 2025.

Questions?​

If you have questions we didn’t address in this blog post or inquiries about your proposal draft, please send us an email at summer-of-code@electronjs.org or check the GSoC FAQ. Please read our contributor guidance before emailing.

Resources​

• Electron Google Summer of Code 2025 Ideas List
• Electron Google Summer of Code 2025 Contributor Guidance
• Google Summer of Code Student/Contributor Guide

Electron 34.0.0 has been released! It includes upgrades to Chromium 132.0.6834.83, V8 13.2, and Node 20.18.1.

The Electron team is excited to announce the release of Electron 34.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

If you have any feedback, please share it with us on Bluesky or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

HTTP Compression Shared Dictionary Management APIs​

HTTP compression allows data to be compressed by a web server before being received by the browser. Modern versions of Chromium support Brotli and Zstandard, which are newer compression algorithms that perform better for text files than older schemes such as gzip.

Custom shared dictionaries further improve the efficiency of Brotli and Zstandard compression. See the Chrome for Developers blog on shared dictionaries for more information.

@felixrieseberg added the following APIs in #44950 to manage shared dictionaries at the Session level:

• session.getSharedDictionaryUsageInfo()
• session.getSharedDictionaryInfo(options)
• session.clearSharedDictionaryCache()
• session.clearSharedDictionaryCacheForIsolationKey(options)

Unresponsive Renderer JavaScript Call Stacks​

Electron's unresponsive event occurs whenever a renderer process hangs for an excessive period of time. The new WebFrameMain.collectJavaScriptCallStack() API added by @samuelmaddock in #44204 allows you to collect the JavaScript call stack from the associated WebFrameMain object (webContnets.mainFrame).

This API can be useful to determine why the frame is unresponsive in cases where there's long-running JavaScript events causing the process to hang. For more information, see the proposed web standard Crash Reporting API.

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

app.commandLine.appendSwitch(
  'enable-features',
  'DocumentPolicyIncludeJSCallStacksInCrashReports',
);

app.on('web-contents-created', (_, webContents) => {
  webContents.on('unresponsive', async () => {
    // Interrupt execution and collect call stack from unresponsive renderer
    const callStack = await webContents.mainFrame.collectJavaScriptCallStack();
    console.log('Renderer unresponsive\n', callStack);
  });
});

In early 2025, Electron’s npm ecosystem repos (under the @electron/ and @electron-forge/ namespaces) will move to Node.js 22 as the minimum supported version.

What does this mean?​

In the past, packages in Electron’s npm ecosystem (Forge, Packager, etc) have supported Node versions for as long as possible, even after a version has reached its End-Of-Life (EOL) date. This is done to make sure we don’t fragment the ecosystem—we understand that many projects depend on older versions of Node, and we don’t want to risk stranding those projects unless there was a pressing reason to upgrade.

Over time, using Node.js 14 as our minimum version has become increasingly difficult for a few reasons:

• Lack of official Node.js 14 macOS ARM64 builds requires us to maintain CI infrastructure workarounds to provide full test coverage.
• engines requirements for upstream package dependencies have moved forward, making it increasingly difficult to resolve supply chain security issues with dependency bumps.

Additionally, newer versions of Node.js have included many improvements that we would like to leverage, such as runtime-native common utilities (e.g. fs.glob and util.parseArgs) and entire new batteries-included modules (e.g. node:test, node:sqlite).

Why upgrade now?​

In July 2024, Electron’s Ecosystem Working Group decided to upgrade all packages to the earliest Node version where require()of synchronous ESM graphs will be supported (see nodejs/node#51977 and nodejs/node#53500) at a future point after that version reaches its LTS date.

We’ve decided to set that update time to January/February 2025. After this upgrade occurs, Node 22 will be the minimum supported version in existing ecosystem packages.

What action do I need to take?​

We’ll strive to maintain compatibility as much as possible. However, to ensure the best support, we encourage you to upgrade your apps to Node 22 or higher.

Note that the Node version running in your project is unrelated to the Node version embedded into your current version of Electron.

What's next​

Please feel free to write to us at info@electronjs.org if you have any questions or concerns. You can also find community support in our official Electron Discord.

The Electron project will pause for the month of December 2024, then return to full speed in January 2025.

via GIPHY

What will be the same in December​

1. Zero-day and other major security-related releases will be published as necessary. Security incidents should be reported via SECURITY.md.
2. Code of Conduct reports and moderation will continue.

What will be different in December​

1. 2024's last stable branch releases for the year, which include Electron 31, 32, and 33, will occur the week of December 1st. There will be no additional planned releases in December.
2. No Nightly and Alpha releases for the last two weeks of December.
3. With few exceptions, no pull request reviews or merges.
4. No issue tracker updates on any repositories.
5. No Discord debugging help from maintainers.
6. No social media content updates.

See you all in 2025!