メインコンテンツへ飛ぶ

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

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


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

注目すべき変更

新機能

  • Windows に没入型ダークモードを追加しました。 #34549
  • パネルのような動作のサポートを追加しました。 フルスクリーンにしたアプリの上にウインドウを浮かべることができます。 #34665
  • Windows 11 でよりネイティブに見えるように Windows コントロールオーバーレイボタンを更新しました。 #34888
  • nodeIntegration: truesandbox: false が指定されない限り、デフォルトでレンダラーがサンドボックス化されるようになりました。 #35125
  • nan でネイティブモジュールをビルドする際のセーフガードを追加しました。 #35160

累積的変更

破壊的な API の変更

以下は、Electron 20 での破壊的変更点です。 これらの変更と将来の変更の詳細については、予定されている破壊的変更 のページを参照してください。

V8 メモリケージの有効化

Electron 20 では V8 のサンドボックス化ポインタ を有効にします。これは Chrome の Chrome 103 での同様の決定 に従ったものです。 これはネイティブモジュールにいくつかの影響を与えます。 この機能には、パフォーマンスやセキュリティ上の利点がありますが、外部 ("ヒープ外") のメモリを指す ArrayBuffer の使用など、ネイティブモジュールに新しい制限を課すことになります。 詳細は ブログ記事 をご参照ください。

省略値の変更: nodeIntegration: true 指定が無いレンダラーはデフォルトでサンドボックス化されます。

これまで、プリロードスクリプトを指定したレンダラーはデフォルトでサンドボックス化されていませんでした。 つまり、プリロードスクリプトはデフォルトで Node.js へのアクセス権を持っていたということです。 Electron 20 では、この省略値が変更されました。 Electron 20 以降、レンダラーに nodeIntegration: true または sandbox: false が指定されていない限り、デフォルトでサンドボックス化されます。

プリロードスクリプトが Node に依存していない場合、対応は不要です。 プリロードスクリプトが Node に依存している場合は、リファクタしてレンダラーから Node の使用部分を削除するか、そういったレンダラーでは sandbox: false を明示的に指定してください。

修正: nan ネイティブモジュールでの自発的クラッシュ

Electron 20 では、ネイティブモジュールに関する 2 つの項目を変更しました。

  1. V8 ヘッダはデフォルトで c++17 を使用するようになりました。 このフラグは electron-rebuild で付与されます。
  2. nan に依存しているネイティブモジュールでインクルードファイルが見つからないと、自発的にクラッシュする問題を修正しました。

最大限安定させるために、ネイティブモジュール、特に nan に依存するモジュールをリビルドする際には、node-gyp>=8.4.0 と electron-rebuild>=3.2.9 の使用を推奨します。 詳細は electron の #35160 と node-gyp の #2497 を参照してください。

削除: Linux 上の .skipTaskbar

X11 では、 skipTaskbar_NET_WM_STATE_SKIP_TASKBAR メッセージを X11 ウインドウマネージャーに送信します。 Wayland には同等のものがなく、また既知の回避策にも許容できないトレードオフがあるため (例えば GNOME の Window.is_skip_taskbar はアンセーフモードが必要)、Electron はこの機能を Linux でサポートできません。

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

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

E18 (Mar'22)E19 (May'22)E20 (Aug'22)E21 (Sep'22)E22 (Dec'22)
18.x.y19.x.y20.x.y21.x.y22.x.y
17.x.y18.x.y19.x.y20.x.y21.x.y
16.x.y17.x.y18.x.y19.x.y20.x.y
15.x.y--------

次回予告

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。 リリース日について約束しないように注意していますが、予定では 2 か月ごとに新しいメジャーバージョンの Electron を、各コンポーネントの新しいバージョンに対してリリースします。

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

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

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

Electron 20 以降では V8 メモリケージが有効になり、一部のネイティブモジュールに影響を及ぼします。


Electron 20 では、Electron にて V8 のサンドボックス化ポインタ が有効になります。これは Chrome の Chrome 103 での同様の決定 に従ったものです。 これはネイティブモジュールにいくつかの影響を与えます。 また、以前には関連する技術である ポインタ圧縮 を Electron 14 で有効にしていました。 当時はあまり話題になりませんでしたが、ポインタ圧縮は V8 の最大ヒープサイズに影響を及ぼします。

この 2 つの技術を有効にすることで、セキュリティ、パフォーマンス、メモリ使用量に大きなメリットがあります。 しかし、それらを有効化するにあたっていくつかの欠点もあります。

サンドボックス化ポインタを有効にする主な欠点は、外部 ("ヒープ外") のメモリを指す ArrayBuffer が許可されなくなる ことです。 つまり、V8 でこの機能に依存しているネイティブモジュールは、Electron 20 以降でも引き続き動作するようにリファクタする必要があります。

ポインタ圧縮を有効にする主な欠点は、V8 ヒープのサイズが最大 4GB に制限される ことです。 正確な詳細は少し複雑です。例えば、ArrayBuffer は V8 ヒープの他の部分とは別にカウントされますが、それ自体の制限 はあります。

Electron のアップグレードのワーキンググループ は、ポインタ圧縮と V8 メモリケージのメリットはデメリットを上回ると考えています。 主な理由は次の 3 つです。

  1. Electron が Chromium に近づきます。 V8 の設定など複雑な内部の詳細について Electron が Chromium からあまる乖離しなければ、誤ってバグやセキュリティ上の脆弱性を導入する可能性は低くなります。 Chromium のセキュリティチームは侮れない素晴らしさであり、彼らの成果を確実に生かしたいのです。 さらに、あるバグが Chromium で使用されていない設定にしか影響しない場合、そのバグ修正は Chromium チームにとって優先されないでしょう。
  2. パフォーマンスが改善します。 ポインタ圧縮により、V8 ヒープサイズを最大 40% 削減し CPU と GC の性能を 5%-10% 向上させます。 Electron アプリケーションの大部分は、4GB のヒープサイズ制限にぶつかることはなく、外部バッファを必要とするネイティブモジュールも使用しないため、これらは性能面で大きなメリットとなります。
  3. よりセキュアになります。 Electron アプリの中には信頼できない JavaScript を実行しているものがあります (できれば セキュリティに関する推奨事項 に従ってください!)。そういったアプリでは V8 メモリケージを有効にすることで、V8 の厄介な脆弱性を持つ巨大クラスからそれらを保護できます。

最後に、どうしても大きなヒープサイズが必要なアプリのための回避策をご紹介します。 例えば、ポインタ圧縮を無効にしてビルドしたアプリに Node.js のコピーを同梱し、メモリ負荷の大きい作業を子プロセスに移行させることが可能です。 またやや複雑ではありますが、ポインタ圧縮を無効にしたカスタム版の Electron を作成することも可能です。その場合、特定のユースケースに対して別のトレードオフが必要になります。 そして最後に、そう遠くない将来、wasm64 により WebAssembly で構築されたアプリが 4GB を超える巨大なメモリをウェブと Electron の両方で利用できるようになる予定です。


FAQ

アプリがこの変更の影響を受けるかどうかは、どうすればわかりますか?

Electron 20 以降で外部メモリを ArrayBuffer でラップしようとすると、実行時にクラッシュします。

アプリでネイティブ Node モジュールを使用していない場合は安全です。純粋な JS からこのクラッシュを引き起こす方法はありません。 この変更は、V8 ヒープ外でのメモリ割り当て (例えば mallocnew の使用) を行い、その外部メモリを ArrayBuffer でラップしているネイティブ Node モジュールにのみ影響します。 これはかなり稀なユースケースですが、一部のモジュールではこの手法が使われており、そのようなモジュールは Electron 20 以降と互換性を持たせるためのリファクタが必要です。

どうすればアプリが使用している V8 ヒープメモリの量を測定して、4GB の制限に近づいているか調べられますか?

レンダラープロセスでは、performance.memory.usedJSHeapSize を使用すると V8 ヒープの使用量をバイト単位で返します。 メインプロセスでは、同じように process.memoryUsage().heapUsed を利用できます。

V8 メモリケージとは何ですか?

ドキュメントによっては「V8 サンドボックス」と呼んでいますが、この用語は Chromium で起こる 他の種類のサンドボックス と混同しやすいので、「メモリケージ」という用語にしておこうと思います。

V8 のエクスプロイトの多くは、以下のようなものです。

  1. V8 の JIT エンジンのバグを見つけます。 JIT エンジンはコードを解析し、実行時の遅い型チェックを省略して高速なマシンコードを生成します。 時々この解析を間違ってしまう、論理エラーが起こります。本当は必要な型チェックを省略してしまうのです。例えば、x が文字列だと考えていたのに実際はオブジェクトだったということが起こります。
  2. この混乱を悪用して、例えば ArrayBuffer の先頭へのポインタなど、V8 ヒープ内のメモリの一部を上書きします。
  3. これで好きな場所を指す ArrayBuffer ができたので、プロセス中の 任意の メモリ、たとえ V8 が通常アクセスできないメモリでも読み書きできてしまいます。

V8 メモリケージは、このような攻撃を無条件に防ぐために考案された技術です。 これを実現する方法は、V8 ヒープにポインターを保存しない ことです。 代わりに、V8 ヒープ内の他のメモリへの参照はすべて、ある予約領域の先頭からのオフセットとして格納されます。 このため、例えば V8 における型の混乱を利用して ArrayBuffer の基底アドレスを変更したとしても、最悪ケージ内のメモリの読み書きができるだけです。 V8 メモリケージがどのように機能するかについてはもっと多くの文献がありまので、ここではこれ以上の詳細には触れません。読み始めるのに最も適しているのは、Chromium チームによる 上位設計ドキュメント でしょう。

Node ネイティブモジュールをリファクタして Electron 20 以降をサポートしたいです。 どうすればいいですか?

V8 のメモリケージに対応するためにネイティブモジュールをリファクタするには、2 つの方法があります。 1 つ目は、外部で作成したバッファを JavaScript に渡す前に コピー して V8 メモリケージに入れることです。 これは一般的に簡単なリファクタですが、バッファが大きいときには遅くなることがあります。 2 つ目は、V8 のメモリアロケータ を使って最終的に JavaScript に渡す予定のメモリを確保する方法です。 これは少し複雑ですが、コピーを回避でき、大きなバッファでのパフォーマンスが向上します。

具体例として、外部の配列バッファを使用する N-API モジュールを以下に示します。

// 外部で確保されたバッファを作成します。
// |create_external_resource| は malloc() によってメモリを確保します。
size_t length = 0;
void* data = create_external_resource(&length);
// Buffer でラップ -- これはメモリケージが有効だと失敗します!
napi_value result;
napi_create_external_buffer(
env, length, data,
finalize_external_resource, NULL, &result);

これはメモリケージが有効な場合、データがケージの外で確保されているためクラッシュします。 代わりにデータをケージへコピーするようにリファクタすると、以下のようになります。

size_t length = 0;
void* data = create_external_resource(&length);
// データを V8 が確保したメモリにコピーして、新しい Buffer を作成します
napi_value result;
void* copied_data = NULL;
napi_create_buffer_copy(env, length, data, &copied_data, &result);
// この新しいコピーにアクセスする際には、|copied_data| が
// そのポインタとなります!

これにより、V8 メモリケージ内にある新たに確保されたメモリ領域へデータがコピーされます。 任意で、N-API は新しくコピーされたデータへのポインタも提供できます。これは、後からデータを修正したり参照したりする必要がある場合に利用できます。

V8 のメモリアロケータを利用するリファクタリングは少し複雑で、malloc を使う代わりに V8 によって割り当てられたメモリを使うように create_external_resource 関数を修正する必要があります。 これは create_external_resource の定義が制御下にあるかどうかによって、多少は実現可能かもしれません。 考え方としては、まず napi_create_buffer など V8 でバッファを作成して、その V8 が確保したメモリにリソースを初期化することになります。 Buffer オブジェクトへの napi_refリソースのライフタイム の間保持することが重要です。さもないと、V8 は Buffer をガベージコレクトし、解放後に使用してしまうエラーを引き起こす可能性があります。

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

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


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

注目すべき変更

Electron リリースケイデンスの変更

このプロジェクトは、以前の方針である最新の 3 つのメジャーバージョンのサポートに戻りつつあります。 Electron のバージョン管理およびサポートについてのより詳細な情報は、バージョン管理のドキュメント をご覧ください。 Electron 15 から始まった新しいリリースサイクルにユーザーが適応できるよう、一時的に 4 つのメジャーバージョンをサポートしていました。 詳細はこちら でご覧いただけます。

累積的変更

破壊的な API の変更

以下は、Electron 19 での破壊的変更点です。 これらの変更と将来の変更の詳細については、予定されている破壊的変更 のページを参照してください。

Linux での非対応化: .skipTaskbar

Linux では BrowserWindow コンストラクタのオプション skipTaskbar がサポートされなくなりました。 #33226 での変更

WebPreferences.preloadURL の削除

準ドキュメント化されていた preloadURL プロパティは、WebPreferences から削除されました。 #33228. WebPreferences.preload を代わりに使用してください。

15.x.y と 16.x.y のサポート終了

Electron 14.x.y と 15.x.y はどちらも既にサポート終了しています。 これにより、Electron は最新の 3 つのメジャーバージョンをサポートする 従来の方針戻ります。 開発者とアプリケーションは新しいバージョンの Electron にアップグレードすることを推奨します。

E15 (Sep'21)E16 (Nov'21)E17 (Feb'22)E18 (Mar'22)E19 (May'22)
15.x.y16.x.y17.x.y18.x.y19.x.y
14.x.y15.x.y16.x.y17.x.y18.x.y
13.x.y14.x.y15.x.y16.x.y17.x.y
12.x.y13.x.y14.x.y15.x.y--

次回予告

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。 リリース日について約束しないように注意していますが、予定では 2 か月ごとに新しいメジャーバージョンの Electron を、各コンポーネントの新しいバージョンに対してリリースします。

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

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

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

Electron はそのプライマリ S3 バケットを変更しているところであり、ビルドスクリプトを更新する必要があるでしょう


何が起きているのですか?

Electron のビルド成果物のうちほとんどが、gh-contractor-zcbenz と呼ばれる S3 バケット上にアップロードされています。 2020 年から現在まで進行中のインフラストラクチャ/所有権移行の一環として、gh-contractor-zcbenz のすべてをその S3 の旧地から https://artifacts.electronjs.org でホストしている新しいストレージシステムに変更しています。 私たちのアセットのほとんどが使用しているパスの接頭辞も若干変更されています。 例えば以下のようなものがあります。

以前: https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/dist/v17.0.0/node.lib
以後: https://artifacts.electronjs.org/headers/dist/v17.0.0/node.lib

重要なのは、ホスト名 が変更され、/atom-shell接頭辞 が変更されたことです。 他の例として、デバッグシンボルの例も挙げましょう。

以前: https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/symbols/path/to/symbol.pdb
以後: https://artifacts.electronjs.org/symbols/path/to/symbol.pdb

同様に、ホスト名が変更され、/atom-shell の接頭辞が変更されています。

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

electron-rebuildelectron-packager@electron/get などの標準的なビルドツールを使用している方は、何もする必要はありません。 おそらくこれが大多数でしょう。

S3 バケットを直接参照している場合は、ホスト名のポイントへの参照を更新し、パスも更新する必要があります。

既存のデータはどうなりますか?

gh-contractor-zcbenz バケットに存在したほとんどのデータは、新しいストレージシステムに複製されました。 これは、すべてのデバッグシンボルとすべてのヘッダがコピーされたということです。 依存していた一部のデータがそのバケットからコピーされていない場合は、electron/electron で Issue を作成しお知らせください。

現在の gh-contractor-zcbenz S3 バケットは積極的に削除されません。 しかし、このバケットの生存期間は保証できません。 私たちはできるだけ早く新しいバケットへターゲットを更新することを 強く 推奨します。

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

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


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

注目すべき変更

Electron リリースケイデンスの変更

Electron 15 にて、Electron は 8 週間ごとに新規メジャー安定版をリリースするようになります。 詳細はこちら でご覧いただけます。

また、Electron は 2022 年 5 月まで、サポートするバージョンを最新の 3 つのバージョンから最新の 4 つのバージョンに変更しています。 Electron のバージョン管理の詳細については バージョン管理のドキュメントを参照してください。 2022 年 5 月以降は、最新の 3 つのバージョンのサポートに戻ります。

累積的変更

注目の機能

  • コードキャッシュのディレクトリを設定する ses.setCodeCachePath() API を追加しました。 #33286
  • 古い BrowserWindowProxy ベースの window.open の実装を削除しました。 さらに webPreferences から nativeWindowOpen オプションを削除しました。 #29405
  • WebContents に 'focus' と 'blur' のイベントを追加しました。 #25873
  • macOS 上に右記の代替メニューロールを追加しました: showSubstitutionstoggleSmartQuotestoggleSmartDashestoggleTextReplacement#32024
  • first-instance-ack イベントを app.requestSingleInstanceLock() フローに追加し、ユーザーが 2 つ目のインスタンスから 1 つ目のインスタンスにデータを渡せるようにしました。 #31460
  • より多くの色形式サポートを setBackgroundColor に追加しました。 #33364

新機能と変更の完全なリストは、18.0.0 リリースノート を参照してください。

破壊的な API の変更

以下は、Electron 18 での破壊的変更点です。 これらの変更と将来の変更の詳細については、予定されている破壊的変更 のページを参照してください。

削除: nativeWindowOpen

Electron 15 より前の window.open は既定で BrowserWindowProxy を使用していました。 このため、window.open('about:blank') では同期的にスクリプトで操作可能な子ウィンドウを開くことができないなどといった、非互換性がありました。 Electron 15 から、nativeWindowOpen が既定で有効になりました。

詳細については、Electron の windows.open のドキュメント をご参照ください。 #29405 で削除されました

14.x.y サポート終了

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

Electron 15 にて、2022 年 5 月の Electron 19 までの間だけ、サポートするバージョンを最新の 3 つのバージョンから最新の 4 つのバージョンに変更しています。 Electron 19 以降は、最新の 3 つのバージョンのサポートに戻ります。 このバージョンサポートの変更は、新しいケイデンス変更の一環です。 完全な詳細についてはこちらのブログ記事 をご参照ください。

E15 (Sep'21)E16 (Nov'21)E17 (Feb'22)E18 (Mar'22)E19 (May'22)
15.x.y16.x.y17.x.y18.x.y19.x.y
14.x.y15.x.y16.x.y17.x.y18.x.y
13.x.y14.x.y15.x.y16.x.y17.x.y
12.x.y13.x.y14.x.y15.x.y--

次回予告

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。 リリース日について約束しないように注意していますが、予定では 2 か月ごとに新しいメジャーバージョンの Electron を、各コンポーネントの新しいバージョンに対してリリースします。

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

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

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

Electron チームは、今年初めて Google Summer of Code に参加することをお知らせします!


Google Summer of Code とは何ですか?

Google Summer of Code (GSoC) は、オープンソースソフトウェアプロジェクトと潜在的な貢献者をつなぐ、年に一回のメンタリングプログラムです。 以前は学生だけでしたが、現在は 18 歳以上であれば誰でも GSoC に登録できます。

詳しい情報については Summer of Code のホームページ をご確認ください。

登録方法は何ですか?

Electron との共同開発に興味はありますか? オープンソースのコントリビューターを始めたばかり方や初心者であれば、ぜひご応募ください!

Google Summer of Code の Electron コントリビューターとして選ばれるためには、ご応募していただく必要があります。 応募開始は 2022 年 4 月 4 日、締め切りは 2022 年 4 月 19 日 となります。 Google Summer of Code の応募要項はこちらで更新しています

応募をご希望ですか? まずは、私たちがご用意した 5 つのプロジェクトアイデア案 をご覧ください。 掲載されているアイデアは、すべて企画のために現在公開中のものです。 また、企画プロジェクトのリストにない新規アイデアも受け付けています。

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

  • 企画書。この夏のプログラムの間に達成する目標の計画を詳細に記した文書です。
  • 開発者としての経歴。 レジュメをお持ちの方はコピーを添付してください。または、関連する技術的な経験を中心に、これまでの経験をお聞かせください。

Electron への応募にかかる提出物の詳細は、こちらをご覧ください。

また GSoC 学生/コントリビューター公式ガイド には、企画書を作成する際の重要なヒントが記載されていますので、ぜひご覧ください。

プロジェクトの企画について議論したい方や質問がある方は、#gsoc-general Discord チャンネル にぜひいらしてください!

リファレンス

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

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


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

注目すべき変更

Electron リリースケイデンスの変更

Electron 15 にて、Electron は 8 週間ごとに新規メジャー安定版をリリースするようになります。 詳細はこちら でご覧いただけます。

また、Electron は 2022 年 5 月まで、サポートするバージョンを最新の 3 つのバージョンから最新の 4 つのバージョンに変更しています。 Electron のバージョン管理の詳細については バージョン管理のドキュメントを参照してください。 2022 年 5 月以降は、最新の 3 つのバージョンのサポートに戻ります。

累積的変更

注目の機能

  • webContents.getMediaSourceId() を追加しました。getUserMedia と共に WebContents のストリームを取得できます。 #31204
  • webContents.getPrinters() を非推奨にし、webContents.getPrintersAsync() を導入します。 #31023
  • desktopCapturer.getSources は、メインプロセスでのみ使用できるようになりました。 #30720

新機能と変更の完全なリストは、17.0.0 リリースノート を参照してください。

破壊的変更

以下は、Electron 17 での破壊的変更点です。 これらの変更と将来の変更の詳細については、予定されている破壊的変更 のページを参照してください。

レンダラー内での desktopCapturer.getSources

desktopCapturer.getSources API は、メインプロセスでのみ使用できるようになりました。 この変更は Electron アプリのデフォルトのセキュリティを改善するためのものです。

API の変更

Electron 17 では API の変更はありませんでした。

削除/非推奨となった変更

  • レンダラー内での desktopCapturer.getSources API の使用方法は削除されました。 アプリにおいてこの API を置換する方法については、こちら をご参照ください。

13.x.y サポート終了

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

Electron 15 にて、2022 年 5 月の Electron 19 までの間だけ、サポートするバージョンを最新の 3 つのバージョンから最新の 4 つのバージョンに変更しています。 Electron 19 以降は、最新の 3 つのバージョンのサポートに戻ります。 このバージョンサポートの変更は、新しいケイデンス変更の一環です。 完全な詳細についてはこちらのブログ記事 をご参照ください。

E15 (Sep'21)E16 (Nov'21)E17 (Feb'22)E18 (Mar'22)E19 (May'22)
15.x.y16.x.y17.x.y18.x.y19.x.y
14.x.y15.x.y16.x.y17.x.y18.x.y
13.x.y14.x.y15.x.y16.x.y17.x.y
12.x.y13.x.y14.x.y15.x.y--

次回予告

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。 リリース日について約束しないように注意していますが、予定では 2 か月ごとに新しいメジャーバージョンの Electron を、各コンポーネントの新しいバージョンに対してリリースします。

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

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

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

Spectron は 2022 年 2 月 1 日に非推奨となります。


2022 年 2 月から、Spectron は Electron チームによって公式に非推奨 となります。

なぜ Spectron を非推奨にするのですか?

Spectron は Electron の新バージョンが出るたびに、一貫して新しいリリースを出してきていました。しかしこのプロジェクトは 1 年以上小さなメンテナンスや改良しか行われておらず、現在フルタイムのメンターはいません。 Electron 14 では remote モジュールが Electron コアから外部モジュールに移行するため、Spectron が確実に動作し続けるためには大幅な書き換えが必要です。

Spectron のメンテナンス継続のいくつかの選択肢を検討した結果、Electron チームは 2022 年で Spectron を非推奨にすることを決定しました。

非推奨のタイムライン

予定の非推奨タイムラインは以下の通りです。

  • 2021 年 11 月 - 2022 年 1 月: Electron チームは引き続きコミュニティからのプルリクエストを受け付けます。
  • 2022 年 1 月: Spectron の非推奨に関する警告の最終版を公開します。
  • 2022 年 2 月 1 日: Spectron のレポジトリを「archived」にします。 これ以降のプルリクエストは受け付けられません。

2022 年 2 月 1 日以降、Electron は Spectron のレポジトリを無期限に保存し、他の人がフォークしたり、既存コードを自分のプロジェクトに利用したりできるようにします。 これにより、Spectron に依存するプロジェクトの移行もよりスムーズに行われることを期待しています。

Spectron の代替

プロジェクトで現在 Spectron を使用していて、別のテストソリューションに移行したい場合は、こちらの自動テストに関するガイド をご覧ください。

現在は Spectron に代わって推奨される代替品として、Playwright や WebDriverIO などがあります。 各選択肢ごとの公式チュートリアルも、この自動テストのドキュメントに記載しております。

次回予告

私たち Electron チームとしましては、Spectron と Electron をご利用いただき感謝しております。 多くのお客様がアプリケーションのテストに Spectron をご利用なされていることは承知しており、この移行をできる限りスムーズに行いたいと考えています。 Electron を選んでくださりありがとうございます!

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

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


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

注目すべき変更

Electron リリースケイデンスの変更

Electron 15 にて、Electron は 8 週間ごとに新規メジャー安定版をリリースするようになります。 詳細はこちら でご覧いただけます。

また、Electron は 2022 年 5 月まで、サポートするバージョンを最新の 3 つのバージョンから最新の 4 つのバージョンに変更しています。 Electron のバージョン管理の詳細については バージョン管理のドキュメントを参照してください。 2022 年 5 月以降は、最新の 3 つのバージョンのサポートに戻ります。

累積的変更

注目の機能

  • WebHID API をサポートするようになりました。 #30213
  • インスタンス間でデータを共有するために、app.requestSingleInstanceLock に data 引数を追加しました。 #30891
  • メディア権限のリクエストハンドラに securityOrigin を渡すようになりました。 #31357
  • commandLine.removeSwitch を追加しました。 #30933

新機能と変更の完全なリストは、16.0.0 リリースノート を参照してください。

破壊的変更

以下は、Electron 16 での破壊的変更点です。 これらの変更と将来の変更の詳細については、予定されている破壊的変更 のページを参照してください。

ネイティブモジュールのビルド

ネイティブモジュールのビルドに node-gyp を使用している場合、プロジェクトの設定や Electron のバージョンによっては --force-process-config を付けて呼び出す必要があるでしょう。 この変更に関する詳細な情報は、#2497 をご覧ください。

動作変更: crashReporter の実装を Linux の Crashpad に

Linux における crashReporter API の内部実装が Breakpad から Crashpad に変更され、Windows や Mac と同じになりました。 この結果、子プロセスが自動的に監視されるようになり、Node の子プロセスで process.crashReporter.start を呼び出す必要がなくなりました (これは Crashpad レポーターの 2 つ目のインスタンスを起動してしまうため非推奨です)。

また、Linux でのアノテーションのレポート方法にも小さな変更があります。長い値に対して __1__2 などを付加したアノテーション間の分割をしなくなり、代わりに (新しい、より長い) アノテーションの値の上限で切り捨てるようになりました。

API の変更

Electron 16 では API の変更はありませんでした。

削除/非推奨となった変更

  • レンダラー内での desktopCapturer.getSources API の使用は非推奨となり、削除される予定です。 この変更は Electron アプリのデフォルトのセキュリティを改善します。 アプリにおいてこの API を置換する方法については、こちら をご参照ください。

12.x.y サポート終了

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

Electron 15 にて、2022 年 5 月の Electron 19 までの間だけ、サポートするバージョンを最新の 3 つのバージョンから最新の 4 つのバージョンに変更しています。 Electron 19 以降は、最新の 3 つのバージョンのサポートに戻ります。 このバージョンサポートの変更は、新しいケイデンス変更の一環です。 完全な詳細についてはこちらのブログ記事 をご参照ください。

E15 (Sep'21)E16 (Nov'21)E17 (Feb'22)E18 (Mar'22)E19 (May'22)
15.x.y16.x.y17.x.y18.x.y19.x.y
14.x.y15.x.y16.x.y17.x.y18.x.y
13.x.y14.x.y15.x.y16.x.y17.x.y
12.x.y13.x.y14.x.y15.x.y--

次回予告

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。 リリース日について約束しないように注意していますが、予定では 2 か月ごとに新しいメジャーバージョンの Electron を、各コンポーネントの新しいバージョンに対してリリースします。

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

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

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

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

GIPHY より


12 月でも変わらないこと

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

12 月で変わること

  1. 12 月は、新しいベータ版および安定版のリリースはありません。 12 月の最後の 2 週間は、ナイトリーのリリースはありません。
  2. いくつかの例外を除いて、プルリクエストのレビューやマージはしません。
  3. どのリポジトリでも Issue トラッカーは更新されません。
  4. メンテナからの Discord デバッグのヘルプはありません。
  5. ソーシャルメディアコンテンツの更新はありません。

なぜこのようなことが起こるのですか?

要するに、メンテナは喜んでプロジェクトに従事するものの、世間は疲れています。 12 月は多くの企業にとって安息月であるため、私たちはメンテナに英気を養う機会を与えたいと考えています。 他のプロジェクトでも同様の措置を検討していただければ幸いです。

Electron の将来を心配したほうがよいでしょうか?

いいえ。 このような選択を取れるのは、プロジェクトが順調に進んでいるからです。 開発者一同 2022 年が楽しみで、きっと良いことが起こると期待しています!