メインコンテンツへ飛ぶ

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 で予定されている破壊的変更の詳細は、予定されている破壊的変更のドキュメントを参照してください

SQLite の脆弱性の修正

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

リモートコード実行の脆弱性 "Magellan" が発見されました。SQLite、Chromium、全バージョンの Electron ベースのソフトウェアに影響します。


影響範囲

Web SQL を使用する Electron アプリケーションが影響を受けます。

緩和策

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

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

これに関する被害報告はありませんが、影響を受けるアプリケーションは緩和策を実施してください。

詳細情報

この脆弱性は Tencent Blade チームによって発見されました。彼らは この脆弱性について論じたブログ記事 を公開しています。

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

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

Electron アプリフィードバックプログラム

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

Electron はリリースサイクルが高速かつより安定するように取り組んでいます。 実現のため、大規模 Electron アプリのためのアプリフィードバックプログラムを始めました。ベータリリースをテストしてアプリ固有の問題を報告できます。 これは、できるだけ早くアプリケーションを次の安定リリースへアップグレードする、その作業の優先順位付けに役立ちます。

編集(2020-05-21):このプログラムは引退しました。


どんなアプリが参加できますか?

このプログラムに参加するアプリの基準と要件は、以下の項目の通りです。

  • ベータ期間中に 10,000 ユーザー時間以上アプリをテストすること
  • アプリにおける Electron のバグと障害について議論する手続きを毎週行う担当者を 1 人配置すること
  • Electron の 行動規範 の遵守に同意すること
  • 以下の質問に列挙されている下記情報を共有すること

Electron アプリが共有しなければならない情報は何ですか?

  • ベータリリースで実行されたアプリの総ユーザー時間
  • アプリがテストしている Electron のバージョン (4.0.0-beta.3 など)
  • ベータテストされているリリースラインでアプリケーションのアップグレードを妨げるようなバグ

ユーザー時間

すべてが正確なユーザー数を共有できるわけではないことは理解していますが、より良いデータは特定リリースの安定性の判断に役立ちます。 現在、アプリのテストはベータサイクルを通じて 10,000 ユーザー時間まで到達するようにお願いしています。

  • 10 ユーザー時間は、10 人が 1 時間テストする、もしくは 1 人が 10 時間テストするということです。
  • 3.0.0-beta.2 で 5,000 ユーザー時間をテストしてから、3.0.0-beta.5 で 5,000 ユーザー時間をテストする、というようにベータリリース間でテストを分割できます。 多ければ多いほど良いのですが、アプリケーションによっては全ベータリリースをテストできません。
  • CI や QA 時間は合計にカウントされませんが、内部リリースはカウントされます。

私の Electron アプリも参加するべきですか?

あなたのアプリのバグは追跡され、コア Electron チームのレーダーに記録されます。 あなたのフィードバックが、新しいベータ版の動作確認、必要な作業の確認などで Electron チームの役に立ちます。

私のアプリケーションの情報は公開されますか? この情報を見られるのは誰ですか?

いいえ、アプリケーションの情報は一般公開されません。 情報は、アプリフィードバックプログラムと Electron ガバナンス のメンバーのみが閲覧できるプライベート GitHub リポジトリに保管されます。 メンバーは全員 Electron の 行動規範 の遵守に同意しています。

新規申込

現在、新規申込の 数を限定 しています。 もし興味があり、上記の要件を満しているならば、この フォーム に記入してください。