Electron 40 Upgrade Planning — when and how should I migrate?
Choose whether to move from Electron 38 to Electron 39, 40, or 41 based on the current support window, Chromium and Node jumps, and the amount of migration surface you want to absorb now.
Blockers
- Lock-in via engine/chromium-142.0.7444.52
- Lock-in via engine/v8-14.2
- Lock-in via engine/chromium-144.0.7559.60
- Lock-in via engine/chromium-146.0.7680.65
- breaking_change_in: format/dsym.zip → package/electron-40
- Lock-in via format/dsym.tar.xz
- breaking_change_in: capability/pdf-separate-webcontents → package/electron-41
- breaking_change_in: protocol/cookie-changed-event-cause → package/electron-41
Who this is for
- small-team
- enterprise
Candidates
Move to Electron 39 first as a supported bridge
As of 2026-03-31, Electron's official support policy covers only the latest three stable major versions, and Electron 38 reached end of life on 2026-03-10. Electron 39 is still within support until 2026-05-05 according to the official release schedule. Electron 39.0.0 shipped on 2025-10-28 with Chromium 142.0.7444.52, Node 22.20.0, and V8 14.2. Its release notes also added an `abi_version` file to the npm package, which is useful when you are checking native-module packaging and rebuild flows.
When to choose
Use this when you must leave Electron 38 immediately but want the smallest runtime step before taking the Node 24 jump in Electron 40 and 41. It is the lowest-disruption supported bridge, but only for teams that can accept another upgrade very soon.
Tradeoffs
Smallest immediate platform jump from Electron 38 and still officially supported, but the support runway is short because Electron 39 reaches end of life on 2026-05-05.
Cautions
Do not treat Electron 39 as a destination release. If you ship native modules, use the bridge period to verify rebuilds and packaging before a later move to a Node 24-based Electron line.
Upgrade directly to Electron 40
Electron 40.0.0 was released on 2026-01-13 and is supported until 2026-06-30. It upgrades Chromium from 142.0.7444.52 to 144.0.7559.60 and Node.js from 22.20.0 to 24.11.1. Electron 40 also deprecates direct renderer-process access to the `clipboard` API and changes macOS debug symbol packaging from `dsym.zip` to `dsym.tar.xz`. As of 2026-03-31, this is the clean middle option between a short-lived Electron 39 bridge and the newest Electron 41 line.
When to choose
Use this when you want to get onto a current supported line now and you are ready to absorb the Node 24 runtime change. It is the pragmatic default if Electron 38 is already out of support and you do not need the absolute latest Electron 41 features.
Tradeoffs
Longer runway than Electron 39 and less churn than jumping straight to Electron 41, but it still brings the major Node 24 jump and the related validation work that comes with a new runtime baseline.
Cautions
If your crash tooling or symbol pipeline expects `dsym.zip`, update it for `dsym.tar.xz`. If renderer code still uses `clipboard` directly, move that access behind preload and `contextBridge`.
Jump straight to Electron 41 and stay near head
Electron 41 was released on 2026-03-10 and is supported until 2026-08-25, giving the longest remaining support window among current stable lines as of 2026-03-31. It ships Chromium 146.0.7680.65 and Node 24.14.0, and the release post recommends installing 41.0.2 or later when upgrading to Electron 41. Notable additions include ASAR Integrity digest support for macOS, improved Wayland behavior, and MSIX auto-updating support. Breaking changes include PDFs no longer creating a separate `WebContents` and a changed cookie cause value in the `cookie` `changed` event.
When to choose
Use this when you already have strong CI, packaging, and regression coverage and you prefer to stay close to current Electron releases. It is the best fit for teams that want the longest current support runway and do not want to pay for a 39-to-40 or 40-to-41 follow-up hop.
Tradeoffs
Best remaining support runway and newest platform features, but it maximizes upgrade scope from Electron 38 because you absorb both the 40-era runtime jump and 41-specific behavior changes.
Cautions
If your app inspects PDFs via separate guest `WebContents`, rework that logic to use the frame tree. If Linux behavior under Wayland matters, retest frameless windows and decoration assumptions.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Electron 40 Upgrade Planning — when and how should I migrate?"