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-01 時点で、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 ファイルをサポートするようになりました。 (P.S. Electron 28 での ESM エントリポイントのサポートをご期待ください。)
• Maker を並列実行するようになりました: Electron Forge 6 では、Maker は ✨ レガシー✨ な理由で直列実行していました。 それ以来、副作用のない 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 Organization に組み込まれ、コアチームがそのメンテナンスを負担していました。

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/ 名前空間の下にその monorepo パッケージ全てを公開し続けます。

@electron/windows-sign の紹介​

2023-06-01 以降、業界標準は FIPS 準拠のハードウェアに格納される Windows のコード署名証明書の鍵を要求するようになりました。

実際には、CI 環境でビルドおよびサインインを行うアプリにとってのコード署名が非常に困難になりました。 多くの Electron ツールは、設定パラメータとして証明書ファイルとパスワードを取り込み、そこからハードコードされたロジックで署名しようとします。

この状況は Electron 開発者にとって共通の苦痛となっています。だからこそ、Windows のコード署名をスタンドアローンな手順へと分離する改善策に取り組んでいるのです。この手順は macOS で @electron/osx-sign が行うことに似ています。

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

レポジトリの Issue トラッカー にてぜひご意見をお寄せください！

次は何をするのでしょうか？​

私たちは来月から、毎年 12 月の安息期に入る予定です。 私たちはその間、2024 年に Electron の開発体験をさらに向上させる方法について考えていることでしょう。

次に取り組んでほしいことがおありですか？ ぜひお聞かせください！

Electron プロジェクトは 2023 年 12 月の 1 ヶ月間休止し、2024 年 1 月から全力に戻ります。

GIPHY より

12 月でも変わらないこと​

1. ゼロデイやその他の主要なセキュリティ関連のリリースは必要に応じて公開されます。 セキュリティインシデントは、SECURITY.md に則って報告してください。
2. 行動規範 における通報とモデレーションは継続されます。

12 月で変わること​

1. Electron 28.0.0 は 12 月 5 日にリリースされます。 Electron 28 以降、12 月中に新しい安定版のリリースはありません。
2. 12 月の最後の 2 週間は、ナイトリーやアルファのリリースはありません。
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 の新機能
  • デベロッパー ツール 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 を使用してください。

// 削除されました
systemPreferences.on('inverted-color-scheme-changed', () => {
  /* ... */
});
systemPreferences.on('high-contrast-color-scheme-changed', () => {
  /* ... */
});

// こちらで置き換えてください
nativeTheme.on('updated', () => {
  /* ... */
});

削除: webContents.getPrinters​

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

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

// 削除されました
console.log(w.webContents.getPrinters());
// こちらで置き換えてください
w.webContents.getPrintersAsync().then((printers) => {
  console.log(printers);
});

削除: systemPreferences.{get,set}AppLevelAppearance と systemPreferences.appLevelAppearance​

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

// 削除されました
systemPreferences.getAppLevelAppearance();
// こちらで置き換えてください
nativeTheme.shouldUseDarkColors;

// 削除されました
systemPreferences.appLevelAppearance;
// こちらで置き換えてください
nativeTheme.shouldUseDarkColors;

// 削除されました
systemPreferences.setAppLevelAppearance('dark');
// こちらで置き換えてください
nativeTheme.themeSource = 'dark';

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

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

// 削除されました
systemPreferences.getColor('alternate-selected-control-text');
// こちらで置き換えてください
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 チームは Chrome の Windows 7/8/8.1 のサポート延長に合わせて、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 のバージョンを更新すべきです。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 としていたり、nodeIntegration: true になっていることがあります。これらは明示的に sandbox を設定しない限り、等しくサンドボックスを無効化します。 そのような行いも理解できます。ご寵愛頂いてきた方であれば、おそらく require("child_process") や require("fs") を HTML/CSS と同じコードに投げ込んで実行する強力さを味わってきたことでしょう。

どうやって サンドボックスに移行するのかについて話す前に、まずは なぜ 移行したいのかについてご説明します。

サンドボックスは、すべてのレンダラープロセスを硬い檻で囲い、内部で何が起ころうと、コードが制限された環境内で実行されることを保証します。 コンセプトとしては 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. サンドボックスを有効にすると、プリロードスクリプトの Node.js 統合が無効になるため、require("../my-script") を使用できなくなります。 つまり、プリロードスクリプトは単一のファイルである必要があります。

   この実現には複数の方法があります。Webpack、esbuild、parcel、rollup はすべて、この役割を担います。 私は Electron Forge の優れた Webpack プラグイン を使いました。同じくらい人気のある electron-builder のユーザーの方は、electron-webpack を利用できるでしょう。

これで全てです。Webpack の巨大なパワーを使いこなすために頭を悩ませたことや、他の方法へコードをリファクタリングする機会にしようと決めたことも含めると、全体の処置には 4 日ほどかかりました。

Electron 26.0.0 がリリースされました! これには Chromium 116.0.5845.62、V8 11.2、Node.js 18.16.1 へのアップグレードが含まれています。 詳しくは以下をご覧ください!

Electron チームは、Electron 26.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細は続きをご覧ください。

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

注目すべき変更​

累積的変更​

• Chromium 116.0.5845.62
  • Chrome 116 の新機能
  • デベロッパー ツール 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 });

// 非推奨
console.log(w.webContents.getPrinters());
// こちらで置き換えてください
w.webContents.getPrintersAsync().then((printers) => {
  console.log(printers);
});

非推奨: systemPreferences.{get,set}AppLevelAppearance と systemPreferences.appLevelAppearance​

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

// 非推奨
systemPreferences.getAppLevelAppearance();
// こちらで置き換えてください
nativeTheme.shouldUseDarkColors;

// 非推奨
systemPreferences.appLevelAppearance;
// こちらで置き換えてください
nativeTheme.shouldUseDarkColors;

// 非推奨
systemPreferences.setAppLevelAppearance('dark');
// こちらで置き換えてください
nativeTheme.themeSource = 'dark';

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

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

// 非推奨
systemPreferences.getColor('alternate-selected-control-text');
// こちらで置き換えてください
systemPreferences.getColor('selected-content-background');

新機能​

• safeStorage.setUsePlainTextEncryption と safeStorage.getSelectedStorageBackend の API を追加しました。 #39107
• safeStorage.setUsePlainTextEncryption と safeStorage.getSelectedStorageBackend の API を追加しました。 #39155
• ipcRenderer.sendTo() 経由で送信されたメッセージに senderIsMainFrame を追加しました。 #39206
• Menu にキーボードで呼び出されたときのフラグを立てるサポートが追加されました。 #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 install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細は続きをご覧ください。

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

注目すべき変更​

ハイライト​

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

累積的変更​

• Chromium 114
  • Chrome 114 の新機能
  • Chrome 113 の新機能
  • デベロッパー ツール 114 の新機能
  • デベロッパー ツール 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 に置き換えられました。

新しいメソッドは、新しいプロトコルを登録するか、既存のプロトコルを傍受するか、どのタイプの応答も可能です。

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

// 以下で置き換えてください
protocol.handle('some-protocol', () => {
  return new Response(
    Buffer.from('<h5>Response</h5>'), //  string または ReadableStream になりえる
    { headers: { 'content-type': 'text/html' } }
  );
});

// Electron 25 で非推奨
protocol.registerHttpProtocol('some-protocol', () => {
  callback({ url: 'https://electronjs.org' });
});

// 以下で置き換えてください。
protocol.handle('some-protocol', () => {
  return net.fetch('https://electronjs.org');
});

// Electron 25 では非推奨
protocol.registerFileProtocol('some-protocol', () => {
  callback({ filePath: '/path/to/my/file' });
});

// 以下で置き換えてください
protocol.handle('some-protocol', () => {
  return net.fetch('file:///path/to/my/file');
});

非推奨: BrowserWindow.setTrafficLightPosition(position)​

BrowserWindow.setTrafficLightPosition(position) は非推奨になり、代わりに BrowserWindow.setWindowButtonPosition(position) API を使うようになりました。こちらでシステム基底の位置へリセットする際には、{ x: 0, y: 0 } の代わりに null を受け付けるようになっています。

// Electron 25 では非推奨
win.setTrafficLightPosition({ x: 10, y: 10 });
win.setTrafficLightPosition({ x: 0, y: 0 });

// 以下で置き換えてください
win.setWindowButtonPosition({ x: 10, y: 10 });
win.setWindowButtonPosition(null);

非推奨: BrowserWindow.getTrafficLightPosition()​

BrowserWindow.getTrafficLightPosition() は非推奨になり、代わりに BrowserWindow.getWindowButtonPosition() API を使うようになりました。こちらでカスタム位置が無いときは、{ x: 0, y: 0 } の代わりに null を受け付けるようになっています。

// Electron 25 で非推奨
const pos = win.getTrafficLightPosition();
if (pos.x === 0 && pos.y === 0) {
  // カスタム位置が無い場合。
}

// 以下で置き換えてください
const ret = win.getWindowButtonPosition();
if (ret === null) {
  // カスタム位置が無い場合。
}

新機能​

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

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

さらば、Windows 7/8/8.1 で述べた通り、Electron 22 (Chromium 108) の EOL 予定日は 2023 年 5 月 30 日から 2023 年 10 月 10 日へと延長されました。 Electron チームは、2023 年 10 月 10 日までこのプログラムの一部であるセキュリティ修正の Electron 22 へのバックポートを継続する予定です。 10 月のサポート日は Chromium と Microsoft 両方の延長サポート日に従っています。 10 月 11 日時点で、Electron チームは最新から 3 つの安定版メジャーバージョンが Windows 7/8/8.1 サポートすることを終了します。

次回予告​

短期的には、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 トラッカー で報告できます。

注目すべき変更​

累積的変更​

• Chromium 112.0.5615.49
  • Chrome 112 の新機能
  • Chrome 111 の新機能
  • デベロッパー ツール 112 の新機能
  • デベロッパー ツール 111 の新機能
• Node.js 18.14.0
  • Node 18.14.0 ブログ記事
• V8 11.2

破壊的変更​

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

maxSize 引数は size に変更されました。これに渡されたサイズがサムネイルの作成サイズになります。 以前は、Windows は maxSize より小さいときでは画像を拡大せず、macOS は常にサイズを maxSize にしていました。 この挙動がプラットフォーム間で同じなります。

// 128x128 の画像。
const imagePath = path.join('path', 'to', 'capybara.png');

// 小さい画像を拡大します。
const upSize = { width: 256, height: 256 };
nativeImage.createThumbnailFromPath(imagePath, upSize).then((result) => {
  console.log(result.getSize()); // { width: 256, height: 256 }
});

// 大きい画像を縮小します。
const downSize = { width: 64, height: 64 };
nativeImage.createThumbnailFromPath(imagePath, downSize).then((result) => {
  console.log(result.getSize()); // { width: 64, height: 64 }
});

新機能​

• cookies.get() で HttpOnly な Cookie をフィルターできる機能を追加しました。 #37365
• logUsage を shell.openExternal() のオプションに追加しました。これにより、Windows で SEE_MASK_FLAG_LOG_USAGE フラグを ShellExecuteEx に渡せます。 SEE_MASK_FLAG_LOG_USAGE フラグは、頻繁に使用されるプログラムやその他の動作をトラッキングできる形でユーザーが起動し始めたことを示します。 #37291
• types を webRequest フィルターに追加し、リッスンするリクエストをフィルターする機能を追加しました。#37427
• 新しく devtools-open-url イベントを追加し、webContents で開発者が新しいウインドウを開けるようになりました。 #36774
• webContents.print() にいくつかの標準ページサイズのオプションを追加しました。 #37265
• enableLocalEcho フラグをセッションハンドラー ses.setDisplayMediaRequestHandler() のコールバックに追加しました。これは audio が WebFrameMain の場合に、リモートのオーディオ入力をローカル出力ストリームにエコーできます。 #37528
• アプリケーション固有のユーザー名を inAppPurchase.purchaseProduct() に渡せるようになりました。 #35902
• window.invalidateShadow() が公開され、これは macOS での残留する視覚効果を消去できます。 #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) の EOL 予定日は 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 エディタ の基盤として作られました。 当時利用可能だったウェブベースのデスクトップフレームワーク (node-webkit や Chromium Embedded Framework) に代わるものとして、ゼロから構築されたものです。 驚くべき機能としては、Node.js と Chromium を組み込むことでウェブ技術向けの強力なデスクトップランタイムを提供していました。

1 年も経たないうちに、Atom Shell の性能と人気は絶大なものになりました。 大企業、スタートアップ、そして個人開発者たちがこぞって Electron でアプリを作り始め (初期の採用企業は Slack、GitKraken、WebTorrent など)、このプロジェクトは Electron という適切な名前に変更されました。

それ以来、Electron は本格的に活動してきました。 週間ダウンロード数の変化は、こちらの npmtrends.com のご好意によってご覧いただけます。

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

Electron v6 では、Chromium と同じ 12 週間の定期メジャーリリースケジュールに移行しました。 この決定はプロジェクトの考え方において「Chromium のバージョンを最新にする」ということを必須事項から優先事項に変えました。 これによりアップグレード間の技術的負債が減り、Electron の更新と堅牢性の維持が容易になりました。

それ以来、Electron の新バージョンを Chromium の安定版と同じ日にリリースするという、よくできた仕組みになっています。 2021 年に Chromium がリリーススケジュールを 4 週間に早めた時には、私たちは肩をすくめて、それに合わせてリリースケーデンスを8週間に増やすことにしました。

Electron は現在 v23 であり (そしてこれからも増え続ける)、クロスプラットフォームのデスクトップアプリケーションを構築するための最高のランタイムを構築することに専念しています。 近年、JavaScript の開発ツールがブームになっていますが、Electron はデスクトップアプリケーションのフレームワークとして、安定しており実戦投入され頑丈であり続けています。 Electron アプリは今やどこにでもあります。Visual Studio Code でプログラミング、Figma でデザイン、Slack でコミュニケーション、Notion でメモ (他にも多くの使用例があります)。 私たちはこの業績を非常に誇りに思うと同時に、助力して頂いたすべての人に感謝しています。

この過程で何を学んだのでしょうか？​

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

ガバナンスモデルで分散された意思決定をスケールする​

Electron が爆発的に普及した後、私たちの克服すべき課題はプロジェクトの長期的な方向性をどうするかでした。 会社や国、タイムゾーンを越えて分散している数十人のエンジニアのチームを、どのように指揮すればよいのでしょうか。

初期の頃、Electron のメンテナーグループはインフォーマルな調整に頼っていました。小規模なプロジェクトでは高速かつ軽量ですが、より広範な協働作業にはスケールしません。 2019 年には、異なるワーキンググループがフォーマルな責任領域を担うガバナンスモデルに移行しました。 これは、プロセスを効率化し、プロジェクトの所有権の一部を特定のメンテナーに割り当てるのに役立っています。 それぞれのワーキンググループ (WG) は、今日ではどのような役割を担っているのでしょうか？

• Electron のリリースの広報 (Releases WG)
• Chromium と Node.js のアップグレード (Upgrades WG)
• 公開 API のデザインの管理 (API WG)
• Electron の堅牢性の維持 (Security WG)
• ウェブサイトの運営、ドキュメント化、ツール作成 (Ecosystem WG)
• コミュニティと企業への働きかけ (Outreach WG)
• コミュニティのモデレーション (Community & Safety WG)
• ビルドインフラ、メンテナーのツール、クラウドサービスの維持管理 (Infrastructure WG)

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

このモデルは完璧ではありませんが、世界的パンデミックやマクロ経済の逆風が続く中で、私たちによく適していました。 今後は、Electron を次の 10 年に繋げるために、ガバナンス憲章を改訂していく予定です。

コミュニティ​

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

コミュニティの活気を高めるために、どのようなことを行ってきたのでしょうか。

バーチャルコミュニティの構築​

• 2020 年に、コミュニティ Discord サーバーを立ち上げました。 以前は Atom のフォーラム欄がありましたが、よりインフォーマルなメッセージングプラットフォームを用意し、メンテナと Electron 開発者間の議論や一般的なデバッグのヘルプのためのスペースを用意することにしました。
• 2021 年には、@BlackHole1 の協力で Electon China というユーザーグループを設立しました。 このグループは、Electron の英語スペースの外でアイデアを出し合ったり Electron について議論したりする場を提供し、中国の活気ある技術市場からのユーザー増加に貢献しています。 また、npm の中国語ミラーである cnpm で Electron のナイトリーのリリースをサポートして頂いたことにも感謝します。

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

• 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 をコンパイルできるようになりました！

Continuous Factor Authentication​

Continuous Factor Authentication (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 は Electron のリリースプロセスの最初から最後まで、ビルドのキックオフから GitHub と npm へのリリースアセットのアップロードまでを自動化します。
• Trop は、GitHub の PR ラベルに基づいて以前のリリースブランチへのパッチの cherry-pick を試みることで、Electron のバックポートプロセスを自動化します。
• Roller は、Electron の Chromium と Node.js の依存関係のローリングアップグレードを自動化します。
• Cation は、electron/electron の PR のステータスを確認するボットです。

このような小さなボット家族のおかげで、開発者の生産性が大幅に向上しました！

今後の予定は?​

プロジェクトとして次の 10 年を迎えるにあたって、疑問に思われることでしょう。Electron はこれからどうなるのでしょうか？

私たちは、Chromium のリリースケイデンスに同期して 8 週間ごとに Electron の新しいメジャーバージョンをリリースし、エンタープライズ級のアプリケーションの安定性と堅牢性を維持しながら、ウェブプラットフォームと 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 でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細は続きをご覧ください。

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

注目すべき変更​

累積的変更​

• Chromium 110
  • Chrome 110 の新機能
  • Chrome 109 の新機能
  • デベロッパー ツール 110 の新機能
  • デベロッパー ツール 109 の新機能
• Node.js 18.12.1
  • Node 18.12.1 ブログ記事
• V8 11.0

新機能​

• label プロパティを Display オブジェクトに追加しました。 #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 イベント を使用してください。

// Electron 23.0 で削除
-win.on('scroll-touch-begin', scrollTouchBegin)
-win.on('scroll-touch-edge', scrollTouchEdge)
-win.on('scroll-touch-end', scrollTouchEnd)

// こちらに置換
+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 でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細は続きをご覧ください。

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

注目すべき変更​

累積的変更​

• Chromium 108
  • Chrome 108 の新機能
  • Chrome 107 の新機能
  • デベロッパー ツール 108 の新機能
  • デベロッパー ツール 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 サポートが非推奨になります (詳細はこちら)。

Electron 23 以降のメジャーリリースでは、Windows 7/8/8.1 には対応しません。

さらなる注目の変更​

• Linux と Windows で Web Bluetooth の PIN ペアリングに対応しました。 #35416
• 新しい Fuse として 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 イベント を使用してください。

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

// こちらに置換
+ 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 月の 1 ヶ月間休止し、2023 年 1 月から復帰します。 詳細については、12 月の休止のブログ記事 をご覧ください。

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。

Electron の公開タイムラインはこちら になります。

将来の変更の詳細については、予定されている破壊的変更 のページをご参照ください。