2023 年の Electron の開発者エコシステムの改善と変化を振り返ります。

ここ数か月で、Electron アプリの開発者エクスペリエンスを向上させるために、Electron エコシステム全体でいくつかの変更を行ってきました！ Electron HQ からの最新の追加事項の簡単な概要を以下に示します。

Electron Forge 7 以降​

Electron Forge 7 — Electron アプリケーションのパッケージングと配布のためのオールインワンツールの最新のメジャーバージョン — が利用可能になりました。

Forge 6 は v5 からの完全な書き直しでしたが、v7 はスコープが小さいものの、いくつかの破壊的な変更が含まれています。今後、破壊的な変更が必要になった場合は、Forge のメジャーバージョンを引き続き公開します。

詳細については、GitHub の Forge v7.0.0 の変更ログをご覧ください。

破壊的な変更​

• macOS のノータリー処理に notarytool に切り替えました： 2023 年 11 月 1 日の時点で、Apple は macOS のノータリー処理に従来の altool を廃止しました。このリリースでは、Electron Forge から完全に削除されています。
• 最小 Node.js を v16.4.0 に引き上げました： このリリースでは、必要な最小 Node.js バージョンを 16.4.0 に設定しました。
• electron-prebuilt および electron-prebuilt-compile のサポートを終了しました: electron-prebuilt は、Electron の npm モジュールの元の名前でしたが、v1.3.1 で electron に置き換えられました。electron-prebuilt-compile は、強化された DX 機能が付属したそのバイナリの代替手段でしたが、最終的にプロジェクトとして放棄されました。

ハイライト​

• Google Cloud Storage パブリッシャー: 静的自動更新をより良くサポートするための取り組みの一環として、Electron Forge は Google Cloud Storage に直接公開することをサポートするようになりました！
• ESM forge.config.js のサポート: Electron Forge が ESM forge.config.js ファイルをサポートするようになりました。(追伸 Electron 28 での ESM エントリーポイントのサポートにご期待ください。)
• Makers が並列実行されるようになりました: Electron Forge 6 では、Makers は ✨レガシー✨の理由で順番に実行されていました。それ以来、Make ステップの並列化を副作用なしでテストしてきたため、同じプラットフォームに対して複数のターゲットをビルドするときにスピードアップが見られるはずです！

より良い静的ストレージ自動更新​

Squirrel.Windows と Squirrel.Mac は、Electron の組み込みの autoUpdater モジュールをサポートするプラットフォーム固有のアップデーターテクノロジーです。どちらのプロジェクトも、次の 2 つの方法による自動更新をサポートしています。

• Squirrel 互換の更新サーバー
• 静的ストレージプロバイダー（AWS、Google Cloud Platform、Microsoft Azure など）でホストされているマニフェスト URL

更新サーバーの方法は、これまで Electron アプリで推奨されるアプローチでしたが（更新ロジックの追加のカスタマイズを提供します）、主な欠点は、クローズドソースの場合は、アプリが独自のサーバーインスタンスを維持する必要があることです。

一方、静的ストレージの方法は常に可能でしたが、Electron 内では文書化されておらず、Electron ツーリングパッケージ全体で十分にサポートされていませんでした。

@MarshallOfSound による優れた作業により、サーバーレス自動アプリ更新の更新ストーリーが大幅に合理化されました

• Electron Forge の Zip および Squirrel.Windows メーカーは、autoUpdater 互換の更新マニフェストを出力するように構成できるようになりました。
• 新しいメジャーバージョンの update-electron-app (v2.0.0) は、update.electronjs.org サーバーの代替として、これらの生成されたマニフェストを読み取ることができるようになりました。

メーカーとパブリッシャーがクラウドファイルストレージに更新マニフェストをアップロードするように構成されると、わずか数行の構成で自動更新を有効にできます

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

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

@electron/ の拡張されたユニバース​

Electron が最初に開始されたとき、コミュニティは Electron アプリの開発、パッケージング、および配布のエクスペリエンスを向上させるために多くのパッケージを公開しました。時間の経過とともに、これらのパッケージの多くが Electron の GitHub 組織に組み込まれ、コアチームがメンテナンスの負担を引き受けることになりました。

2022年、私たちはこれらのすべてのファーストパーティツールをnpmの@electron/名前空間で統合し始めました。この変更により、以前はelectron-fooだったパッケージは、npmでは@electron/fooになり、以前はelectron/electron-fooという名前だったリポジトリは、GitHubではelectron/fooになりました。これらの変更は、ファーストパーティプロジェクトとユーザーランドプロジェクトを明確に区別するのに役立ちます。これには、以下のような多くの一般的に使用されるパッケージが含まれます。

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

今後、リリースするすべてのファーストパーティパッケージも@electron/名前空間に含まれるようになります。ただし、これには2つの例外があります。

• Electronコアは、引き続きelectronパッケージで公開されます。
• Electron Forgeは、そのすべてのモノレポパッケージを@electron-forge/名前空間で公開し続けます。

@electron/windows-sign のご紹介​

2023年6月1日から、業界標準でWindowsコード署名証明書のキーをFIPS準拠のハードウェアに保存することが義務付けられました。

実際には、多くのElectronツールが証明書ファイルとパスワードを構成パラメータとして受け取り、そこからハードコードされたロジックを使用して署名しようとするため、CI環境でビルドと署名を行うアプリにとってコード署名が非常に難しくなりました。

この状況はElectron開発者にとって共通の悩みの種でした。そのため、私たちはmacOSで@electron/osx-signが行うのと同様に、Windowsコード署名をスタンドアロンのステップに分離するより良いソリューションに取り組んできました。

将来的には、このパッケージをElectron Forgeツールチェーンに完全に統合する予定ですが、現在は単独で存在しています。パッケージは現在、npm install --save-dev @electron/windows-sign でインストール可能で、プログラムまたはCLI経由で使用できます。

ぜひ試してみて、リポジトリのIssueトラッカーでフィードバックをお寄せください！

今後の予定​

来月には、毎年恒例の12月の静寂期間に入ります。その間、私たちは2024年にElectronの開発体験をさらに向上させる方法について検討します。

次に私たちが取り組むべきことについて、何かご意見はありますか？ぜひ教えてください！

Electronプロジェクトは2023年12月は一時停止し、2024年1月にフルスピードで再開します。

via GIPHY

12月に変わらないこと​

1. ゼロデイおよびその他の重大なセキュリティ関連のリリースは、必要に応じて公開されます。セキュリティインシデントは、SECURITY.md を通じて報告する必要があります。
2. 行動規範の報告とモデレーションは継続されます。

12月に変わること​

1. Electron 28.0.0 は12月5日にリリースされます。Electron 28の後、12月には新しいStableリリースはありません。
2. 12月最後の2週間は、NightlyおよびAlphaリリースはありません。
3. いくつかの例外を除き、プルリクエストのレビューやマージは行われません。
4. すべてのリポジトリでIssueトラッカーの更新はありません。
5. メンテナーからのDiscordでのデバッグサポートはありません。
6. ソーシャルメディアコンテンツの更新はありません。

今後の展望​

これは、静寂期間の実験を行って3年目になりますが、1ヶ月の休息と、その後通常のリリースケイデンスを維持することとのバランスをとることに、これまで大きな成功を収めています。したがって、これを今後のリリーススケジュールに定期的に組み込むことにしました。毎年、最後の安定版リリースにリマインダーを入れる予定です。

2024年にお会いしましょう！

Electron 27.0.0 がリリースされました！ Chromium 118.0.5993.32、V8 11.8、およびNode.js 18.17.1へのアップグレードが含まれています。

Electronチームは、Electron 27.0.0のリリースを発表できることを嬉しく思います！ npm install electron@latestでnpmからインストールするか、リリースウェブサイトからダウンロードできます。このリリースに関する詳細については、引き続きお読みください。

フィードバックがあれば、TwitterまたはMastodonで共有するか、コミュニティDiscordにご参加ください！バグや機能リクエストは、ElectronのIssueトラッカーで報告できます。

注目すべき変更点​

スタックの変更​

• Chromium 118.0.5993.32
  • Chrome 118の新機能
  • DevTools 118の新機能
• Node.js 18.17.1
  • Node 18.17.1のブログ記事
  • Node 18.17.0のブログ記事
• V8 11.8

破壊的な変更​

削除: macOS 10.13 / 10.14 のサポート​

macOS 10.13 (High Sierra) および macOS 10.14 (Mojave) は、Chromium ではサポートされなくなりました。

以前のバージョンのElectronはこれらのオペレーティングシステムで引き続き実行されますが、Electron v27.0.0以降を実行するにはmacOS 10.15（Catalina）以降が必要になります。

非推奨: ipcRenderer.sendTo()​

ipcRenderer.sendTo() APIは非推奨になりました。レンダラー間でMessageChannelを設定することで置き換える必要があります。

IpcRendererEventのsenderIdプロパティとsenderIsMainFrameプロパティも非推奨になりました。

削除: systemPreferences のカラースキームイベント​

次のsystemPreferencesイベントが削除されました。

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

代わりにnativeThemeモジュールの新しいupdatedイベントを使用してください。

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

// Replace with
nativeTheme.on('updated', () => {
  /* ... */
});

削除: webContents.getPrinters​

webContents.getPrintersメソッドは削除されました。代わりにwebContents.getPrintersAsyncを使用してください。

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

// Removed
console.log(w.webContents.getPrinters());
// Replace with
w.webContents.getPrintersAsync().then((printers) => {
  console.log(printers);
});

削除: systemPreferences.{get,set}AppLevelAppearance および systemPreferences.appLevelAppearance​

systemPreferences.getAppLevelAppearanceメソッドとsystemPreferences.setAppLevelAppearanceメソッド、およびsystemPreferences.appLevelAppearanceプロパティは削除されました。代わりにnativeThemeモジュールを使用してください。

// Removed
systemPreferences.getAppLevelAppearance();
// Replace with
nativeTheme.shouldUseDarkColors;

// Removed
systemPreferences.appLevelAppearance;
// Replace with
nativeTheme.shouldUseDarkColors;

// Removed
systemPreferences.setAppLevelAppearance('dark');
// Replace with
nativeTheme.themeSource = 'dark';

削除: systemPreferences.getColorのalternate-selected-control-text値​

systemPreferences.getColorのalternate-selected-control-text値は削除されました。代わりにselected-content-backgroundを使用してください。

// Removed
systemPreferences.getColor('alternate-selected-control-text');
// Replace with
systemPreferences.getColor('selected-content-background');

新機能​

• アプリのアクセシビリティ透過設定APIを追加 #39631
• chrome.scripting拡張APIのサポートを追加 #39675
• WaylandWindowDecorationsをデフォルトで有効化 #39644

24.x.y のサポート終了​

Electron 24.x.yは、プロジェクトのサポートポリシーに従って、サポート終了となりました。開発者およびアプリケーションは、Electronのより新しいバージョンにアップグレードすることをお勧めします。

22.x.y の拡張サポート終了​

今年初めに、Electronチームは、Windows 7/8/8.1に対するChromeの拡張サポートに合わせるため、Electron 22の計画されていたサポート終了日を2023年5月30日から2023年10月10日に延長しました（詳細については、さようなら、Windows 7/8/8.1を参照）。

Electron 22.x.yは、プロジェクトのサポートポリシーとこのサポート延長に従って、サポート終了となりました。これにより、サポートは最新の3つの安定版メジャーバージョンに戻り、Windows 7/8/8.1の公式サポートが終了します。

今後の予定​

短期的には、チームがChromium、Node、V8を含むElectronを構成する主要コンポーネントの開発に引き続き注力していくことが予想されます。

Electronの公開タイムラインはこちらで確認できます。

将来の変更に関する詳しい情報は、計画されている破壊的変更のページで確認できます。

CVE-2023-4863：WebPにおけるヒープバッファオーバーフローが公開されてから1週間以上が経過し、webp画像をレンダリングするソフトウェアの新しいリリースが相次いでいます。macOS、iOS、Chrome、Firefox、さまざまなLinuxディストリビューションがすべてアップデートを受けました。これは、Citizen Labによる調査の結果、「ワシントンDCを拠点とする市民社会組織」が使用するiPhoneが、iMessage内のゼロクリックエクスプロイトを使用して攻撃を受けていたことが判明したことを受けたものです。

Electronもすぐに行動を開始し、同日に新しいバージョンをリリースしました。アプリがユーザー提供のコンテンツをレンダリングする場合は、Electronのバージョンをアップデートする必要があります。v27.0.0-beta.2、v26.2.1、v25.8.1、v24.8.3、およびv22.3.24にはすべて、webp画像のレンダリングを担当するライブラリであるlibwebpの修正バージョンが含まれています。

「画像をレンダリングする」という無害なインタラクションが潜在的に危険な行為であることを誰もが新たに認識した今、Electronには、次の大きな攻撃（それが何であれ）の被害範囲を制限するプロセスサンドボックスが付属していることを改めてお知らせします。

サンドボックスはElectron v1から利用可能で、v20でデフォルトで有効になりましたが、多くのアプリ（特に古いアプリ）では、コードのどこかにsandbox: falseがあるか、明示的なsandbox設定がない場合にサンドボックスを同様に無効にするnodeIntegration: trueがある可能性があります。それは理解できます。長い間私たちと一緒にいた方は、おそらく、HTML/CSSを実行する同じコードにrequire("child_process")またはrequire("fs")を記述する力を楽しんだでしょう。

サンドボックスへの移行方法を説明する前に、まずサンドボックスが必要な理由について説明しましょう。

サンドボックスは、すべてのレンダラープロセスをハードケージで囲み、内部で何が起こっても、コードが制限された環境内で実行されるようにします。概念としてはChromiumよりもはるかに古く、すべての主要なオペレーティングシステムが機能として提供しています。ElectronとChromiumのサンドボックスは、これらのシステム機能の上に構築されています。ユーザーが生成したコンテンツを表示しない場合でも、レンダラーが侵害される可能性を検討する必要があります。サプライチェーン攻撃のような高度なシナリオや、ちょっとしたバグのような単純なシナリオでも、レンダラーが意図しない動作をする可能性があります。

サンドボックスを使用すると、そのシナリオの危険性が大幅に軽減されます。内部のプロセスは、CPUサイクルとメモリを自由に使用できます。それだけです。プロセスはディスクに書き込んだり、独自のウィンドウを表示したりすることはできません。今回のlibwepバグの場合、サンドボックスは攻撃者がマルウェアをインストールまたは実行できないようにします。実際、従業員のiPhoneに対する最初のPegasus攻撃の場合、攻撃は、通常サンドボックス化されているiMessageの境界から抜け出して電話にアクセスするために、サンドボックス化されていない画像プロセスを特に標的にしました。この例のようなCVEが発表されたら、Electronアプリを安全なバージョンにアップグレードする必要があります。しかしその間、攻撃者が与える可能性のある損害の量は大幅に制限されます。

バニラElectronアプリケーションをsandbox: falseからsandbox: trueに移行するのは大変な作業です。なぜなら、私は個人的にElectronセキュリティガイドラインの最初のドラフトを作成したにもかかわらず、自分のアプリを1つも移行できていないからです。今週末にそれが変わったので、皆さんにも変更することをお勧めします。

対処する必要があることは2つあります。

1. preloadスクリプトまたは実際のWebContentsのいずれかでNode.jsコードを使用している場合は、そのすべてのNode.jsインタラクションをメインプロセス（または、必要に応じてユーティリティプロセス）に移動する必要があります。レンダラーが非常に強力になったため、コードの大部分は実際にはリファクタリングを必要としない可能性が高くなります。

   プロセス間通信に関するドキュメントを参照してください。私の場合は、多くのコードを移動してipcRenderer.invoke()とipcMain.handle()でラップしましたが、プロセスは簡単で、すぐに完了しました。ここでAPIに少し注意してください。executeCodeAsRoot(code)という名前のAPIを作成すると、サンドボックスはユーザーをあまり保護しません。

2. サンドボックスを有効にすると、preloadスクリプトでNode.js統合が無効になるため、require("../my-script")を使用できなくなります。つまり、preloadスクリプトは単一のファイルである必要があります。

   これを行うには複数の方法があります。Webpack、esbuild、parcel、およびrollupはすべて、ジョブを完了します。私はElectron Forgeの優れたWebpackプラグインを使用しました。同じように人気のあるelectron-builderのユーザーはelectron-webpackを使用できます。

全体として、プロセス全体には約4日間かかりました。そして、Webpackの巨大なパワーをどのように使いこなすか頭を悩ませる時間も含まれています。この機会にコードをさまざまな方法でリファクタリングすることにしたからです。

Electron 26.0.0がリリースされました！ Chromium 116.0.5845.62、V8 11.2、およびNode.js 18.16.1へのアップグレードが含まれています。詳細については、以下をお読みください！

Electronチームは、Electron 26.0.0のリリースを発表できることを嬉しく思います！ npmを使用してnpm install electron@latestでインストールするか、リリースウェブサイトからダウンロードできます。このリリースに関する詳細については、読み続けてください。

フィードバックがある場合は、Twitterで共有するか、コミュニティのDiscordにご参加ください。バグや機能リクエストは、Electronのissue trackerで報告できます。

注目すべき変更点​

スタックの変更​

• Chromium 116.0.5845.62
  • Chrome 116の新機能
  • DevTools 116の新機能
• Node.js 18.16.1
  • Node 18.16.1のブログ記事
• V8 11.2

破壊的な変更​

非推奨：webContents.getPrinters​

webContents.getPrintersメソッドは非推奨になりました。代わりにwebContents.getPrintersAsyncを使用してください。

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

// Deprecated
console.log(w.webContents.getPrinters());
// Replace with
w.webContents.getPrintersAsync().then((printers) => {
  console.log(printers);
});

非推奨：systemPreferences.{get,set}AppLevelAppearanceおよびsystemPreferences.appLevelAppearance​

systemPreferences.getAppLevelAppearanceメソッドとsystemPreferences.setAppLevelAppearanceメソッド、およびsystemPreferences.appLevelAppearanceプロパティは非推奨になりました。代わりにnativeThemeモジュールを使用してください。

// Deprecated
systemPreferences.getAppLevelAppearance();
// Replace with
nativeTheme.shouldUseDarkColors;

// Deprecated
systemPreferences.appLevelAppearance;
// Replace with
nativeTheme.shouldUseDarkColors;

// Deprecated
systemPreferences.setAppLevelAppearance('dark');
// Replace with
nativeTheme.themeSource = 'dark';

非推奨：systemPreferences.getColorのalternate-selected-control-text値​

systemPreferences.getColorのalternate-selected-control-text値は非推奨になりました。代わりにselected-content-backgroundを使用してください。

// Deprecated
systemPreferences.getColor('alternate-selected-control-text');
// Replace with
systemPreferences.getColor('selected-content-background');

新機能​

• safeStorage.setUsePlainTextEncryption APIとsafeStorage.getSelectedStorageBackend APIを追加しました。#39107
• safeStorage.setUsePlainTextEncryption APIとsafeStorage.getSelectedStorageBackend APIを追加しました。#39155
• ipcRenderer.sendTo()を介して送信されたメッセージにsenderIsMainFrameを追加しました。#39206
• キーボードで開始されたメニューをフラグ付けするためのサポートを追加しました。#38954

23.x.yのサポート終了​

Electron 23.x.yは、プロジェクトのサポートポリシーに従って、サポート終了となりました。開発者とアプリケーションは、より新しいバージョンのElectronにアップグレードすることをお勧めします。

今後の予定​

短期的には、チームがChromium、Node、V8を含むElectronを構成する主要コンポーネントの開発に引き続き注力していくことが予想されます。

Electronの公開タイムラインはこちらで確認できます。

将来の変更に関する詳しい情報は、計画されている破壊的変更のページで確認できます。

Electron 25.0.0がリリースされました！ Chromium 114、V8 11.4、およびNode.js 18.15.0へのアップグレードが含まれています。詳細については、以下をお読みください！

Electronチームは、Electron 25.0.0のリリースを発表できることを嬉しく思います！ npmを使用してnpm install electron@latestでインストールするか、リリースウェブサイトからダウンロードできます。このリリースに関する詳細については、読み続けてください。

フィードバックがある場合は、Twitterで共有するか、コミュニティのDiscordにご参加ください。バグや機能リクエストは、Electronのissue trackerで報告できます。

注目すべき変更点​

ハイライト​

• Chromiumのネットワークスタックを使用して、Electronのnetモジュール内にnet.fetchを実装しました。これは、Node.jsのHTTPスタックを使用するNodeのfetch()とは異なります。#36733および#36606を参照してください。
• protocol.{register,intercept}{String,Buffer,Stream,Http,File}Protocolを置き換えて非推奨にするprotocol.handleを追加しました。#36674
• ChromiumおよびMicrosoftのWindows 7/8/8.1の非推奨計画に合わせて、Electron 22のサポートを拡張しました。詳細については、このブログ記事の最後をご覧ください。

スタックの変更​

• Chromium 114
  • Chrome 114の新機能
  • Chrome 113の新機能
  • DevTools 114の新機能
  • DevTools 113の新機能
• Node.js 18.15.0
  • Node 18.15.0のブログ記事
• V8 11.4

破壊的な変更​

非推奨：protocol.{register,intercept}{Buffer,String,Stream,File,Http}Protocol​

protocol.register*Protocolメソッドとprotocol.intercept*Protocolメソッドは、protocol.handleに置き換えられました。

新しいメソッドは、新しいプロトコルを登録するか、既存のプロトコルをインターセプトすることができ、応答は任意のタイプにすることができます。

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

// Replace with
protocol.handle('some-protocol', () => {
  return new Response(
    Buffer.from('<h5>Response</h5>'), // Could also be a string or ReadableStream.
    { headers: { 'content-type': 'text/html' } }
  );
});

// Deprecated in Electron 25
protocol.registerHttpProtocol('some-protocol', () => {
  callback({ url: 'https://electron.dokyumento.jp' });
});

// Replace with
protocol.handle('some-protocol', () => {
  return net.fetch('https://electron.dokyumento.jp');
});

// Deprecated in Electron 25
protocol.registerFileProtocol('some-protocol', () => {
  callback({ filePath: '/path/to/my/file' });
});

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

非推奨：BrowserWindow.setTrafficLightPosition(position)​

BrowserWindow.setTrafficLightPosition(position)は非推奨になりました。代わりに、システムデフォルトに位置をリセットするために{ x: 0, y: 0 }の代わりにnullを受け入れるBrowserWindow.setWindowButtonPosition(position)APIを使用する必要があります。

// Deprecated in Electron 25
win.setTrafficLightPosition({ x: 10, y: 10 });
win.setTrafficLightPosition({ x: 0, y: 0 });

// Replace with
win.setWindowButtonPosition({ x: 10, y: 10 });
win.setWindowButtonPosition(null);

非推奨：BrowserWindow.getTrafficLightPosition()​

BrowserWindow.getTrafficLightPosition()は非推奨になりました。カスタム位置がない場合に{ x: 0, y: 0 }の代わりにnullを返すBrowserWindow.getWindowButtonPosition()APIを代わりに使用する必要があります。

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

// Replace with
const ret = win.getWindowButtonPosition();
if (ret === null) {
  // No custom position.
}

新機能​

• net.fetch()を追加しました。#36733
  • net.fetchは、file: URLと、protocol.register*Protocolで登録されたカスタムプロトコルへのリクエストをサポートしています。#36606
• BrowserWindow.set/getWindowButtonPosition APIを追加しました。#37094
• protocol.{register,intercept}{String,Buffer,Stream,Http,File}Protocolを置き換えて非推奨にするprotocol.handleを追加しました。#36674
• webContentsおよび<webview>タグに、フレーム階層内のフレームがナビゲートを試みるたびに発生するwill-frame-navigateイベントを追加しました。#34418
• ナビゲーターイベントにイニシエーター情報を追加しました。この情報により、子によって開始されたナビゲーションとは対照的に、window.open と親フレームによるナビゲーションを区別することができます。#37085
• defaultSession オブジェクトを使用してホストを解決する net.resolveHost を追加しました。#38152
• app に新しい 'did-resign-active' イベントを追加しました。#38018
• webContents.print() にいくつかの標準ページサイズオプションを追加しました。#37159
• audio が WebFrameMain の場合、リモートオーディオ入力をローカル出力ストリームでエコーできるようにする enableLocalEcho フラグを、セッションハンドラー ses.setDisplayMediaRequestHandler() コールバックに追加しました。#37315
• powerMonitor に熱管理情報を追加しました。#38028
• session.fromPath() API に絶対パスを渡せるようにしました。#37604
• webContents で audio-state-changed イベントを公開しました。#37366

22.x.y の継続サポート​

さよなら、Windows 7/8/8.1 で述べられているように、Electron 22（Chromium 108）の計画されているサポート終了日は、2023年5月30日から2023年10月10日に延長されます。Electronチームは、このプログラムの一部であるセキュリティ修正を2023年10月10日までElectron 22にバックポートし続けます。10月のサポート日は、ChromiumとMicrosoftの両方の延長サポート日に従います。10月11日に、Electronチームは、Windows 7/8/8.1をサポートしなくなる最新の3つの安定したメジャーバージョンまでサポートを終了します。

今後の予定​

短期的には、チームがChromium、Node、V8を含むElectronを構成する主要コンポーネントの開発に引き続き注力していくことが予想されます。

Electronの公開タイムラインはこちらで確認できます。

将来の変更に関する詳しい情報は、計画されている破壊的変更のページで確認できます。

Electron 24.0.0 がリリースされました！ Chromium 112.0.5615.49、V8 11.2、および Node.js 18.14.0 へのアップグレードが含まれています。詳細については下記をお読みください！

Electronチームは、Electron 24.0.0のリリースを発表できることを嬉しく思います！ npm install electron@latest を使用して npm でインストールするか、リリースウェブサイトからダウンロードできます。このリリースに関する詳細については、以下をお読みください。

フィードバックがある場合は、Twitterで共有するか、コミュニティのDiscordにご参加ください。バグや機能リクエストは、Electronのissue trackerで報告できます。

注目すべき変更点​

スタックの変更​

• Chromium 112.0.5615.49
  • Chrome 112 の新機能
  • Chrome 111 の新機能
  • DevTools 112 の新機能
  • DevTools 111 の新機能
• Node.js 18.14.0
  • Node 18.14.0 のブログ記事
• V8 11.2

破壊的な変更​

API の変更: nativeImage.createThumbnailFromPath(path, size)​

maxSize パラメーターが size に変更され、渡されたサイズが作成されるサムネイルのサイズになることを反映しました。以前は、Windows では画像が maxSize よりも小さい場合は拡大されず、macOS では常にサイズが maxSize に設定されていました。動作はプラットフォーム間で同じになりました。

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

// Scaling up a smaller image.
const upSize = { width: 256, height: 256 };
nativeImage.createThumbnailFromPath(imagePath, upSize).then((result) => {
  console.log(result.getSize()); // { width: 256, height: 256 }
});

// Scaling down a larger image.
const downSize = { width: 64, height: 64 };
nativeImage.createThumbnailFromPath(imagePath, downSize).then((result) => {
  console.log(result.getSize()); // { width: 64, height: 64 }
});

新機能​

• cookies.get() で HttpOnly クッキーをフィルタリングする機能を追加しました。#37365
• shell.openExternal() オプションに logUsage を追加しました。これにより、Windows で ShellExecuteEx に SEE_MASK_FLAG_LOG_USAGE フラグを渡すことができます。SEE_MASK_FLAG_LOG_USAGE フラグは、頻繁に使用されるプログラムやその他の動作の追跡を有効にするユーザー開始の起動を示します。#37291
• webRequest フィルターに types を追加し、リッスンするリクエストをフィルタリングする機能を追加しました。#37427
• 新しい devtools-open-url イベントを webContents に追加して、開発者が新しいウィンドウを開くことができるようにしました。#36774
• webContents.print() にいくつかの標準ページサイズオプションを追加しました。#37265
• audio が WebFrameMain の場合、リモートオーディオ入力をローカル出力ストリームでエコーできるようにする enableLocalEcho フラグを、セッションハンドラー ses.setDisplayMediaRequestHandler() コールバックに追加しました。#37528
• アプリケーション固有のユーザー名を inAppPurchase.purchaseProduct() に渡せるようにしました。#35902
• macOS 上で残存する視覚的なアーティファクトをクリアするために window.invalidateShadow() を公開しました。#32452
• プログラム全体の最適化が、electron node ヘッダー構成ファイルでデフォルトで有効になり、コンパイラは、モジュールごと（コンパイラごと）ではなく、プログラム内のすべてのモジュールからの情報を使用して最適化を実行できるようになりました。#36937
• SystemPreferences::CanPromptTouchID (macOS) が Apple Watch をサポートするようになりました。#36935

21.x.y のサポート終了​

Electron 21.x.y は、プロジェクトの サポートポリシーに従って、サポートが終了しました。開発者とアプリケーションは、新しいバージョンの Electron にアップグレードすることをお勧めします。

さよなら、Windows 7/8/8.1 で述べられているように、Electron 22（Chromium 108）の計画されているサポート終了日は、2023年5月30日から2023年10月10日に延長されます。Electronチームは、このプログラムの一部であるセキュリティ修正を2023年10月10日までElectron 22にバックポートし続けます。

今後の予定​

短期的には、チームがChromium、Node、V8を含むElectronを構成する主要コンポーネントの開発に引き続き注力していくことが予想されます。

Electronの公開タイムラインはこちらで確認できます。

将来の変更に関する詳しい情報は、計画されている破壊的変更のページで確認できます。

electron/electron リポジトリへの最初のコミットは、2013年3月13日でした¹。

10年と1192人のユニークな貢献者からの27,147以上のコミットの後、Electronは今日、デスクトップアプリケーションを構築するための最も人気のあるフレームワークの1つになりました。このマイルストーンは、これまでの道のりを祝い、振り返り、その過程で学んだことを共有する絶好の機会です。

プロジェクトに時間と労力を費やして貢献してくださったすべての方々がいなければ、今日の私たちはここにいませんでした。ソースコードのコミットは常に最も目に見える貢献ですが、バグを報告し、ユーザーランドモジュールを維持し、ドキュメントと翻訳を提供し、サイバースペース全体でElectronコミュニティに参加している人々の努力も認めなければなりません。すべての貢献は、メンテナーとしての私たちにとって非常に貴重です。

ブログ記事の続きに入る前に、ありがとうございます。❤️

私たちはどのようにしてここにたどり着いたのでしょうか？​

Atom Shell は、2014年4月にパブリックベータ版がリリースされたGitHubの Atomエディター のバックボーンとして構築されました。当時利用可能だったWebベースのデスクトップフレームワーク（node-webkitとChromium Embedded Framework）の代替として、ゼロから構築されました。それはキラー機能を持っていました。Node.jsとChromiumを埋め込んで、Webテクノロジーのための強力なデスクトップランタイムを提供することです。

1年以内に、Atom Shellは機能と人気において大きな成長を見せ始めました。大企業、スタートアップ、個々の開発者が同様にそれを使ってアプリを構築し始め（初期の採用者には Slack、 GitKraken、 WebTorrent などがあります）、プロジェクトは適切に Electron に改名されました。

それ以来、Electronは走り続け、止まることはありませんでした。これが npmtrends.com の提供による、時間の経過に伴う毎週のダウンロード数の推移です。

Electron v1は2016年にリリースされ、APIの安定性とより優れたドキュメントとツールが約束されました。Electron v2は2018年にリリースされ、セマンティックバージョニングが導入され、Electron開発者がリリースサイクルを追跡しやすくなりました。

Electron v6までに、Chromiumに合わせて、通常の12週間のメジャーリリースケイデンスに移行しました。この決定は、プロジェクトの考え方の変化であり、「最新のChromiumバージョンを持つこと」を、持っていると便利なものから優先事項に変えました。これにより、アップグレード間の技術的負債が減り、Electronを最新かつ安全に保つのが容易になりました。

それ以来、私たちは順調に稼働しており、Chromium stableと同じ日に新しいElectronバージョンをリリースしています。Chromiumが2021年にリリーススケジュールを4週間に短縮したときには、肩をすくめて、それに応じてリリースケイデンスを8週間に増やすことができました。

現在、私たちはElectron v23（そしてそれ以降）であり、クロスプラットフォームのデスクトップアプリケーションを構築するための最適なランタイムを構築することに依然として専念しています。近年、JavaScript開発者向けツールのブームがあったにもかかわらず、Electronは、デスクトップアプリフレームワークの分野で安定した、実戦でテストされた頑強な存在であり続けています。Electronアプリは今やユビキタスです。Visual Studio Codeでプログラミングしたり、Figmaでデザインしたり、Slackでコミュニケーションしたり、Notionでメモを取ったりすることができます（他にも多くのユースケースがあります）。この成果を非常に誇りに思っており、実現を可能にしたすべての人々に感謝しています。

その過程で私たちは何を学んだのでしょうか？​

10年の節目への道は長く曲がりくねったものでした。持続可能な大規模オープンソースプロジェクトを運営するのに役立った主なことをいくつかご紹介します。

ガバナンスモデルによる分散型意思決定の拡大​

私たちが克服しなければならなかった1つの課題は、Electronが最初に人気を博した後のプロジェクトの長期的な方向性を処理することでした。企業、国、タイムゾーンに分散した数十人のエンジニアのチームとしてどのように対処するのでしょうか？

初期の頃、Electronのメンテナーグループは非公式な調整に頼っていました。これは小規模なプロジェクトでは迅速で軽量ですが、より幅広いコラボレーションにはスケールしません。2019年に、私たちは異なるワーキンググループが正式な責任領域を持つガバナンスモデルに移行しました。これは、プロセスを合理化し、プロジェクトの所有権の一部を特定のメンテナーに割り当てる上で役立ってきました。各ワーキンググループ（WG）は現在、何を担当しているのでしょうか？

• Electron リリースを世に出す (リリース WG)
• Chromium と Node.js のアップグレード (アップグレード WG)
• パブリック API 設計の監督 (API WG)
• Electron のセキュリティ維持 (セキュリティ WG)
• ウェブサイト、ドキュメント、ツール（エコシステム WG）の運営
• コミュニティおよび企業のアウトリーチ (アウトリーチ WG)
• コミュニティモデレーション (コミュニティおよび安全 WG)
• ビルドインフラストラクチャ、メンテナーツール、クラウドサービスの維持 (インフラストラクチャ WG)

ガバナンスモデルに移行したのとほぼ同時期に、Electronの所有権をGitHubからOpenJS Foundation にも移しました。元のコアチームは現在もMicrosoftで働いていますが、Electronガバナンスを形成するより大きな協力者のグループの一部にすぎません。²

このモデルは完璧ではありませんが、世界的なパンデミックや継続的なマクロ経済の逆風の中、私たちにとって非常に役立ってきました。今後は、Electron の20年目を導くために、ガバナンス憲章を刷新する予定です。

コミュニティ​

オープンソースにおけるコミュニティ部分は難しく、特にアウトリーチチームが「コミュニティマネージャー」と書かれたトレンチコートを着た十数人のエンジニアである場合はなおさらです。とはいえ、大規模なオープンソースプロジェクトであるということは、多くのユーザーがいることを意味し、ユーザーランドのエコシステムを構築するためにElectronに対する彼らのエネルギーを活用することは、プロジェクトの健全性を維持する上で非常に重要です。

コミュニティの存在感を高めるために、私たちは何をしてきたのでしょうか？

仮想コミュニティの構築​

• 2020年、私たちはコミュニティDiscordサーバーを立ち上げました。以前はAtomのフォーラムにセクションがありましたが、メンテナーとElectron開発者間の議論や一般的なデバッグ支援のためのスペースとして、よりインフォーマルなメッセージングプラットフォームを持つことにしました。
• 2021年には、@BlackHole1の協力のもと、Electron Chinaユーザーグループを設立しました。このグループは、中国の活況を呈しているテクノロジーシーンからのElectronユーザーの成長に貢献しており、英語圏以外の場所でアイデアを共同で検討し、Electronについて議論するためのスペースを提供しています。また、npmの中国ミラーでElectronのナイトリーリリースをサポートしてくれているcnpmにも感謝いたします。

注目度の高いオープンソースプログラムへの参加​

• 私たちは2019年から毎年Hacktoberfestを祝っています。Hacktoberfestは、DigitalOceanが主催するオープンソースの毎年恒例の祭典であり、毎年多くの熱心な貢献者がオープンソースソフトウェアに足跡を残そうと参加してくれます。
• 2020年には、Google Season of Docsの最初のイテレーションに参加し、@bandantonioと協力して、Electronの新しいユーザーチュートリアルの流れを再構築しました。
• 2022年には、初めてGoogle Summer of Codeの学生を指導しました。@aryanshridharは、Electron Fiddleのコアバージョンローディングロジックをリファクタリングし、そのバンドラーをwebpackに移行するという素晴らしい作業を行いました。

すべてを自動化！​

現在、Electronのガバナンスには約30人のアクティブなメンテナーがいます。私たちの半分以下がフルタイムの貢献者であるため、やるべきことがたくさんあります。すべてをスムーズに動かすための私たちの秘訣は何でしょうか？私たちのモットーは、コンピューターは安価で、人間の時間は高価であるということです。典型的なエンジニアのやり方で、私たちは自分たちの生活を楽にするための自動化されたサポートツール群を開発しました。

Not Goma​

Electronのコアコードベースは、C++コードの巨大な塊であり、ビルド時間は、バグ修正や新機能をどれだけ速く出荷できるかの制約要因となってきました。2020年、私たちはGoogleのGoma分散コンパイラーサービス用のカスタムのElectron固有のバックエンドであるNot Gomaをデプロイしました。Not Gomaは、許可されたユーザーのマシンからのコンパイル要求を処理し、バックエンドの数百のコアにプロセスを分散します。また、コンパイル結果をキャッシュするため、同じファイルをコンパイルする別の人は、事前にコンパイルされた結果をダウンロードするだけで済みます。

Not Gomaを起動して以来、メンテナーのコンパイル時間は数時間単位から数分単位に短縮されました。安定したインターネット接続が、貢献者がElectronをコンパイルするための最低限の要件になりました！

継続的な多要素認証​

継続的な多要素認証 (CFA) は、npmの多要素認証（2FA）システムを自動化するレイヤーであり、semantic-releaseと組み合わせて、さまざまな@electron/ npmパッケージの安全で自動化されたリリースを管理します。

semantic-releaseはすでにnpmパッケージの公開プロセスを自動化していますが、多要素認証をオフにするか、この制限を回避する秘密トークンを渡す必要があります。

私たちは、npm 2FA用の時間ベースのワンタイムパスワード（TOTP）を任意のCIジョブに配信するためにCFAを構築しました。これにより、多要素認証の追加のセキュリティを維持しながら、semantic-releaseの自動化を活用できます。

私たちはSlack統合フロントエンドでCFAを使用しており、メンテナーはTOTPジェネレーターを手元に持っていれば、Slackがインストールされている任意のデバイスからパッケージの公開を検証できます。

Sheriff​

Sheriffは、GitHub、Slack、Google Workspace全体での権限の管理を自動化するために私たちが作成したオープンソースツールです。

Sheriffの主な価値提案は、権限管理が透過的なプロセスであるべきだということです。上記のすべてのサービスにわたる権限を指定する単一のYAML構成ファイルを使用します。Sheriffを使用すると、リポジトリのコラボレーターのステータスを取得したり、新しいメーリングリストを作成したりすることは、PRが承認されてマージされるのと同じくらい簡単になります。

SheriffにはSlackに投稿する監査ログもあり、Electron組織のどこかで不審なアクティビティが発生した場合に管理者に警告します。

…そして、すべてのGitHubボット​

GitHubは、豊富なAPI拡張性とProbotと呼ばれるファーストパーティのボットアプリケーションフレームワークを備えたプラットフォームです。仕事のより創造的な部分に集中できるように、私たちは面倒な作業を支援する一連の小さなボットを構築しました。以下にいくつかの例を示します。

• Sudowoodoは、ビルドの開始からリリースアセットをGitHubおよびnpmにアップロードするまで、Electronのリリースプロセスを最初から最後まで自動化します。
• Tropは、GitHub PRラベルに基づいて、以前のリリースブランチへのパッチのチェリーピックを試行することで、Electronのバックポートプロセスを自動化します。
• Rollerは、ElectronのChromiumおよびNode.js依存関係のローリングアップグレードを自動化します。
• Cationは、electron/electron PRのステータスチェックボットです。

全体として、私たちの小さなボットファミリーは、開発者の生産性を大幅に向上させました！

次は？​

プロジェクトとしての20年目を迎えるにあたり、Electronの次はどうなるのか？と疑問に思われるかもしれません。

私たちはChromiumのリリースリズムと同期し、8週間ごとにElectronの新しいメジャーバージョンをリリースし、WebプラットフォームとNode.jsの最新かつ最高のものをフレームワークに更新し、エンタープライズグレードのアプリケーションの安定性とセキュリティを維持します。

今後の取り組みに関するニュースは、具体化した場合に発表することが一般的です。今後のリリース、機能、および一般的なプロジェクトの最新情報を入手したい場合は、私たちのブログを読んだり、ソーシャルメディアプロファイル(TwitterおよびMastodon)をフォローしたりできます！

Electron 23.0.0がリリースされました！Chromium 110、V8 11.0、およびNode.js 18.12.1へのアップグレードが含まれています。さらに、Windows 7/8/8.1のサポートは終了しました。詳細については、以下をお読みください！

Electronチームは、Electron 23.0.0のリリースを発表できることを嬉しく思います！npm install electron@latest を使用してnpmでインストールするか、リリースWebサイトからダウンロードできます。このリリースに関する詳細については、読み続けてください。

フィードバックがある場合は、Twitterで共有するか、コミュニティのDiscordにご参加ください。バグや機能リクエストは、Electronのissue trackerで報告できます。

注目すべき変更点​

スタックの変更​

• Chromium 110
  • Chrome 110の新機能
  • Chrome 109の新機能
  • DevTools 110の新機能
  • DevTools 109の新機能
• Node.js 18.12.1
  • Node 18.12.1 ブログ記事
• V8 11.0

新機能​

• Display オブジェクトに label プロパティが追加されました。#36933
• ユーザーのシステム言語を返す app.getPreferredSystemLanguages() API が追加されました。#36035
• WebUSB API のサポートが追加されました。#36289
• SerialPort.forget() のサポートと、特定のオリジンが取り消されたときにSessionオブジェクトで発生する新しいイベント serial-port-revoked が追加されました。#35310
• macOS で Mission Control をオプトアウトできるようにする新しい win.setHiddenInMissionControl API が追加されました。#36092

Windows 7/8/8.1 のサポート終了​

Electron 23 は、Windows 7/8/8.1 をサポートしなくなりました。Electron は、Chromium の廃止ポリシーに従い、Chromium 109 で Windows 7/8/8.1、および Windows Server 2012 および 2012 R2 のサポートを廃止します（詳細はこちら）。

API の破壊的変更​

以下は、Electron 23 で導入された破壊的な変更点です。これらの変更点や今後の変更点については、計画された破壊的変更ページで詳しくご覧いただけます。

削除: BrowserWindow scroll-touch-* イベント​

BrowserWindow の非推奨の scroll-touch-begin、scroll-touch-end、および scroll-touch-edge イベントが削除されました。代わりに、WebContents で新しく利用可能になった input-event イベントを使用してください。

// Removed in Electron 23.0
-win.on('scroll-touch-begin', scrollTouchBegin)
-win.on('scroll-touch-edge', scrollTouchEdge)
-win.on('scroll-touch-end', scrollTouchEnd)

// Replace with
+win.webContents.on('input-event', (_, event) => {
+  if (event.type === 'gestureScrollBegin') {
+    scrollTouchBegin()
+  } else if (event.type === 'gestureScrollUpdate') +{
+    scrollTouchEdge()
+  } else if (event.type === 'gestureScrollEnd') {
+    scrollTouchEnd()
+  }
+})

20.x.y のサポート終了​

Electron 20.x.y は、プロジェクトのサポートポリシーに従って、サポートが終了しました。開発者およびアプリケーションは、新しいバージョンの Electron にアップグレードすることを推奨します。

今後の予定​

短期的には、チームがChromium、Node、V8を含むElectronを構成する主要コンポーネントの開発に引き続き注力していくことが予想されます。

Electronの公開タイムラインはこちらで確認できます。

将来の変更に関する詳しい情報は、計画されている破壊的変更のページで確認できます。

Electron 22.0.0 がリリースされました！新しいユーティリティプロセス API、Windows 7/8/8.1 のサポートに関するアップデート、Chromium 108、V8 10.8、および Node.js 16.17.1 へのアップグレードが含まれています。詳細については以下をお読みください！

Electron チームは、Electron 22.0.0 のリリースを発表できることを嬉しく思っています！npm install electron@latest を使用して npm でインストールするか、リリース Web サイトからダウンロードできます。このリリースに関する詳細については、以下をお読みください。

フィードバックがある場合は、Twitterで共有するか、コミュニティのDiscordにご参加ください。バグや機能リクエストは、Electronのissue trackerで報告できます。

注目すべき変更点​

スタックの変更​

• Chromium 108
  • Chrome 108 の新機能
  • Chrome 107 の新機能
  • DevTools 108 の新機能
  • DevTools 107 の新機能
• Node.js 16.17.1
  • Node 16.17.1 ブログ記事
• V8 10.8

主な機能​

UtilityProcess API #36089​

新しい UtilityProcess メインプロセスモジュールを使用すると、Node.js の統合のみを備えた軽量な Chromium 子プロセスを作成できると同時に、MessageChannel を使用してサンドボックス化されたレンダラーと通信できます。この API は、移行を容易にするために Node.js の child_process.fork に基づいて設計されました。主な違いは、信頼できるスクリプトのみがロードされるように、エントリポイント modulePath がパッケージ化されたアプリケーション内にある必要があることです。さらに、このモジュールは、メインプロセスがアプリケーション内の唯一の信頼できるプロセスであるという契約を維持するために、デフォルトでレンダラーとの通信チャネルの確立を防止します。

詳細については、ドキュメントの新しい UtilityProcess APIをご覧ください。

Windows 7/8/8.1 サポートの更新​

Electron 22 は、Windows 7/8/8.1 をサポートする最後の Electron メジャーバージョンとなります。Electron は、Chromium の廃止ポリシーに従い、Chromium 109 で Windows 7/8/8.1 のサポートを廃止します（詳細はこちら）。

Windows 7/8/8.1 は、Electron 23 以降のメジャーリリースではサポートされません。

その他の主な変更点​

• Linux および Windows で Web Bluetooth ピンペアリングのサポートが追加されました。#35416
• LoadBrowserProcessSpecificV8Snapshot を、メイン/ブラウザプロセスが browser_v8_context_snapshot.bin のファイルから v8 スナップショットをロードできるようにする新しいヒューズとして追加しました。その他のプロセスは、今日使用されているのと同じパスを使用します。#35266
• ウィンドウオープナーにアクセスする WebContents.opener と、WebFrameMain インスタンスに対応する WebContents を取得する webContents.fromFrame(frame) が追加されました。#35140
• 新しいセッションハンドラー ses.setDisplayMediaRequestHandler を介して navigator.mediaDevices.getDisplayMedia のサポートが追加されました。#30702

API の破壊的変更​

以下は、Electron 22 で導入された破壊的な変更点です。これらの変更点や今後の変更点については、計画された破壊的変更ページで詳しくご覧いただけます。

非推奨: webContents.incrementCapturerCount(stayHidden, stayAwake)​

webContents.incrementCapturerCount(stayHidden, stayAwake) は非推奨になりました。ページキャプチャが完了すると、webContents.capturePage によって自動的に処理されるようになりました。

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

- w.webContents.incrementCapturerCount()
- w.capturePage().then(image => {
-   console.log(image.toDataURL())
-   w.webContents.decrementCapturerCount()
- })

+ w.capturePage().then(image => {
+   console.log(image.toDataURL())
+ })

非推奨: webContents.decrementCapturerCount(stayHidden, stayAwake)​

webContents.decrementCapturerCount(stayHidden, stayAwake) は非推奨になりました。ページキャプチャが完了すると、webContents.capturePage によって自動的に処理されるようになりました。

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

- w.webContents.incrementCapturerCount()
- w.capturePage().then(image => {
-   console.log(image.toDataURL())
-   w.webContents.decrementCapturerCount()
- })

+ w.capturePage().then(image => {
+   console.log(image.toDataURL())
+ })

削除: WebContents new-window イベント​

WebContents の new-window イベントが削除されました。これは、webContents.setWindowOpenHandler() に置き換えられました。

- webContents.on('new-window', (event) => {
-   event.preventDefault()
- })

+ webContents.setWindowOpenHandler((details) => {
+   return { action: 'deny' }
+ })

非推奨: BrowserWindow scroll-touch-* イベント​

BrowserWindow の scroll-touch-begin、scroll-touch-end、および scroll-touch-edge イベントは非推奨になりました。代わりに、WebContents で新しく利用可能になった input-event イベントを使用してください。

// Deprecated
- win.on('scroll-touch-begin', scrollTouchBegin)
- win.on('scroll-touch-edge', scrollTouchEdge)
- win.on('scroll-touch-end', scrollTouchEnd)

// Replace with
+ win.webContents.on('input-event', (_, event) => {
+   if (event.type === 'gestureScrollBegin') {
+     scrollTouchBegin()
+   } else if (event.type === 'gestureScrollUpdate') {
+     scrollTouchEdge()
+   } else if (event.type === 'gestureScrollEnd') {
+     scrollTouchEnd()
+   }
+ })

19.x.y のサポート終了​

Electron 19.x.y は、プロジェクトのサポートポリシーに従って、サポートが終了しました。開発者およびアプリケーションは、新しいバージョンの Electron にアップグレードすることを推奨します。

今後の予定​

Electron プロジェクトは、2022 年 12 月の間一時停止し、2023 年 1 月に再開します。詳細については、12 月のシャットダウンに関するブログ記事をご覧ください。

短期的には、チームがChromium、Node、V8を含むElectronを構成する主要コンポーネントの開発に引き続き注力していくことが予想されます。

Electronの公開タイムラインはこちらで確認できます。

将来の変更に関する詳しい情報は、計画されている破壊的変更のページで確認できます。