メインコンテンツへ飛ぶ

新しい Electron リリースケイデンス

· 読むのにかかる時間 1 分
⚡️ 更新 (2021-07-14): より速くなっています!

2021 年の第 3 四半期にて、Chrome チームは 6 週間ごとから 4 週間ごとへと リリースケイデンスを増やしました。 Electron のリリースはこれに準拠しています。 最新の情報につきましては、更新した 8 週間ごとのケイデンス のブログ記事をご覧ください。

🎉 Electron は 12 週ごとに新しいメジャー安定バージョンをリリースします! 🎉


⚡️ なんて速さだ! でもなんで?

簡単に言えば、Chromium は更新を止めないので Electron も遅くなりません。

Chromium は、一貫した 6 週間の スケジュール でリリースされます。 Electron で Chromium の最新バージョンを提供するには、そのスケジュールを追う必要があります。 Chromium のリリースサイクルに関する詳細は こちら を参照してください。

🚀 なんで 12 週ごとに?

6 週ごとに、新しい機能、バグ修正/セキュリティ修正、V8 の改善が施された新しい Chromium リリースが出ます。 Electron ユーザーはこの変更を明確に待ち望んでおり、他の Chromium 安定リリースごとに安定リリース日を合わせていました。 最初に、Electron v6.0.0 には M76 が含まれます。これは、Chromium M76 と同じリリース日である 2019 年 7 月 30 日 で安定版リリースを予定しています。

🚧 私と自作 Electron アプリはどうなりますか?

新しい Chromium と V8 の機能と修正プログラムに以前よりも早くアクセスできるようになります。 重要なのは、これら新しい変更がいつ いつ 行われるかもわかるため、以前よりも良質な情報で計画できるということです。

Electron チームは、新しい順に 3 つのメジャーバージョンを 継続サポート します。 例えば、v6.0.0 が 2019 年 7 月 30 日に安定版になった 場合、v6.x、v5.x、v4.x はサポートします。v3.x はサポート終了になります。

💬 App のフィードバックプログラム

アプリフィードバックプログラム に参加して、ベータリリースと安定化のテストに役立ててください。 このプログラムに参加するプロジェクトは、そのアプリで Electron ベータ版をテストします。見返りとして、発見した新しいバグは安定版リリースのために優先します。

📝 Electronリリースの略歴

v3.0.0 より前の安定版リリースに関する決定は、スケジュールに従っていませんでした。 v3.0.0 と v4.0.0 において、プロジェクトに内部スケジュールを追加しました。 今年の初めに Electron v5.0.0 の安定版リリース日を初めて公開することにしました。 安定版リリース日の発表は全体として好意的に受け止められており、今後のリリースでも継続リリースできることを楽しみにしています。

これらのアップグレード関連の作業を効率化するために、 ガバナンス システム内に アップグレードリリース の作業グループが作成されました。 これらにより、作業をより優先順位付けて委任できます。これは後のリリースごとに効果が出てくるでしょう。

Chromium のケイデンスと比較すると、我々の新たなケイデンスは以下のように位置します。

Electron と Chromium のバージョンを比較する折れ線グラフ

📨 ご質問は、info@electronjs.org までメールでお問い合わせください。

Electron 5.0.0

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

Electron チームは、Electron 5.0.0 のリリース発表にワクワクしています! npm を使って npm install electron@latest でインストールするか、リリースページ から tarball をダウンロードできます。 このリリースには、アップグレード、修正、新機能が含まれています。 新機能たちと共に何を作るのか、楽しみにしています! このリリースの詳細については下に続きます。是非ご意見をお聞かせください!


何が新しくなったの?

Electron の機能の多くは、Chromium、Node.js、V8 といったコアコンポーネントによって提供されています。 Electron では、これらのプロジェクトが最新のものになるように維持し、JavaScript の新機能、パフォーマンスの向上、セキュリティ修正をユーザーに提供しています。 これらの各パッケージについて、Electron 5 ではメジャーバージョンを更新しています。

Electron 5 には、Electron 固有の API の改善も含まれます。 主な変更点の概要は以下の通りです。変更点の全リストは Electron v5.0.0 リリースノート を参照してください。

Promise 化

Electron 5 でも Promise 化イニシアチブ の取り組みを継続しており、Electron のコールバックベース API を Promise を使用したものへと変換しています。 これらの API が Electron 5 で変換されています。

  • app.getFileIcon
  • contentTracing.getCategories
  • contentTracing.startRecording
  • contentTracing.stopRecording
  • debugger.sendCommand
  • Cookie API
  • shell.openExternal
  • webContents.loadFile
  • webContents.loadURL
  • webContents.zoomLevel
  • webContents.zoomFactor
  • win.capturePage

macOS 向けシステムカラーアクセス

macOS システムカラーにアクセスするために、これらの関数が systemPreferences に変更または追加されました。

  • systemPreferences.getAccentColor
  • systemPreferences.getColor
  • systemPreferences.getSystemColor

プロセスメモリ情報

現在のプロセスに関するメモリ使用量の統計情報を取得する関数 process.getProcessMemoryInfo が追加されました。

remote API の更なるフィルタリング

remote API のセキュリティを向上させるため、remote.getBuiltinremote.getCurrentWindowremote.getCurrentWebContents<webview>.getWebContentsフィルタリング できる、新しい remote のイベントが追加されました。

BrowserWindow で複数の BrowserView

BrowserWindow が一つの BrowserWindow 内で複数の BrowserViewを管理できるようになりました。

破壊的変更

パッケージしたアプリのデフォルト

パッケージしたアプリは、デフォルトのアプリと同じように動作するようになりました。デフォルトのアプリケーションメニューがそのアプリになければ作成され、アプリが window-all-closed イベントを処理しなければ、そのイベントは自動的に処理されます。

混合サンドボックス

混合サンドボックスモードはデフォルトで有効になりました。 これまでは混合サンドボックスモードも有効になっている場合にのみサンドボックス化されていました。これで、sandbox: true で起動したレンダラーが実際にサンドボックス化されるようになりました。

セキュリティの改善

セキュリティ向上のため、nodeIntegrationwebviewTag の省略値が false になりました。

スペルチェッカーが非同期に

SpellCheck API が変更され、非同期の実行結果 を提供するようになりました。

非推奨

以下の API は Electron 5.0.0 で新たに非推奨となり、6.0.0 で削除される予定のものです。

arm と arm64 向けの mksnapshot バイナリ

arm と arm64 向けの mksnapshot のネイティブバイナリは非推奨となり、6.0.0 で削除されます。 arm と arm64 向けの snapshots は x64 バイナリで作成できます。

WebContents での ServiceWorker API

WebContents 上での ServiceWorker API は後に削除するために非推奨となります。

  • webContents.hasServiceWorker
  • webContents.unregisterServiceWorker

サンドボックス化 WebContents での自動モジュール

セキュリティ向上のため、以下のモジュールの require を介した直接使用は非推奨になります。代わりにサンドボックス化された WebContents 内で remote.require を使用してください。

  • electron.screen
  • child_process
  • fs
  • os
  • パス

webFrame Isolated World APIs

webFrame.setIsolatedWorldContentSecurityPolicywebFrame.setIsolatedWorldHumanReadableNamewebFrame.setIsolatedWorldSecurityOriginwebFrame.setIsolatedWorldInfo と入れ替わりで非推奨になりました。

混合サンドボックス

enableMixedSandbox--enable-mixed-sandbox コマンドラインスイッチは互換性のためにまだ残りますが、非推奨となり効果も無くなります。

2.0.x サポートの終了

サポートするバージョンのポリシー に基づき、2.0.x は役目を終えました。

App のフィードバックプログラム

テストには引き続き アプリフィードバックプログラム を使用します。 このプログラムに参加するプロジェクトは、そのアプリで Electron ベータ版をテストします。見返りとして、発見した新しいバグは安定版リリースのために優先します。 参加や詳細については、当プログラムに関するブログ記事を確認してください

次回予告

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。 リリース日について約束しないように注意していますが、予定では約四半期ごとに新しいメジャーバージョンの Electron を、各コンポーネントの新しいバージョンに対してリリースします。 仮 6.0.0 スケジュール では、Electron 6 開発ライフサイクルの主要な日付を示してあります。 また、Electron のバージョン管理の詳細については バージョン管理のドキュメントを参照 してください。

今後のバージョンの Electron で予定されている破壊的変更の詳細は、予定されている破壊的変更のドキュメントを参照してください

Electron でネイティブから JavaScript へ

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

C++ や Objective-C で記述された Electron の機能は、どのように JavaScript となってエンドユーザーが利用できるのでしょうか。


背景

Electron は、開発者の参入障壁を取り下げることを主目的とした JavaScript プラットフォームで、プラットフォーム固有の実装を気にせずに堅牢なデスクトップアプリを構築できます。 ただし、Electron 自身の中核には、特定システムの言語で記述するようなプラットフォーム固有の機能も必要です。

実際には Electron がネイティブコードを扱うので、単一の JavaScript API に集中できます。

一体、どのように動作しているのでしょうか。 C++ や Objective-C で記述された Electron の機能は、どのように JavaScript となってエンドユーザーが利用できるのでしょうか。

この道筋を追いかけるために、app モジュール から始めましょう。

lib/ ディレクトリ内の app.ts ファイルを開くと、その上部に以下のようなコードの行があります。

const binding = process.electronBinding('app');

この行は、開発者が使用している C++/Objective-C モジュールを JavaScript にバインドする Electron の仕組みをまさに表しています。 この関数は ElectronBindings クラスの、ヘッダーと 実装ファイル によって作成されます。

process.electronBinding

これらのファイルは Node.js の process.binding のように動作する process.electronBinding 関数を追加します。 process.binding は Node.js の require() メソッドよりローレベルの実装です。ただし、他の JS で書かれたコードではなくネイティブコードを require することができます。 このカスタム process.electronBinding 関数は Electron からネイティブコードをロードする機能を与えます。

トップレベルの JavaScript モジュール (app など) がこのネイティブコードを require する場合、そのネイティブコードの状態はどのように決定および設定されるのでしょうか。 そのメソッドはどこまで JavaScript に公開されるのでしょうか。 プロパティではどうなのでしょうか。

native_mate

現時点では、この疑問には native_mate が答えてくれます。これは、C++ と JavaScript の間で型をマーシャリングしやすくする Chromium の gin ライブラリ のフォークです。

native_mate/native_mate の中には、object_template_builder のヘッダーと実装ファイルがあります。 これにより、JavaScript 開発者が望むように適合する形式のネイティブコードでモジュールを形成します。

mate::ObjectTemplateBuilder

すべての Electron モジュールを object として見ると、object_template_builder で構築する理由がわかりやすくなります。 このクラスは、C++ で記述された Google によるオープンソースで高性能の JavaScript および WebAssembly エンジン、V8 が公開するクラスの上に構築されます。 V8 は JavaScript (ECMAScript) の仕様を実装しているため、ネイティブ機能の実装を JavaScript の実装に直接関連付けることができます。 たとえば、v8::ObjectTemplate は専用のコンストラクタ関数とプロトタイプなしで JavaScript オブジェクトを提供します。 Object[.prototype] を使用するため、JavaScript での Object.create() と等価です。

この動作確認は、アプリモジュールの実装ファイル atom_api_app.cc を参照してください。 下部には以下のようなものがあります。

mate::ObjectTemplateBuilder(isolate, prototype->PrototypeTemplate())
.SetMethod("getGPUInfo", &App::GetGPUInfo)

上記の行では、.SetMethodmate::ObjectTemplateBuilder で呼び出されます。 .SetMethodObjectTemplateBuilder クラスの任意のインスタンスで呼び出し、以下の構文で JavaScript の Object プロトタイプ にメソッドを設定できます。

.SetMethod("method_name", &function_to_bind)

これは以下の JavaScript と等価です。

function App{}
App.prototype.getGPUInfo = function () {
// ここに実装
}

このクラスには以下のようなモジュールにプロパティをセットする関数も含まれます。

.SetProperty("property_name", &getter_function_to_bind)

または

.SetProperty("property_name", &getter_function_to_bind, &setter_function_to_bind)

これらは、以下のような Object.defineProperty による JavaScript 実装になります。

function App {}
Object.defineProperty(App.prototype, 'myProperty', {
get() {
return _myProperty
}
})

aND

function App {}
Object.defineProperty(App.prototype, 'myProperty', {
get() {
return _myProperty
}
set(newPropertyValue) {
_myProperty = newPropertyValue
}
})

これによって開発者が予期するようなプロトタイプとプロパティで形成された JavaScript オブジェクトを作成することができ、よりローレベルのシステムで実装された関数とプロパティでもよりはっきりと推論します!

特定のモジュールメソッドの実装場所に関する決定は、それ自体が複雑かつ多くの場合に置いて非決定的です。これについては今後の記事で補います。

Electron のガバナンス

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

Electron がデスクトップアプリケーションで人気を博すにつれて、取り組むチームも成長しました。さまざまな企業で働き、タイムゾーンに住み、関心を持つ専任メンテナーが増えています。 よりスムーズに成長し続けることができるように、我々にガバナンス機構を導入します。


なぜ変革するのですか?

Electron プロジェクトの人々は、世界中のタイムゾーンに居るボランティア、専任メンテナー、Electron に依存しているいくつかの企業と調整しています。 これまで、形式的でない調整で上手くいっていました。しかし、チームが成長するにつれてこのやり方がスケールしないことがわかりました。 また、新規のコントリビューターをプロジェクト内に呼び戻しやすくしたいのです。

ワーキンググループ

Electron ガバナンスは、プロジェクトのさまざまな部分を担当するワーキンググループを含みます。 我々は以下の 7 つのグループから始めることにします。

  • コミュニティ & 安全性: 行動規範 の問題を執る。
  • ドキュメント & ツール: 外部向けツール (FiddleForge など) の監督と Electron の ドキュメント化 を行う。
  • 支援: Electron コミュニティの成長を支援する。
  • リリース: リリースが安定かつ予定通りであることを確認する。
  • セキュリティ: セキュリティテストを行い、セキュリティの問題に対応する。
  • アップグレード: 新しいバージョンの V8、Chromium、Node などの、上流のアップグレードを統合する。
  • ウェブサイト: Electron のウェブサイト を維持し改善する。

これらのグループは相互に調整し合いますが、グループは各々のの会議スケジュールと議題を保持し、生産的に活動してください。 これらのグループの詳細は ガバナンスリポジトリ で見ることができます。

Electron プロジェクトの方向性は変わりますか?

これは Electron の方向性に直接影響しません。 私たちの戦略が成功した場合、ワーキンググループは、新しいコントリビューターが関心のあるトピックを見つけやすくし、それぞれの日常業務と無関係の議論を他グループに移行することで、メンテナーの活動が楽になります。 こうなると、制限されない人々の間接的な働きかけがより影響するでしょう。

詳細はどこですか?

Chromium FileReader の脆弱性の修正

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

Chrome に高レベルの重大な脆弱性が発見されました。Electron を含む Chromium ベースのすべてのソフトウェアに影響します。

この脆弱性は CVE-2019-5786 と命名されています。 詳細は Chrome ブログ記事 を参照してください。

Chrome でこの脆弱性が悪用されているという報告があります。なるべく早く Electron を更新することを強く推奨します。


影響範囲

これはサードパーティや信頼できない JavaScript を実行する恐れのある Electron アプリケーションに影響します。

緩和策

影響を受けるアプリは、パッチを当てたバージョンの Electron にアップグレードする必要があります。

以下の通り、この脆弱性に対する修正を含む新しいバージョンの Electron を公開しました。

Electron 5 の最新ベータ版は Chromium 73 を追っていたので、パッチは適用済みです。

詳細情報

この脆弱性は Google の Threat Analysis Group の Clement Lecigne によって発見され、Chrome チームに報告されました。 その Chrome ブログ記事は こちら です。

Electron アプリを堅牢に保つベストプラクティスの詳細は、セキュリティチュートリアル を参照してください。

Electron の脆弱性を報告する場合は、security@electronjs.org にメールでご連絡お願いします。

32 ビット Linux のサポート中止

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

Electron チームは 32 ビット Linux (ia32 / i386) に対するサポートを Electron v4.0 から中止します。 32 ビットを元にした Linux 環境をサポートする最後のバージョンは Electron v3.1 です。 このバージョンでは、 Electron v6 がリリースされるまでサポートリリースを受けられます。 64 ビット Linux 及び armv7l のサポートは変わらず続行されます。


Electron は何のサポートをやめるのですか?

コンピュータに貼られたシールや、ソフトウェアをダウンロードするときの選択肢として "64 ビット" 及び "32 ビット" の説明を見たことがあるかもしれません。 この語は、特定のコンピュータアーキテクチャを表します。 1990 年代と 2000 年代初期に作成されたほとんどのコンピュータは、 32 ビットアーキテクチャに基づいた CPU を使用していましたが、後に作られたものは、より新しく強力な 64 ビットアーキテクチャに基づくようになりました。 Nintendo 64 (分かりますか?) と PlayStation 2 は新しいアーキテクチャを持つデバイスで最初に広く利用されたものでした。 2010 年以降に販売されたコンピュータのほとんどには、 64 ビットプロセッサが使われていました。 Google は 32 ビット向けの Chrome リリースを 2016 年 3 月にやめたほか、 Canonical は 32 ビットデスクトップ向けイメージの配布を 2017 年にやめた後、 Ubuntu 18.10 で 32 ビットのサポートを終了しました。このように、 32 ビットアーキテクチャのサポートは縮小しています。 Arch Linux、Elementary OS や他の著名な Linux ディストリビューションでは、既に古いプロセッサアーキテクチャのサポートを終了しています。

これまで、 Electron は 32 ビットアーキテクチャ向けのビルドを配布し、サポートしてきました。 リリース v4.0 から、 Electron チームは 32 ビット Linux のバイナリ配布やサポートをできなくなります。

Electron は常に活発的なオープンソースプロジェクトであり、新しいアーキテクチャ向けに Electron をビルドしようとする開発者を奨励したり、助けたりしていきます。

開発者にとっては何を意味しますか?

32 ビット Linux 用にアプリを配布していない場合、何もする必要はありません。

32 ビット Linux 向け Electron アプリを配布しているプロジェクトでは、どのように進めるかを決める必要があるでしょう。 決定や計画を行うために、Electron 6 がリリースされる まで は Electron 3 で 32 ビット Linux がサポートされます。

ユーザにとっては何を意味しますか?

あなたが Linux ユーザで、 64 ビットに基づいたシステムで実行しているかどうかが分からない場合、おそらく 64 ビットに基づいたアーキテクチャで実行しているでしょう。 確認するには、 lscpu または uname -m コマンドを端末で実行してください。 どちらかが現在のアーキテクチャを表示するでしょう。

Linux を 32 ビットプロセッサで実行している場合、最近リリースされたソフトウェアでその OS 用のものを見つけるのは困難になってきているはずです。 Electron チームは、 Linux コミュニティの他の著名なメンバーと同じく、 64 ビットに基づいたアーキテクチャへアップグレードすることを推奨します。

BrowserView window.open() の脆弱性の修正

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

Node を子ウィンドウで再度有効にできるというコードの脆弱性が発見されました。


sandbox: true または nativeWindowOpen: truenodeIntegration: false で BrowserView を開くと、そこから window.open を呼び出すことができます。そうして新しく開いた子ウィンドウでは nodeIntegration が有効な webContents が生成されます。 この脆弱性は、すべてのサポートされているバージョンの Electron に影響します。

緩和策

この脆弱性に対する修正を含む新しいバージョンの Electron を公開しました。2.0.173.0.153.1.34.0.45.0.0-beta.2 です。 すべての Electron 開発者は、アプリをすぐに最新の安定バージョンに更新することを推奨します。

何らかの理由で Electron バージョンをアップグレードできない場合は、すべての子ウェブコンテンツを無効にすることでこの問題を緩和できます。

view.webContents.on('-add-new-contents', (e) => e.preventDefault());

詳細情報

この脆弱性は PalmerAL によって発見され、Electron プロジェクトに責任ある形で報告されました。

Electron アプリを堅牢に保つベストプラクティスの詳細は、セキュリティチュートリアル を参照してください。

Electron の脆弱性を報告する場合は、security@electronjs.org にメールでご連絡お願いします。

Node.js ネイティブアドオンと Electron 5.0

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

Electron 5.0 でネイティブな Node.js アドオンを使用しようとして問題が発生している場合、 V8 の最新バージョンで動作するように更新する必要があるかもしれません。


さようなら v8::Handle 、こんにちは v8::Local

2014 年、 V8 チームはローカルハンドルを v8::Local に置き換え、 v8::Handle を非推奨にしました。 Electron 5.0 は v8::Handle が削除されたバージョンの V8 を含んでいるため、それを使用しているネイティブ Node.js アドオンは Electron 5.0 で使用される前に更新する必要があります。

必要なコード変更は最小限ですが、未だ v8::Handle を使用している すべての ネイティブ Node モジュールは Electron 5.0 でのビルドに失敗するため、変更されなければなりません。 Node.js v12 はこの V8 の変更を含んでいるため、 v8::Handle を使用しているモジュールは次のバージョンの Node で動作するために どのみち 更新される必要があるでしょう。

私はネイティブアドオンをメンテナンスしていますが、どうすればいいですか?

あなたが Node.js 用のネイティブアドオンをメンテナンスしている場合、 v8::Handle が使われている場所がすべて v8::Local に置き換わっていることを確認してください。 前者は後者の別名に過ぎなかったので、この問題に対処するために他の変更を加える必要はありません。

また、 N-API は、Node.js の一部として V8 とは別に管理され、基になる JavaScript エンジンの変更からネイティブアドオンを分離することを目的としています。 詳細については Node.js ウェブサイト内の N-API ドキュメント を参照してください。

ヘルプ! ネイティブアドオンを使用している私のアプリが動作しません!

アプリで Node.js 用のネイティブアドオンを使用していて、この問題のためにネイティブアドオンがビルドされない場合は、アドオンの作成者に問い合わせて、問題を解決する新しいバージョンがリリースされているかどうかを確認してください。 もしそうでなければ、著者に連絡を取る (または プルリクエストを開く! ) とよいでしょう。

Electron v5.0.0 タイムライン

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

v5.0.0 以降の Electron のリリーススケジュールを初めて公開することにドキドキしています。 これは公開される長期のスケジュールを設定する第一歩です。


v4.0.0 安定版リリースの ブログ記事 で述べたように、およそ四半期ごとにリリース予定です。Chromium のリリースと密接なケイデンスを維持します。 Chromium は、6 週間という非常に速い周期で新バージョンをリリースします。

Electron と Chromium の変遷を並べて見てみましょう。

Electron と Chromium のバージョンを比較する折れ線グラフ

2018 年の後半、私たちの最優先事項は、より早くリリースして Chromium に追いつくことでした。 これは事前に決めたタイムラインを遵守することで成功しました。 Electron 3.0.0 と 4.0.0 は、各リリース 2 ~ 3 か月のタイムラインでリリースされました。 5.0.0 以降のリリースでもそのペースを続けるつもりです。 ほぼ四半期ごとに Electron のメジャーリリースが行われ、Chromium のリリースペースに追いつきます。 Chromium の安定版リリースに先んじることは常に私たちの目標であり、私たちはそれを着実に進めています。

Node.jsChromium のように将来の日付を約束したいのですが、まだ その段階ではありません。 将来的には長期的なスケジュールに変化するだろうと楽観視しています。

それを念頭に置いて、v5.0.0 のリリーススケジュールを公開することで第一段階を進めています。 スケジュールは こちら にあります。

ベータ版リリースと安定化のテストに役立てるため、アプリフィードバックプログラム への参加をご検討ください。

Electron 4.0.0

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

Electron チームは、Electron 4 安定版が利用可能になった発表でワクワクしています! electronjs.org からか、npm で npm install electron@latest からインストールできます。 このリリースにはアップグレード、修正、新機能が詰め込んであります。皆さんが何を作るのか待ち遠しいです。 以下にこのリリースの詳細が続きます。是非使用したご意見を共有してください!


何が新しくなったの?

Electron の機能の大部分は、Electron を構成するコアコンポーネントの Chromium、Node.js、V8 によって提供されています。 そのため Electron チームの主な目標は、これらのプロジェクトの変更に可能な限り対応し、Electron アプリを開発する開発者に新しいウェブや JavaScript の機能へのアクセスを提供することです。 このため Electron 4 ではこれらの各コンポーネントのバージョンが大きく変更されています。Electron v4.0.0 には Chromium 69.0.3497.106、Node 10.11.0、V8 6.9.427.24 が入っています。

さらに、Electron 4 には Electron 固有の API への変更が含まれます。 変更箇所の全リストは、Electron v4.0.0 リリースノート を参照してください。

remote モジュールの無効化

セキュリティ上の理由から、remote モジュールを無効化できるようになりました。 このモジュールは BrowserWindowwebview タグに対して無効化できます。

// BrowserWindow
new BrowserWindow({
webPreferences: {
enableRemoteModule: false
}
})

// webview タグ
<webview src="http://www.google.com/" enableremotemodule="false"></webview>

詳細は BrowserWindow<webview> タグ のドキュメントを参照してください。

remote.require() / remote.getGlobal() リクエストのフィルタリング

この機能は、レンダラープロセスや webviewremote モジュールを完全に無効化したくないけれど、remote.require で require され得るモジュールを追加で制御したい場合に便利です。

レンダラープロセス内で remote.require からモジュールが require されると、app モジュールremote-require イベントが発生します。 event (第一引数) の event.preventDefault() を呼び出すと、モジュールをロードしないようにできます。 第 2 引数には require を発生させた WebContents インスタンス が、第 3 引数にはモジュール名が渡されます。 同じイベントが WebContents インスタンスでも発生しますが、この場合はイベントとモジュール名のみが引数です。 どちらの場合でも、event.returnValue に値をセットすることでカスタム値を返すことが出来ます。

// 全ての WebContents からの `remote.require` を制御:
app.on('remote-require', function (event, webContents, requestedModuleName) {
// ...
});

// 特定の WebContents インスタンスからの `remote.require` を制御します。
browserWin.webContents.on(
'remote-require',
function (event, requestedModuleName) {
// ...
},
);

同様に、remote.getGlobal(name) が呼び出されると remote-get-global イベントが発生します。 これは remote-require イベントと同じように動作します。global が返されないように preventDefault() を呼び出したり、event.returnValue でカスタム値を返したりできます。

// 全ての WebContents からの `remote.getGlobal` を制御します。
app.on('remote-get-global', function (event, webContents, requrestedGlobalName) {
// ...
},
);

// 特定の WebContents インスタンスからの `remote.getGlobal` を制御します。
browserWin.webContents.on(
'remote-get-global',
function (event, requestedGlobalName) {
// ...
},
);

詳細は、以下のドキュメントを参照してください。

JavaScript で アプリについて にアクセス

macOS で {role: 'about'} で作成されたメニューアイテムをクリックするのと同じように、app.showAboutPanel() を呼び出すとプログラムから このアプリについて のパネルを表示できるようになりました。 詳しくは showAboutPanel ドキュメント を参照して下さい。

WebContents バックグラウンド抑制の制御

WebContents インスタンスに、ページがバックグラウンドになったときにタイマーやアニメーションの抑制を有効または無効にするメソッド setBackgroundThrottling(allowed) が加わりました。

let win = new BrowserWindow(...)
win.webContents.setBackgroundThrottling(enableBackgroundThrottling)

詳しくは setBackgroundThrottling ドキュメント を参照して下さい。

破壊的変更

macOS 10.9 をサポートしないように

Chromium は macOS 10.9 (OS X Mavericks) をサポートしなくなったので、Electron 4.0 以降でもサポートしません

シングルインスタンスロック

以前は、アプリをシングルインスタンスアプリケーションに (アプリのインスタンスが常に 1 つしか実行されないように) するために、app.makeSingleInstance() メソッドが使用できました。 Electron 4.0 からは、代わりに app.requestSingleInstanceLock() を使用する必要があります。 このメソッドの戻り値は、アプリケーションのこのインスタンスのロックが成功したかどうかを表します。 ロックの取得に失敗した場合は、アプリケーションの別のインスタンスがすでにロックした上で実行していると考えられるため、直ちに終了してください。

requestSingleInstanceLock() の使用例や、さまざまなプラットフォームでの細かい挙動については、app.requestSingleInstanceLock() とその関連メソッド のドキュメントや second-instance イベント を参照してください。

win_delay_load_hook

Windows でネイティブモジュールをビルドするとき、モジュールの binding.gyp 内の win_delay_load_hook 変数は true (これが初期値) にならなければいけません。 このフックが存在しない場合、そのネイティブモジュールは Windows 上ではロードできず、Cannot find module のようなエラーメッセージが表示されます。 詳細は ネイティブモジュールガイドを参照してください

非推奨

以下の破壊的変更が Electron 5.0 で予定されているため、Electron 4.0 で非推奨となります。

Windows で nativeWindowOpen された場合の Node.js インテグレーション無効化

Electron 5.0 からは、nativeWindowOpen オプションで開いた子ウィンドウでは常に Node.js インテグレーションが無効化されます。

webPreferences の既定値

webPreferences オプションを指定して新しいBrowserWindow を作成する場合、以下のように元の webPreferences オプションの省略値は非推奨となり、新しい省略値が採用されます。

プロパティ非推奨の省略値新しい省略値
contextIsolationfalsetrue
nodeIntegrationtruefalse
webviewTagnodeIntegration が設定されていればその値に, さもなくば truefalse

注記: 現在 既知のバグ (#9736) があり、contextIsolation がオンの場合にwebview タグが動作しません。 最新の情報は GitHub の Issue を確認してください!

コンテキストイソレーション、Node インテグレーション、webview タグについての詳細は、Electron セキュリティドキュメント を参照してください。

Electron 4.0 では旧来のデフォルト値を使用しますが、値を明示的に渡さない場合は非推奨の警告が表示されます。 アプリが Electron 5.0 へ対応するように準備するのであれば、これらのオプションに明示的な値を使用してください。 各オプションの詳細については BrowserWindow ドキュメント を参照してください。

webContents.findInPage(text[, options])

medialCapitalAsWordStartwordStart オプションは、上流で削除されたために非推奨となりました。

App のフィードバックプログラム

Electron 3.0 の開発時に実施した アプリフィードバックプログラム が成功したので、4.0 の開発でも継続して実施します。 Atlassian、Discord、MS Teams、OpenFin、Slack、Symphony、WhatsApp、その他プログラムメンバーの方々には、4.0 ベータサイクルに参加して頂いたことに多大な感謝の意を表します。 アプリフィードバックプログラムの詳細や今後のベータ版への参加については、当プログラムに関するブログ記事を参照してください

次回予告

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。 リリース日について約束しないように注意していますが、予定では約四半期ごとに新しいメジャーバージョンの Electron を、各コンポーネントの新しいバージョンに対してリリースします。 Electron のバージョン管理の詳細については バージョン管理のドキュメントを参照してください

今後のバージョンの Electron で予定されている破壊的変更の詳細は、予定されている破壊的変更のドキュメントを参照してください