今日このごろ、いくつかの有名な Electron アプリに対して最近提出された公開 CVE について Electron チームが警告を受けました。 CVE は、Electron の 2 つの fuse - runAsNode と enableNodeCliInspectArguments - に関連しており、これらのコンポーネントを積極的に無効化しない場合、遠隔攻撃者がこれらのコンポーネントを介して任意のコードを実行できると誤って主張しています。

これらの CVE が誠意を持って提出されたとは考えていません。 まず、この記述は誤りです - この構成では遠隔コード実行は 不可能です。 第二に、これらの CVE で指摘されている企業は、バグ報奨金プログラムを実施しているにもかかわらず、そのバグを通知されていません。 最後に、問題のコンポーネントを無効にするとアプリのセキュリティが強化されることは信じられますが、その CVE が適切な重大度で登録されているとは考えられません。 「Critical」は最も危険な問題に対して予約されたものですが、今回の場合は明らかに当てはまりません。

CVE は誰でも発行できます。 これはソフトウェア業界全体の健全性にとっては良いことですが、一人のセキュリティ研究者が評判を高めるために「CVE を稼ぐ」ことは役立ちません。

とはいえ、恐ろしい「重大」な深刻度を持つ CVE が存在するだけでエンドユーザーの混乱を招く可能性があることは理解しています。そのためプロジェクトとして、問題に対処するためのガイダンスと支援を提供したいと考えています。

どのような影響がありますか?​

CVE をレビューしたところ、Electron チームはこれらの CVE は重大でないと判断しました。

この攻撃者は、ハードウェアに物理的にアクセスするか、完全な遠隔コード実行を実現することによって、マシン上で任意のコマンドを実行できる必要があります。 これは繰り返しとなっています。ここで説明されている脆弱性を利用するには、攻撃者が対象のシステムに既にアクセスできていなければなりません。

例えば、Chrome は 脅威モデルで物理的にローカルな攻撃を考慮していません。

これらの攻撃は Chrome の脅威モデルの範囲外であると考えています。これは、ユーザとしてデバイスにログインした悪意のあるユーザーや、オペレーティングシステムのユーザアカウントの権限でソフトウェアを実行できる悪意のあるユーザーから Chrome (または任意のアプリケーション) を保護する方法がないためです。 このような攻撃者は、実行可能ファイルや DLL を変更したり、PATH などの環境変数を変更したり、構成ファイルを変更したり、ユーザアカウントが所有するデータを読み取ったり、それを攻撃者自身に電子メールで送信したりできます。 このような攻撃者はデバイスを完全に制御できるため、Chrome が施せる対策では防御を完全に保証できません。 この問題は Chrome に特有のものではありません — すべてのアプリケーションは物理的にローカルなユーザを信頼せざるをえません。

CVE に記載されているエクスプロイトにより攻撃者は、影響を受けるようなアプリを、継承された TCC (透明性、同意、制御) の権限を持つ汎用 Node.js プロセスとして使用できるようになります。 したがって、たとえばアプリにアドレス帳へのアクセスが許可されている場合、攻撃者はそのアドレス帳へのアクセスを継承するアプリを Node.js として実行し、任意のコードを実行できます。 これは一般に「Living Off The Land」攻撃として知られています。 攻撃者は通常、PowerShell や Bash などのツールを用いて任意コード実行をします。

影響はありますか?​

デフォルトでは、リリースされている全バージョンの Electron は runAsNode と enableNodeCliInspectArguments の機能が有効です。 Electron Fuses のドキュメント で説明されているように、これらをオフにしていない場合、アプリが「Living Off the Land」攻撃に利用される危険性は同様に高くなります。 繰り返し強調しますが、攻撃者は 既に 被害者のマシン上でコードとプログラムを実行できている必要があります。

緩和策​

この問題を軽減する最も簡単な方法は、あなたの Electron アプリの runAsNode の Fuse を無効化することです。 runAsNode ヒューズは、ELECTRON_RUN_AS_NODE 環境変数が尊重されるかどうかを切り替えます。 これらのヒューズを切り替える方法については、Electron Fuses のドキュメント をご参照ください。

注意としてこの Fuse が無効になっている場合、メインプロセスの process.fork はこの環境変数に依存して動作するため、期待通りに動作しなくなることがあります。 代わりに、ユーティリティプロセス を使用することを推奨します。これは、スタンドアロンの Node.js プロセス (SQLite サーバーのプロセスや同様の場合) が必要な多くのユースケースで機能します。

Electron アプリで推奨されるセキュリティのベストプラクティスの詳細については、セキュリティチェックリスト をご覧ください。

Electron 28.0.0 がリリースされました! これには Chromium 120.0.6099.56、V8 12.0、Node.js 18.18.2 へのアップグレードが含まれています。

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

何かフィードバックがあれば、Twitter や Mastodon で共有したり、コミュニティの Discord に参加してみましょう! バグや機能の要望は Electron の Issue トラッカー で報告できます。

注目すべき変更​

ハイライト​

• ECMAScript モジュール、略して ESM のサポートを実装しました (ECMAScript モジュールとは何かですって？ こちらで詳しく学べます。 これは Electron での ESM サポートだけでなく、UtilityProcess API のエントリポイントなどの領域も含まれます。 詳細については 私たちの ESM の ドキュメント をご参照ください。
• 加えて Electron Forge は、Electron 自体での ESM サポートだけでなく Electron アプリケーションのパッケージ化、ビルド、開発においても ESM をサポートしています。 このサポートは Forge v7.0.0 以降となります。

累積的変更​

• Chromium 120.0.6099.56
  • Chrome 119 と デベロッパーツール 119 の新機能
  • Chrome 120 と デベロッパーツール 120 の新機能
• Node 18.18.2
  • Node 18.18.0 ノート
  • Node 18.18.1 ノート
  • Node 18.18.2 ノート
• V8 12.0

新機能​

• ESM サポートを有効化しました。 #37535
  • 詳細については、ESM の ドキュメント をご参照ください。
• UtilityProcess API に ESM エントリポイントを追加しました。 #40047
• display オブジェクトに、detected、maximumCursorSize、 nativeOrigin を含むいくつかのプロパティを追加しました。 #40554
• Linux で ELECTRON_OZONE_PLATFORM_HINT 環境変数のサポートを追加しました。 #39792

破壊的変更​

動作変更：WebContents.backgroundThrottling を false にすると、ホストの WebContents 内のすべての BrowserWindow に影響します​

WebContents.backgroundThrottling を false に設定すると、BrowserWindow によって表示されるすべての WebContents でのフレーム抑制が無効になります。

削除: BrowserWindow.setTrafficLightPosition(position)​

BrowserWindow.setTrafficLightPosition(position) は削除されたので、代わりに BrowserWindow.setWindowButtonPosition(position) API を使用してください。こちらは、デフォルトの位置へリセットする際に { x: 0, y: 0 } ではなく null を受け取るようになっています。

// Electron 28 で非推奨
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 28 で削除
const pos = win.getTrafficLightPosition();
if (pos.x === 0 && pos.y === 0) {
  // カスタム位置が無い時。
}

// こちらに置き換えてください
const ret = win.getWindowButtonPosition();
if (ret === null) {
  // カスタム位置が無い時。
}

削除: ipcRenderer.sendTo()​

ipcRenderer.sendTo() API は削除されました。 これはレンダラー間で MessageChannel を設置するように置き換える必要があります。

IpcRendererEvent の senderId と senderIsMainFrame のプロパティも削除されました。

削除: app.runningUnderRosettaTranslation​

app.runningUnderRosettaTranslation プロパティは削除されました。 代わりに app.runningUnderARM64Translation を使用してください。

// 削除されました
console.log(app.runningUnderRosettaTranslation);
// こちらで置き換えてください
console.log(app.runningUnderARM64Translation);

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

プロジェクトの サポートポリシー に則り、Electron 25.x.y はサポート終了を迎えました。 開発者とアプリケーションは新しいバージョンの Electron にアップグレードすることを推奨します。

次回予告​

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

Electron の公開タイムラインはこちらで ご覧いただけます。

今後の変更についての詳細は、予定されている破壊的変更 のページをご覧ください。

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) をフォローしてください!