メインコンテンツへ飛ぶ

Electron 32.0.0

· 読むのにかかる時間 1 分

Electron 32.0.0 がリリースされました! これには Chromium 128.0.6613.36、V8 12.8、Node 20.16.0 へのアップグレードが含まれています。


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

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

注目すべき変更

ハイライト

  • ドキュメントに新しく API バージョン履歴を追加しました。これは、Google Summer of Code の一環として @piotrpdev によって作成された機能です。 詳細については、こちらのブログ記事 をご覧ください。 #42982
  • ウェブの File API から非標準の File.path 拡張を削除しました。 #42053
  • ブロックされたパス内のファイルまたはディレクトリを開こうとしたときに、ウェブの ファイル システム API が失敗する流れを上流と整合させました。 #42993
  • webcontents.navigationHistory に、次の既存のナビゲーション関連 API を追加しました: canGoBack, goBack, canGoForward, goForward, canGoToOffset, goToOffset, clear。 以前のナビゲーション API は非推奨になりました。 #41752

累積的変更

Electron 32 では、Chromium は 126.0.6478.36 から 128.0.6613.36 へ、Node は 20.14.0 から 20.16.0 へ、V8 は 12.6 から 12.8 へとアップグレードしています。

新機能

  • ユーティリティプロセスから開始された認証の要求に、app モジュールの 'login' イベントを介して応答するためのサポートが追加されました。 #43317
  • CPUUsage 構造体に cumulativeCPUUsage プロパティを追加しました。このプロパティは、プロセスの起動以降に使用された CPU 時間の累計秒数を返します。 #41819
  • webContents.navigationHistory に、次の既存のナビゲーション関連 API を追加しました: canGoBack, goBack, canGoForward, goForward, canGoToOffset, goToOffset, clear#41752
  • WebContentsView を既存の webContents オブジェクトを受け入れるように拡張しました。 #42086
  • nativeTheme に新しいプロパティ prefersReducedTransparency を追加しました。これは、ユーザーがシステムのアクセシビリティ設定を介して OS レベルの透過度を下げることを選択したかどうかを示します。 #43137
  • ブロックされたパスでファイルまたはディレクトリを開こうとしたときに、ファイルシステムアクセス API が失敗する流れを上流と整合させました。 #42993
  • Linux でウインドウコントロールオーバーレイ API を使えるようにしました。 #42681
  • ネットワークリクエストで zstd 圧縮を使えるようにしました。 #43300

破壊的変更

削除: File.path

ウェブの File オブジェクトの非標準の path プロパティは、レンダラー内ですべてを実行するのが一般的だった時代に、ネイティブのファイルを操作する便利な方法として Electron の初期バージョンで追加されました。 ただし、これは標準からの逸脱であり軽微なセキュリティリスクも伴うため、Electron 32.0 以降では webUtils.getPathForFile メソッドに置き換えられました。

// 以前 (レンダラー)
const file = document.querySelector('input[type=file]');
alert(`Uploaded file path was: ${file.path}`);
// これから (レンダラー)
const file = document.querySelector('input[type=file]');
electron.showFilePath(file);

// これから (プリロード)
const { contextBridge, webUtils } = require('electron');

contextBridge.exposeInMainWorld('electron', {
showFilePath(file) {
// できればウェブコンテンツへの完全なファイルパスを
// 公開しないことを推奨します。
const path = webUtils.getPathForFile(file);
alert(`Uploaded file path was: ${path}`);
},
});

非推奨: WebContentsclearHistory, canGoBack, goBack, canGoForward, goForward, goToIndex, canGoToOffset, goToOffset

WebContents インスタンスのナビゲーション関連の API が非推奨になりました。 これらの API は、ナビゲーション履歴を管理するための、より構造化された直感的なインターフェースを提供するために、WebContentsnavigationHistory プロパティへ移動されました。

// 非推奨
win.webContents.clearHistory();
win.webContents.canGoBack();
win.webContents.goBack();
win.webContents.canGoForward();
win.webContents.goForward();
win.webContents.goToIndex(index);
win.webContents.canGoToOffset();
win.webContents.goToOffset(index);

// こちらで置き換えてください
win.webContents.navigationHistory.clear();
win.webContents.navigationHistory.canGoBack();
win.webContents.navigationHistory.goBack();
win.webContents.navigationHistory.canGoForward();
win.webContents.navigationHistory.goForward();
win.webContents.navigationHistory.canGoToOffset();
win.webContents.navigationHistory.goToOffset(index);

Behavior changed: Directory databases in userData will be deleted

If you have a directory called databases in the directory returned by app.getPath('userData'), it will be deleted when Electron 32 is first run. The databases directory was used by WebSQL, which was removed in Electron 31. Chromium now performs a cleanup that deletes this directory. See issue #45396.

29.x.y サポートの終了

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

E32 (2024 年 8 月)E33 (2024 年 10 月)E34 (2025 年 1 月)
32.x.y33.x.y34.x.y
31.x.y32.x.y33.x.y
30.x.y31.x.y32.x.y

次回予告

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

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

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

Electron 31.0.0

· 読むのにかかる時間 1 分

Electron 31.0.0 がリリースされました! これには Chromium 126.0.6478.36、V8 12.6、Node 20.14.0 へのアップグレードが含まれています。


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

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

注目すべき変更

ハイライト

  • WebContentsView を既存の webContents オブジェクトを受け入れるように拡張しました。 #42319
  • NODE_EXTRA_CA_CERTS のサポートを追加しました。 #41689
  • window.flashFrame(bool) を macOS 上で持続的に点滅するように更新しました。 #41391
  • WebSQL のサポートを削除しました #41868
  • nativeImage.toDataURL が PNG 色空間を保つようにしました #41610
  • webContents.setWindowOpenHandler が手動作成した BrowserWindow をサポートするように拡張しました。 #41432

累積的変更

Electron 31 では、Chromium は 124.0.6367.49 から 126.0.6478.36 へ、Node は 20.11.1 から 20.14.0 へ、V8 は 12.4 から 12.6 へとアップグレードしています。

新機能

  • SessionclearData メソッドを追加しました。 #40983
    • Session.clearData API に options パラメーターを追加しました。 #41355
  • navigator.serial にサービスクラス ID によって要求される Bluetooth ポートのサポートを追加しました。 #41638
  • Node の NODE_EXTRA_CA_CERTS 環境変数のサポートを追加しました。 #41689
  • webContents.setWindowOpenHandler が手動作成した BrowserWindow をサポートするように拡張しました。 #41432
  • ウェブ標準の ファイルシステム API のサポートを実装しました。 #41419
  • WebContentsView を既存の WebContents インスタンスを受け入れるように拡張しました。 #42319
  • webContents API に新しくインスタンスプロパティ navigationHistorynavigationHistory.getEntryAtIndex メソッドを追加しました。これによりアプリケーションがブラウズ履歴内の任意のナビゲーションエントリの URL とタイトルを取得できるようになります。 #41577 (及び 29, 30)

破壊的変更

削除:WebSQL のサポート

Chromium は WebSQL の上流サポートを削除し、Android のみに移行しました。 詳細は Chromium の削除する意図についての議論 をご参照ください。

動作変更: nativeImage.toDataURL が PNG 色空間を保つようにしました

PNG デコーダの実装が色空間データを保持するように変更されました。 この関数から返される符号化されたデータは元と一致するようになります。

詳細は crbug.com/332584706 をご参照ください。

動作変更: win.flashFrame(bool) を macOS 上で持続的に点滅するようにしました

これにより、Windows および Linux と同等の動作になります。 以前の動作: 最初の flashFrame(true) は Dock のアイコンを 1 回バウンスするだけ (NSInformationalRequest レベルを使用する場合) で、flashFrame(false) は何も行いません。 新しい動作: flashFrame(false) が呼び出されるまで、持続的に点滅します。 これは代わりに NSCriticalRequest レベルを使用しています。 NSInformationalRequest を明示的に使用してこれまで通り一度だけの Dock のアイコンをバウンスさせたい場合は、dock.bounce('informational') を使用できます。

28.x.y サポートの終了

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

E31 (2024 年 6 月)E32 (2024 年 8 月)E33 (2024 年 10 月)
31.x.y32.x.y33.x.y
30.x.y31.x.y32.x.y
28.x.y29.x.y31.x.y

次回予告

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

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

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

Electron 30.0.0

· 読むのにかかる時間 1 分

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


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

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

注目すべき変更

ハイライト

  • ASAR 整合性の fuse が Windows でサポートされました (#40504)
    • 正しく設定されていない場合、ASAR 整合性が有効の既存のアプリは Windows 上で動作しない可能性があります。 Electron のパッケージ化ツールを使用しているアプリは、@electron/packager@18.3.1 または @electron/forge@7.4.0 にアップグレードしてください。
    • 詳細については私たちの ASAR 整合性のチュートリアル をご覧ください。
  • Added WebContentsView and BaseWindow main process modules, deprecating & replacing BrowserView (#35658). Learn more about how to migrate from BrowserView to WebContentsView in this blog post.
    • BrowserViewWebContentsView の上のシムとなり、古い実装は削除されました。
    • 新しい WebContentsView API と他の類似 API との比較については、私たちの Web 埋め込みドキュメント をご参照ください。
  • ファイルシステム API のサポートを実装しました (#41827)

累積的変更

Electron 30 では、122.0.6261.39 から 124.0.6367.49 へ、Node は 20.9.2 から 20.11.1 へ、V8 は 12.2 から 12.4 へとアップグレードしています。

新機能

  • Webview に transparent のウェブ環境設定を追加しました。 (#40301)
  • webContents API に新しくインスタンスプロパティ navigationHistorynavigationHistory.getEntryAtIndex メソッドを追加しました。これによりアプリケーションがブラウズ履歴内の任意のナビゲーションエントリの URL とタイトルを取得できるようになります。 (#41662)
  • 新しく BrowserWindow.isOccluded() メソッドを追加しました。これによりアプリが覆い隠されている状態を確認できるようになります。 (#38982)
  • ユーティリティプロセスから net モジュールを使用して行われたリクエストに対するプロキシ構成サポートを追加しました。 (#41417)
  • navigator.serial にサービスクラス ID によって要求される Bluetooth ポートのサポートを追加しました。 (#41734)
  • Node.js の NODE_EXTRA_CA_CERTS CLI フラグのサポートを追加しました。 (#41822)

破壊的変更

動作変更: クロスオリジンの iframe が権限ポリシーを用いて機能にアクセスするようになりました

クロスオリジンの iframe にアクセスするには、特定の iframe で利用可能な機能を allow 属性を介して指定しなければなりません。

詳細は ドキュメント をご参照ください。

削除: --disable-color-correct-rendering コマンドラインスイッチ

このスイッチは正式にドキュメント化されたことはありませんが、削除したことをここに注記しておきます。 Chromium 自体が色空間のサポートを強化したため、このフラグは必要なくなります。

動作変更: macOS での BrowserView.setAutoResize の動作

Electron 30 では、BrowserView は新しい WebContentsView API のラッパーになりました。

以前の BrowserView API の setAutoResize 関数は、macOS では autoresizing で、Windows と Linux ではカスタムアルゴリズムによって支えていました。 BrowserView をウインドウ全体に表示するなどの単純な使用例では、これら 2 つのアプローチの動作は同じでした。 ただしより高度なケースでは、Windows および Linux のカスタムサイズ変更アルゴリズムが macOS の自動サイズ変更 API の動作と完全に一致しませんでした。そのめ、BrowserView の自動サイズ変更は macOS 上では他のプラットフォームとは異なる動作でした。 この自動サイズ変更の動作がすべてのプラットフォーム間で標準化されました。

もしあなたのアプリが BrowserView をウィンドウ全体に表示するよりも複雑な操作を BrowserView.setAutoResize で行っていたのならば、macOS でのこの動作の違いに対処するカスタムロジックを既に用意していたことでしょう。 その場合、Electron 30 からは自動サイズ変更の動作が一貫しているため、そのロジックは必要なくなります。

削除: WebContentscontext-menu にある params.inputFormType プロパティ

WebContentscontext-menu イベント内の params オブジェクトにある inputFormType プロパティを削除しました。 代わりに新しい formControlType プロパティを使用してください。

削除: process.getIOCounters()

Chromium はこの情報へのアクセスを削除しました。

27.x.y サポートの終了

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

E30 (Apr'24)E31 (2024 年 6 月)E32 (2024 年 8 月)
30.x.y31.x.y32.x.y
29.x.y30.x.y31.x.y
28.x.y29.x.y30.x.y

次回予告

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

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

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

Google Summer of Code 2024

· 読むのにかかる時間 1 分

Electron が第 20 回 Google Summer of Code (GSoC) 2024 のメンター組織として承認されたことをお知らせします! Google Summer of Code は、オープンソースソフトウェア開発に新たな貢献者を呼び込むことに重点を置いた国際プログラムです。

プログラムの詳細については、Google の Summer of Code のホームページ をご覧ください。

私たちについて

Electron は、ウェブ技術を用いたクロスプラットフォームのデスクトップアプリケーションを構築する JavaScript フレームワークです。 Electron フレームワークのコアは ChromiumNode.js で構築されたコンパイル済みバイナリ実行形式であり、主に C++ で書かれています。

Electron のコア以外にも以下のように、Electron 組織の維持に役立つ様々なプロジェクトに取り組んでいます。

Summer of Code の貢献者の方は、github.com/electron 傘下の多くのプロジェクトのうちの 1 つで、Electron のコアの貢献者の一部と協力して頂きます。

応募する前に

Electron にあまり詳しくない方は、ドキュメント を読んだり、Electron Fiddle のサンプルを試してみることをお勧めします。

Electron アプリの頒布形式の詳細について学ぶには、サンプルアプリケーションを作成して Electron Forge を試すのもよいでしょう。

npm init electron-app@latest my-app

コードに少し慣れたら、Electron の Discord サーバー での会話にご参加ください。

info

Google Summer of Code に初めて参加する方やオープンソース全般に馴染みがない方は、コミュニティに参加する前に、まず Google の 貢献者ガイド を読むことをお勧めします。

計画書の執筆

Electron との共同開発に興味を持てましたか? まずは、私たちが用意した 7 つのプロジェクトアイデア案 をご覧ください。 掲載されているアイデアは、すべて企画のために現在公開中のものです。

この他に検討して欲しいアイデアをお持ちですか? 提案プロジェクトのリストにない新しいアイデアも歓迎しますが、アプローチを十分に概説し、かつ詳細に説明するようにしてください。 あまり自信がないのであれば、リストのアイデアに従うことをお勧めします。

応募には以下のものがあるとよいでしょう。

  • 計画書: この夏のプログラムの間に達成する目標の計画を詳細に記した文書。
  • 開発者としての経歴。 履歴書がある場合は、コピーを添付してください。 なければ、過去の技術経験についてお教えください。
    • 特定の分野での経験不足で不合格となることはありませんが、私たちメンターがあなたを最大限にサポートし、あなたの夏のプロジェクトが成功するよう計画を立てるのに役立ちます。

Electron の応募で提出する一式の詳細なガイドはこちらです。 計画書は Google Summer of Code ポータルに直接提出してください。 注意として、申請ポータルから送信せずに Electron チームへ電子メールで送信した計画書は、最終提出物とみなされません。

計画書についてさらに詳しいガイダンスが必要な場合や、何を書き込めばよいかわからない場合は、Google Summer of Code 公式の計画書作成アドバイス に従うこともお勧めします。

応募開始は 2024 年 3 月 18 日、締め切りは 2024 年 4 月 2 日 です。

info

2022 年の Google Summer of Code では、インターンの @aryanshridhar さんには素晴らしい働きをして頂きました。 Aryan さんが夏に Electron で取り組んだことを確認したい方は、2022 GSoC プログラムのアーカイブ から彼のレポートを閲覧できます。

質問?

ブログ記事で取り上げられていない質問や計画書の執筆に関するお問い合わせは、summer-of-code@electronjs.org までメールしていただくか、GSoC FAQ をご確認ください。

リソース

Electron 29.0.0

· 読むのにかかる時間 1 分

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


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

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

注目すべき変更

ハイライト

  • 新しいトップレベルの webUtils モジュールを追加しました。これは Web API のオブジェクトと対話するユーティリティレイヤーを提供するレンダラープロセスのモジュールです。 このモジュールで最初に利用可能な API は webUtils.getPathForFile です。 Electron の以前の File.path 拡張は Web 標準から逸脱していましたが、この新しい API は現在の Web 標準の動作に沿ったものになっています。

累積的変更

Electron 29 では、120.0.6099.56 から 122.0.6261.39 へ、Node は 18.18.2 から 20.9.0 へ、V8 は 12.0 から 12.2 へとアップグレードしています。

新機能

  • Web API のオブジェクトと対話するユーティリティレイヤーとして webUtils モジュールを追加しました。これは File.path 拡張を置き換えるものです。 #38776
  • ユーティリティプロセスnet モジュールを追加しました。 #40890
  • 新しい Electron FusegrantFileProtocolExtraPrivileges を追加しました。これは、file:// プロトコルを Chromium と一致するよりセキュアな動作に制限するものです。 #40372
  • カスタムスキームで V8 コードのキャッシュを許可するためのオプションを protocol.registerSchemesAsPrivileged に追加しました。 #40544
  • app.{set|get}LoginItemSettings(settings) を macOS 13.0 以降で Apple 推奨の新しい基盤フレームワークを使用するように移行しました。 #37244

破壊的変更

動作変更:ipcRenderercontextBridge を越えて送信できなくなりました。

ipcRenderer モジュール全体をオブジェクトとして contextBridge 経由で送信しようとすると、ブリッジの受信側には空のオブジェクトが生成されるようになりました。 この変更は、セキュリティの落とし穴を撤去/軽減するために行われました。 ipcRenderer やそのメソッドをブリッジ越しに直接公開してはいけません。 代わりに、以下のような安全なラッパーを用意してください。

contextBridge.exposeInMainWorld('app', {
onEvent: (cb) => ipcRenderer.on('foo', (e, ...args) => cb(args)),
});

削除: apprenderer-process-crashed イベント

app での renderer-process-crashed イベントは削除されました。 代わりに新しいイベントである render-process-gone を使用してください。

// 削除済み
app.on('renderer-process-crashed', (event, webContents, killed) => {
/* ... */
});

// こちらで置き換えてください
app.on('render-process-gone', (event, webContents, details) => {
/* ... */
});

削除: WebContents<webview> crashed イベント

WebContents<webview>crashed イベントは削除されました。 代わりに新しいイベントである render-process-gone を使用してください。

// 削除済み
win.webContents.on('crashed', (event, killed) => {
/* ... */
});
webview.addEventListener('crashed', (event) => {
/* ... */
});

// こちらに置き換えてください
win.webContents.on('render-process-gone', (event, details) => {
/* ... */
});
webview.addEventListener('render-process-gone', (event) => {
/* ... */
});

削除: appgpu-process-crashed イベント

appgpu-process-crashed イベントは削除されました。 代わりに新しいイベントである child-process-gone を使用してください。

// 削除済み
app.on('gpu-process-crashed', (event, killed) => {
/* ... */
});

// こちらに置き換えてください
app.on('child-process-gone', (event, details) => {
/* ... */
});

26.x.y サポートの終了

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

E29 (Feb'24)E30 (Apr'24)E31 (2024 年 6 月)
29.x.y30.x.y31.x.y
28.x.y29.x.y30.x.y
27.x.y28.x.y29.x.y

次回予告

この度 Electron がコミュニティの Request for Comments (RFC) のプロセスを追加したことはご存知でしょうか? フレームワークに機能を追加したい場合、RFC はその設計においてメンテナとの対話を始める有用なツールとなります。 プルリクエストで議論されている今後の変更も確認できます。 詳細については、electron/rfcs の紹介 のブログ記事をご覧いただくか、electron/rfcs リポジトリの README を直接ご確認ください。

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

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

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

electron/rfcs の紹介

· 読むのにかかる時間 1 分

Electron の API ワーキング グループ は、Electron のコアへのより大きな変更を支援するために、オープンな Requests for Comments (RFC) プロセスを採用しようとしています。

なぜ RFC なのでしょうか?

要するに、Electron のコアへの重要な変更を実装するプロセスをスムーズにしたいのです。

現在、新しいコードの変更は主に GitHub の Issue とプルリクエストを通じて議論されています。 Electron のほとんどの変更においては、これは良いシステムです。 多くのバグ修正、ドキュメントの変更、さらには新機能も、標準の GitHub フローを介せば非同期的にレビューおよびマージできるほど簡単です。

より重大な変更—たとえば大規模な API サーフェスや、Electron アプリの大部分に影響する重大な変更などの場合、コードの大部分が記述される前のアイデア段階でレビューを行うほうが合理的です。

このプロセスは一般公開されるように設計すべきです。そうすることで、Electron に導入される前に、オープンソースコミュニティ全体が潜在的な変更についてフィードバックを提供しやすくなります。

どのように動作するのですか?

RFC 全体のプロセスは、GitHub 上の electron/rfcs リポジトリに保管されます。 プロセスの手順は、リポジトリの README で詳しく説明しています。

簡単に言うと、electron/rfcs リポジトリに PR が作成されると、RFC は 提唱 になります。 提唱の RFC は次のように遷移します。

  • アクティブ は、PR がリポジトリの main ブランチにマージされた場合になります。つまり、Electron のメンテナが electron/electron での実装に同意できることを意味します。
  • 拒絶 は PR が最終的に拒否された場合になります。
info

RFC が アクティブ になるには、PR が少なくとも 2 人の API ワーキンググループのメンバーによって承認されなければなりません。 マージ前に、RFC は WG メンバーの 3 分の 2 以上の定足数によって開かれた会議で同期的に提示され、全会一致で承認される必要があります。 合意に達した場合、1 か月の最終コメント期間が開始され、その後 PR がマージされます。

実装が electron/electron にマージされたとき、アクティブな RFC は 完了 になります。

誰が参加できますか?

Electron コミュニティの誰もが、RFC を提出したり、electron/rfcs リポジトリにフィードバックを残したりできます!

私たちは、このプロセスを双方向の対話にして、コミュニティの参加を奨励し、将来これらの API を使用する可能性のある Electron アプリからの多様な意見を得たいと考えていました。 現在提唱状態の RFC にフィードバックを残したい方向けに、Electron のメンテナが既に作成したいくつかの RFC を下記します。

クレジット

Electron の RFC プロセスは、多くの確立されたオープンソースの RFC プロセスに基づいてモデル化されました。 多くのアイデアやコピーライティングの主要部分のインスピレーションは、以下から得ました。

"runAsNode" の CVE に関する声明

· 読むのにかかる時間 1 分

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

これらの 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 は runAsNodeenableNodeCliInspectArguments の機能が有効です。 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

· 読むのにかかる時間 1 分

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

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

注目すべき変更

ハイライト

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

累積的変更

新機能

  • ESM サポートを有効化しました。 #37535
  • UtilityProcess API に ESM エントリポイントを追加しました。 #40047
  • display オブジェクトに、detectedmaximumCursorSizenativeOrigin を含むいくつかのプロパティを追加しました。 #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 を設置するように置き換える必要があります。

IpcRendererEventsenderIdsenderIsMainFrame のプロパティも削除されました。

削除: app.runningUnderRosettaTranslation

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

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

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

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

E28 (Dec'23)E29 (Feb'24)E30 (Apr'24)
28.x.y29.x.y30.x.y
27.x.y28.x.y29.x.y
26.x.y27.x.y28.x.y

次回予告

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

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

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

エコシステム 2023 総括

· 読むのにかかる時間 1 分

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-prebuiltelectron-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 ステップの並列化をテストしてきました。これで同一プラットフォーム向けに複数のターゲットをビルドするときの速度が向上しているとわかるでしょう!
ありがとうございます!

🙇 Forge の設定で GCS パブリッシャーと ESM の両方のサポートに貢献していただいた mahnunchik** さんに多大な感謝を送ります!

静的ストレージの自動更新の改善

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}`,
},
});
参考リンク

📦 もっと知りたいですか? 詳細なガイドにつきましては、Forge の自動更新のドキュメント をご参照ください。

@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/packager リポジトリを非公開にしてしまいました。これにより、GitHub のスターの数を消えるという不幸な副作用がありました (消える前は 9000 以上でした)。 Packager をいつもご利用の方は、⭐ スター ⭐ していただけると幸いです!

@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 の開発体験をさらに向上させる方法について考えていることでしょう。

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

12 月の安息月 (Dec'23)

· 読むのにかかる時間 1 分

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 年にまたお会いしましょう!