今朝 OpenJSワールド で、Electronが OpenJS財団の インキュベーションプログラムを正式に卒業し、現在OpenJS財団インパクトプロジェクトになったことを発表しました。

Electron は 2019 年 12 月にインキュベーションに参加しました。これは、モントリオールで開催された直近の OpenJS Foundation グローバルカンファレンスで発表されました。 私たちは、Impact Project として JavaScript コミュニティでより大きな役割を果たし、OpenJS Foundation とのパートナーシップを継続できることを嬉しく思います。

詳細​

財団、その使命、財団員については、[OpenJSF ウェブサイト](https://www.notion.so/Electron-joins-the-OpenJS-Foundation- d898f12480874e56abe78f29b041fb91#0801fd7e9fa340afbcdce0510ba05f8a) で見ることができます。 OpenJS 財団は、jQuery、Node.js、webpack などの多くのオープンソース JavaScript プロジェクトをホストしています。 GoDaddy、Google、IBM、Intel、Joyent、Microsoft を含む 30 の企業やエンドユーザーメンバーによってサポートされています。

Electron は、ウェブ技術を備えたクロスプラットフォームのデスクトップアプリケーションを構築するオープンソースフレームワークです。 Electron の裏方の人物とどのように連携するのかについては、ガバナンスページ を参照してください。

Electron 自体を使い始める場合は、ドキュメント をご覧ください。

Electron はメジャーリリースを延期しています

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

メジャーリリースのケイデンススケジュール は Chromium のリリーススケジュールと連動しており、最近になって Chromium プロジェクトは作業スケジュール調整のために リリースを一時停止する 決定をしました。 つまり、Chromium のケイデンスが変更されている間、Electron は新しいメジャーリリースを一時的に延期します。

Chromium の歩みに合わせることが最善の選択として慎重に進めており、その間、Electron チームはバグ修正、セキュリティ、パフォーマンス、安定性に関するフルタイム作業に移行します。

この間、メンテナーと消費者両方の福利が優先されたいため、フィードバックを歓迎しますし、通常のリリーススケジュールに戻ることを楽しみにしています。

その他の更新情報については Twitter アカウント をフォローしてください。

編集 (2020-03-30): Electron 9 安定版は Chromium M83 をターゲットとし、Chromium の発表 である M82 の安定版の日付を飛ばして M83 の安定版の日付へと調整することで、2020 年 5 月 19 日にリリースされます。

モントリオールの Node + JS Interactiveで、OpenJS 財団 が Electron を財団のインキュベーションプログラムに受け入れたことを発表しました。 財団は、プロジェクトをホストし維持する中立的な組織を提供し、コミュニティ全体の利益のために共同で活動に資金を提供することにより、JavaScript エコシステムとウェブ技術の健全な成長を支援することを約束します。

OpenJS 財団は、jQuery、Node.js、webpack などの多くのオープンソース JavaScript プロジェクトをホストしています。 GoDaddy、Google、IBM、Intel、Joyent、Microsoft を含む 30 の企業やエンドユーザーメンバーによってサポートされています。 Electron は、ウェブ技術を備えたクロスプラットフォームのデスクトップアプリケーションを構築するオープンソースフレームワークです。

これは Electron にとって心躍る決定であり、オープンソースプロジェクトとして次の段階へ進化したと考えています。

開発者にとっての意義​

Electron が OpenJS 財団に参加しても、Electron の作成、リリース、使用方法は変わりません。Electron を使用してアプリケーションを構築する開発者に直接影響を与えることはありません。 Electron は 2013 年に GitHub で作成されましたが、現在は多くの組織や個人によって管理されています。 2019 年、Electron はガバナンス構造を体系化し、プロジェクト全体に影響を与える決定方法の形式化に多額の投資を行いました。 複数の組織と開発者が Electron に投資し、協力することで、プロジェクトがより強くなると信じています。

Electron を単一企業体の所有から引き上げ、ウェブや JavaScript エコシステムのサポートに焦点を当てた中立的な基盤に移行することで、オープンソースプロジェクトとして次の段階へ成熟します。

詳細​

財団、その使命、財団員については、[OpenJSF ウェブサイト](https://www.notion.so/Electron-joins-the-OpenJS-Foundation- d898f12480874e56abe78f29b041fb91#0801fd7e9fa340afbcdce0510ba05f8a) で見ることができます。 Electron の OpenJSF インキュベーションプログラムへの受け入れに関する詳細と引用については、公式プレスリリースをご覧ください。 Electron の裏方の人物とどのように連携するのかについては、ガバナンスページ を参照してください。

Electron 自体を使い始める場合は、ドキュメント をご覧ください。

🎉 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 のケイデンスと比較すると、我々の新たなケイデンスは以下のように位置します。

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

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

なぜ変革するのですか?​

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

ワーキンググループ​

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

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

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

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

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

詳細はどこですか?​

• ガバナンス レポジトリ と チャーター に、新しいガバナンス構造に関する情報があります。
• 各ワーキンググループはそれぞれのページを保有しています。コミュニティ、ドキュメント & ツール、支援、リリース、セキュリティ、アップグレード、ウェブサイト があります。
• メンテナと連絡するには、Issue を開く か、info@electronjs.org までメールでお問い合わせください。

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 ビットに基づいたアーキテクチャへアップグレードすることを推奨します。

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 は、GN を使用して自身を構築しています。 その理由についてこちらで説明します。

GYP と GN

2013 年、最初に Electron がリリースされたとき、Chromium のビルド構成は GYP で記述されていました。これは "Generate Your Projects" の略です。

2014 年、Chromium プロジェクトは GN ("Generate Ninja") を導入しました。Chromium のビルドファイルは GN に移行され、GYP はソースコードから削除されました。

歴史的に、Electron はメインの Electron コード と libchromiumcontent を分離しています。これは、Chromium の 'content' サブモジュールをラップする Electron の一部です。 Electron は GYP を使用し続けましたが、Chromium の方の libchromiumcontent は GN に切り替えました。

ピッタリ噛まない歯車のように、2 つのビルドシステムの間に摩擦がありました。 互換性の維持にはエラーが発生しやすくなりました。コンパイラフラグと #define を Chromium、Node、V8、Electron 間で細心の注意を払って同期する必要があるからです。

これに対処するため、Electron チームは全てを GN へ移行してきました。 そしてついに、Electron 最後の GYP コード削除の コミットが master に乗りました。

開発者にとっての意義

Electron 自体にコントリビュートしている方は、master もしくは 4.0.0 から Electron をチェックアウトしてビルドするプロセスが 3.0.0 以前と大きく変わります。 詳細は GN ビルド手順 を参照してください。

Electron でアプリを開発している方は、新しい Electron 4.0.0-nightly でのいくつかの小さな変更に気付くかもしれません。しかし、Electron ビルドシステムが変わったことによる影響はおそらくありません。

Electron にとっての意義

GN は GYP より 高速 で、ファイルの可読性が高く保守も容易です。 さらに、単体のビルド構成システムを使用することで、Electron を Chromium の新バージョンへアップグレードするにあたって必要な作業が軽減されるでしょう。

• Chromium 67 では MSVC サポートを削除し、Windows でも Clang を使用したビルドに切り替えました。そのため、Electron 4.0.0 での開発は既に大幅に支援されています。 GN ビルドでは、Chromium からすべてのコンパイラコマンドを直接継承するため、Windows 用 Clang ビルドを無料で入手できます!

• また、Electron、Chromium、Node 間で同じビルドの BoringSSL を Electron に使用しやすくなりました。これはもはや 過去の問題 です。

Electron の基盤となる Chrome のライブラリ libchromiumcontent には、ビルド時間から 10 週間ずれた時間になることによって、一部の Symantec、GeoTrust、Thawte SSL/TLS 証明書が拒否されてしまう問題があります。Electron 1.4.12 には、この上流の Chrome の問題を修正する重要なパッチが含まれています。 影響を受けるサイトの証明書自体に問題はなく、これらの証明書を置き換えても何もありません。

Electron 1.4.0 — 1.4.11 では、これらの影響を受ける証明書のサイトへの HTTPS リクエストは、特定の日付以降、ネットワークエラーになります。 これは、window.fetch、Ajax リクエスト、Electron の net API、BrowserWindow.loadURL、webContents.loadURL、<webview> タグの src 属性など、Chrome の基盤となるネットワーク API を使用して行われた HTTPS 要求に影響します。

アプリケーションを 1.4.12 にアップグレードすると、これらのリクエストエラーが発生しなくなります。

注釈: この問題は Chrome 53 から発生したため、1.4.0 以前のバージョンの Electron は影響を受けません。

影響日​

以下は、Electron 1.4 の各バージョンと、影響を受ける証明書のサイトへのリクエストが失敗し始める日付の表です。

アプリの影響日へコンピューターの時計を進めて、https://symbeta.symantec.com/welcome/ から正常に読み込まれるかどうか確認してください。

詳細情報​

このトピック、大元の問題、修正の詳細については、以下のサイトで見ることができます。

• 証明書の透明性とは?
• Symtantec ナレッジデータベースの記事
• Chrome issue 664177
• issue 664177 の Chrome 修正
• issue 664177 の libchromiumcontent パッチ

Electron バージョン 1.3.1 では、 npm install electron --save-dev とすればコンパイル済みの Electron をアプリにインストールできます。

ビルド済み Electron ライブラリ​

Electron アプリの開発経験があれば、おそらく electron-prebuilt npm パッケージを触ったことがあるでしょう。 このパッケージはほぼすべての Electron プロジェクトにおいて不可欠なものです。 インストールされると、オペレーティングシステムを検出し、ビルド済みバイナリの中からそのシステムアーキテクチャに適したものをダウンロードします。

新しい名前​

Electron のインストール過程は、新規開発者にとっての壁となりがちでした。 多くの勇敢な人々が、npm install electron-prebuilt ではなく npm install electron を実行して Electron アプリの開発を始めようとしたところ、(多くの場合、混乱の末に) それが探していた electron ではないことに気づいたでしょう。

これは、 GitHub の Electron プロジェクトが作られる前から electron プロジェクトが npm に存在していたためです。 Electron での開発がより簡単で直感的になるよう、私たちは既存の electron の所有者に連絡を取り、名前を使わせてもらえないかを交渉しました。 幸い、彼は私たちのプロジェクトに賛同しており、名前の再利用に協力して下さいました。

Prebuilt との営み​

バージョン 1.3.1 では、electron と electron-prebuilt のパッケージを npm に同時公開するようになりました。 2 つのパッケージは同じです。 現在プロジェクトで electron-prebuilt を使用している数多の開発者のために、しばらくの間、両方の名前でパッケージを公開することを決めました。 新しい electron に依存するように package.json ファイルを更新することを推奨しますが、 2016 年末までは新しいバージョンの electron-prebuilt もリリースされます。

electron-userland/electron-prebuilt は electron npm パッケージに対する正規のホームリポジトリとして残ります。

謝辞​

@mafintosh には特別な感謝を捧げます。 @maxogden をはじめとする多くの 貢献者の方々 には、electron-prebuilt の作成と保守、そして JavaScript、Node.js、Electron コミュニティへのたゆまぬご協力に感謝します。

そして npm で electron パッケージを引き取らせてくれた @logicalparadox に感謝します。

プロジェクトの更新​

この変更に影響される人気のパッケージを更新するために、コミュニティと協力してきました。 electron-packager 、 electron-rebuild 、 electron-builder のようなパッケージは、古い名前をサポートしつつ、既に新しい名前で動作するように更新されています。

新しいパッケージをインストールするときに何らかの問題が発生した場合、 electron-userland/electron-prebuilt リポジトリに Issue を開いてお知らせください。

Electron に関する他の問題については、 electron/electron リポジトリを使用してください。