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

via GIPHY

12 月でも変わらないこと​

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

12 月で変わること​

1. 2024's last stable branch releases for the year, which include Electron 31, 32, and 33, will occur the week of December 1st. There will be no additional planned releases in December.
2. 12 月の最後の 2 週間は、ナイトリーやアルファのリリースはありません。
3. いくつかの例外を除いて、プルリクエストのレビューやマージはしません。
4. どのリポジトリでも Issue トラッカーは更新されません。
5. メンテナからの Discord デバッグのヘルプはありません。
6. ソーシャルメディアコンテンツの更新はありません。

皆さん、2025 年にまたお会いしましょう!

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

electron/electron リポジトリへの最初のコミットは 2013 年 3 月 13 日でした¹。

その後、10 年の歳月と 1192 人の貢献者による 27,147 以上のコミットを経て、今日 Electron はデスクトップアプリケーションを構築する最も人気のフレームワークの 1 つとなっています。 この節目は、これまでの歩みを祝って振り返り、その過程で学んだことを共有する絶好の機会です。

今があるのは、このプロジェクトへ貢献しようと時間に労力を捧げてくださった皆さまのおかげです。 ソースコードのコミットは最も目立つ貢献ですが、バグ報告、ユーザーランドモジュールのメンテナンス、ドキュメントや翻訳の提供、サイバースペースでの Electron コミュニティへの参加など、人々のそういった努力も認めなければなりません。 すべての貢献は私たちメンテナーにとってかけがえのないものです。

記事の続きの前に一言、御礼申し上げます。 ❤️

ここまでどうやって到達できたのでしょうか？​

Atom Shell は、2014 年 4 月にパブリックベータを開始した GitHub の Atom エディタ の基盤として作られました。 当時利用可能だったウェブベースのデスクトップフレームワーク (node-webkit や Chromium Embedded Framework) に代わるものとして、ゼロから構築されたものです。 驚くべき機能としては、Node.js と Chromium を組み込むことでウェブ技術向けの強力なデスクトップランタイムを提供していました。

1 年も経たないうちに、Atom Shell の性能と人気は絶大なものになりました。 大企業、スタートアップ、そして個人開発者たちがこぞって Electron でアプリを作り始め (初期の採用企業は Slack、GitKraken、WebTorrent など)、このプロジェクトは Electron という適切な名前に変更されました。

それ以来、Electron は本格的に活動してきました。 週間ダウンロード数の変化は、こちらの npmtrends.com のご好意によってご覧いただけます。

Electron v1 は 2016 年にリリースされ、API の安定性の向上とドキュメントやツールの充実を約束しました。 2018 年にリリースされた Electron v2 は、セマンティックバージョニングを導入し、Electron の開発者がリリースサイクルを把握しやすくなりました。

Electron v6 では、Chromium と同じ 12 週間の定期メジャーリリースケジュールに移行しました。 この決定はプロジェクトの考え方において「Chromium のバージョンを最新にする」ということを必須事項から優先事項に変えました。 これによりアップグレード間の技術的負債が減り、Electron の更新と堅牢性の維持が容易になりました。

それ以来、Electron の新バージョンを Chromium の安定版と同じ日にリリースするという、よくできた仕組みになっています。 2021 年に Chromium がリリーススケジュールを 4 週間に早めた時には、私たちは肩をすくめて、それに合わせてリリースケーデンスを8週間に増やすことにしました。

Electron は現在 v23 であり (そしてこれからも増え続ける)、クロスプラットフォームのデスクトップアプリケーションを構築するための最高のランタイムを構築することに専念しています。 近年、JavaScript の開発ツールがブームになっていますが、Electron はデスクトップアプリケーションのフレームワークとして、安定しており実戦投入され頑丈であり続けています。 Electron アプリは今やどこにでもあります。Visual Studio Code でプログラミング、Figma でデザイン、Slack でコミュニケーション、Notion でメモ (他にも多くの使用例があります)。 私たちはこの業績を非常に誇りに思うと同時に、助力して頂いたすべての人に感謝しています。

この過程で何を学んだのでしょうか？​

10 年という節目を迎えるまでの道のりは、長いものでした。 ここでは、持続可能な大規模オープンソースプロジェクトの運営に役立った主なものを紹介します。

ガバナンスモデルで分散された意思決定をスケールする​

Electron が爆発的に普及した後、私たちの克服すべき課題はプロジェクトの長期的な方向性をどうするかでした。 会社や国、タイムゾーンを越えて分散している数十人のエンジニアのチームを、どのように指揮すればよいのでしょうか。

初期の頃、Electron のメンテナーグループはインフォーマルな調整に頼っていました。小規模なプロジェクトでは高速かつ軽量ですが、より広範な協働作業にはスケールしません。 2019 年には、異なるワーキンググループがフォーマルな責任領域を担うガバナンスモデルに移行しました。 これは、プロセスを効率化し、プロジェクトの所有権の一部を特定のメンテナーに割り当てるのに役立っています。 それぞれのワーキンググループ (WG) は、今日ではどのような役割を担っているのでしょうか？

• Electron のリリースの広報 (Releases WG)
• Chromium と Node.js のアップグレード (Upgrades WG)
• 公開 API のデザインの管理 (API WG)
• Electron の堅牢性の維持 (Security WG)
• ウェブサイトの運営、ドキュメント化、ツール作成 (Ecosystem WG)
• コミュニティと企業への働きかけ (Outreach WG)
• コミュニティのモデレーション (Community & Safety WG)
• ビルドインフラ、メンテナーのツール、クラウドサービスの維持管理 (Infrastructure WG)

ガバナンスモデルに移行したのと同じ頃、Electron の所有権も GitHub から OpenJS Foundation に 移行しました。 元々のコアチームは現在もMicrosoftで働いていますが、彼らはElectronの管理体制を形成する、より大きな協力者のグループの一部に過ぎません。²

このモデルは完璧ではありませんが、世界的パンデミックやマクロ経済の逆風が続く中で、私たちによく適していました。 今後は、Electron を次の 10 年に繋げるために、ガバナンス憲章を改訂していく予定です。

コミュニティ​

オープンソースにおけるコミュニティの分野は難しいです。アウトリーチのチームが「コミュニティマネージャー」と書かれたトレンチコートを着た十数人のエンジニアである場合は特に難しくなります。 とはいえ、大規模なオープンソースプロジェクトであるということは、多くのユーザーを抱えているということであり、彼らの Electron に対するエネルギーを活用してユーザーランドのエコシステムを構築することは、プロジェクトの健全性を維持する上で極めて重要な要素です。

コミュニティの活気を高めるために、どのようなことを行ってきたのでしょうか。

バーチャルコミュニティの構築​

• 2020 年に、コミュニティ Discord サーバーを立ち上げました。 以前は Atom のフォーラム欄がありましたが、よりインフォーマルなメッセージングプラットフォームを用意し、メンテナと Electron 開発者間の議論や一般的なデバッグのヘルプのためのスペースを用意することにしました。
• 2021 年には、@BlackHole1 の協力で Electon China というユーザーグループを設立しました。 このグループは、Electron の英語スペースの外でアイデアを出し合ったり Electron について議論したりする場を提供し、中国の活気ある技術市場からのユーザー増加に貢献しています。 また、npm の中国語ミラーである cnpm で Electron のナイトリーのリリースをサポートして頂いたことにも感謝します。

注目度の高いオープンソースプログラムへの参加​

• 2019 年から毎年、Hacktoberfest に参加しています。 Hacktoberfest は、DigitalOcean が毎年開催しているオープンソースの祭典で、オープンソースソフトウェアに自分の足跡を残そうとする熱心な貢献者が毎年何十人も集まっています。
• 2020 年には、Google Season of Docs の初期のイテレーションに参加し、@bandantonio の協力の下で Electron の新しいユーザーチュートリアルのフローを作り直しました。
• 2022 年には、初めて Google Summer of Code の学生のメンターをしました。 @aryanshridhar は、Electron Fiddle のコアのバージョン読み込みロジックをリファクタリングし、そのバンドラを webpack に移行する、素晴らしい働きをしてくださいました。

あらゆるものの自動化！​

現在、Electron のガバナンスには約 30 人のアクティブなメンテナがいます。 フルタイムで貢献している人は半分以下なので、あれもこれもと仕事が多いことになります。 すべてを円滑に進めるコツは何でしょうか？ 私たちのモットーは、コンピュータは安い、人の時間は高い、です。 典型的なエンジニアの活動において、より活動を快適にするための自動化サポートツール群を開発しました。

Not Goma​

Electron のコアとなるコードベースは巨大な C++ コードの塊であり、そのビルド時間はバグ修正や新機能をいかに早く送り出せるかの制限要因となっていました。 2020 年には、Google の分散コンパイラサービス Goma の Electron 専用カスタムバックエンドである Not Goma をデプロイしています。 Not Goma は、認可されたユーザーのマシンからのコンパイル要求を処理し、バックエンドの数百のコアに処理を分散させます。 また、コンパイル結果をキャッシュしておくことで、同じファイルをコンパイルする他の人はそのコンパイル済み結果をダウンロードするだけでよくなります。

Not Goma の立ち上げ以降、メンテナのコンパイル時間が数時間の規模から数分に短縮されました。 安定したインターネット接続さえあれば、Electron をコンパイルできるようになりました！

Continuous Factor Authentication​

Continuous Factor Authentication (CFA) は npm の二要素認証 (2FA) システムの自動化レイヤーで、semantic-release と組み合わせて様々な @electron/ npm パッケージの安全な自動リリースを管理します。

semantic-release でも npm パッケージの公開プロセスは自動できますが、これだけでは二要素認証をオフにするか制限を回避するシークレットトークンを渡す必要があります。

私たちは npm の 2FA の時間ベースのワンタイムパスワード (TOTP) を任意の CI ジョブに配信する CFA を構築し、二要素認証の追加セキュリティを維持しながら semantic-release の自動化を活用できるようにしました。

これには Slack での統合フロントエンドを備えた CFA を使用しています。これによりメンテナは、TOTP ジェネレータが手元にあれば Slack のあるどのデバイスからでもパッケージの公開を検証できます。

Sheriff​

Sheriff は、GitHub、Slack、Google Workspace 全体での権限管理を自動化するために私たちが書いたオープンソースのツールです。

Sheriff の重要な価値提案は、権限管理は透明性のあるプロセスであるべきだということです。 これは上記のすべてのサービスにまたがって権限を指定するために、単一の YAML 設定ファイルを使用します。 Sheriff を使えば、PR を承認してマージするのと同じくらい簡単に、レポジトリのコラボレーターの状況を取得したり、新しいメーリングリストを作成したりできます。

Sheriff には Slack に投稿される監査ログもあり、Electron の組織内のどこかで不審な動きがあったときに管理者へ警告できます。

…そしてすべての GitHub ボット​

GitHub は豊富な API 拡張性を持つプラットフォームであり、Probot というファーストパーティのボットアプリケーションフレームワークを提供しています。 私たちがより創造的な仕事に集中できるよう、私たちの代わりに単純作業をこなしてくれる小さいボット群を構築しています。 以下にいくつかの例を示します。

• Sudowoodo は Electron のリリースプロセスの最初から最後まで、ビルドのキックオフから GitHub と npm へのリリースアセットのアップロードまでを自動化します。
• Trop は、GitHub の PR ラベルに基づいて以前のリリースブランチへのパッチの cherry-pick を試みることで、Electron のバックポートプロセスを自動化します。
• Roller は、Electron の Chromium と Node.js の依存関係のローリングアップグレードを自動化します。
• Cation は、electron/electron の PR のステータスを確認するボットです。

このような小さなボット家族のおかげで、開発者の生産性が大幅に向上しました！

今後の予定は?​

プロジェクトとして次の 10 年を迎えるにあたって、疑問に思われることでしょう。Electron はこれからどうなるのでしょうか？

私たちは、Chromium のリリースケイデンスに同期して 8 週間ごとに Electron の新しいメジャーバージョンをリリースし、エンタープライズ級のアプリケーションの安定性と堅牢性を維持しながら、ウェブプラットフォームと Node.js による最新で最高のフレームワークを保ち続けます。

今後の取り組みについては基本的に、具体的になった時点でお知らせします。 今後のリリース、機能、一般的なプロジェクトの更新について知りたい方は、ブログ をご覧頂くか、ソーシャルメディアのプロフィール (Twitter や Mastodon) をフォローしてください!

Electron は、Electron 23 からWindows 7、Windows 8、Windows 8.1 のサポートを終了します。

Chromium の非推奨化の方針 に基づき、Electron は Electron 23 から Windows 7、Windows 8 および Windows 8.1 のサポートを終了します。 これは、マイクロソフトが 2023 年 1 月 10 日付の Windows 7 ESU と Windows 8.1 extended のサポート終了に合わせています。

Electron 22 は、10 より古いバージョンの Windows をサポートする最後の Electron メジャーバージョンとなります。 Electron 23 以降のメジャーリリースでは、Windows 7/8/8.1 には対応しません。 旧バージョンの Electron は Windows 7 上でも引き続き動作し、Electron 22.x 系列のパッチは Electron が 22.x のサポートを終了する 2023 年 5 月 30 日までリリースし続けます (サポートタイムライン より)。

なぜ非推奨になるのでしょうか?​

Electron は Chromium の非推奨化の方針の予定に従っており、これは Chromium 109 でサポートを終了します (Chromium のタイムラインについて詳しくはこちら)。 Electron 23 には Chromium 110 が搭載され、古いバージョンの Windows には対応しなくなります。

そのため、Chromium 108 を搭載した Electron 22 が最後のサポートバージョンとなります。

非推奨のタイムライン​

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

• 2022 年 12 月: Electron チームは年末年始の休養期になります
• 2023 年 1 月: Windows 7 & 8 関連の問題はサポート中の全リリースブランチで受け付けます。
• 2023 年 2 月 7 日: Electron 23 がリリースされます。
• 2023 年 2 月 8 日 - 2023 年 5 月 29 日: Electron は Electron 23 以前のサポート対象の系列について引き続き修正を受け付けます。
• 2023 年 5 月 30 日: Electron 22 のサポートサイクルが終わりを迎えます。

開発者にとっての意義:

• Electron チームは、安定版のサポート対象系列の Windows 7/8/8.1 に関する問題および修正を、各系列のサポートサイクルが終了するまで受け付けます。
  • これは具体的には、Electron 22、Electron 21、Electron 20 に適用されます。
• Windows 7/8/8.1 に関する新たな Issue は、Electron 23 より古い Electron バージョンで受け付けます。
  • 新規 Issue はそれ以降のリリース系列では受け付けられません。
• Electron 22 のサポートが終了した時点で、Windows 7/8/8.1 に関する既存の Issue はすべて Close されます。

今後の予定​

ご質問やご不明な点がございましたら、info@electronjs.org までお気軽にお問い合わせください。 公式の Electron Discord でコミュニティのサポートも受けられます。

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

GIPHY より

12 月でも変わらないこと​

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

12 月で変わること​

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

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

2021 年 12 月の安息月の成功を受けて、2022 年にも実施したいとの要望がありました。 12 月は多くの企業にとって引き続き安息月であるため、私たちはメンテナに英気を養う機会を与えたいと考えています。 開発者一同 2023 年が楽しみで、きっと良いことが起こると期待しています! 他のプロジェクトでも同様の措置を検討していただければ幸いです。

先月、Electron のメンテナグループがカナダのバンクーバーに集まり、2023 年以降のプロジェクトの方向性について話し合いました。 4 日間にわたる会議で、コアメンテナや招待された共同研究者が、新しい取り組みやメンテナンスの問題点、プロジェクト全般の健全性などについて話し合いました。

今後も、私たちチームは定期的かつ迅速な Chromium アップグレードのリリース、バグの修正、そして Electron をより安全で高性能なものにすることに全力を注いでいきます。 また、いくつかのエキサイティングなプロジェクトも進行中ですので、ぜひコミュニティの皆さんと共有したいと思います。

革新的な新 API​

Electron プロジェクトにおける主要な API 提案のうち、合意形成が必要なものは RFC (Request for Comments) のプロセスを経て、API 作業グループのメンバーによってレビューされます。

今年は、Electron アプリの新次元を切り開く可能性を秘めた、2 つの大きな提案を推進しました。 これらの提案は非常に実験的なものですが、ここではその一部を垣間見てみましょう!

新しいネイティブアドオンの機能強化 (C API)​

この提案は、Node の Node-API と同様に、アプリ開発者が Electron の内部リソースと連携する独自のネイティブ Node アドオンを作成できるようにするための Electron C API の新しいレイヤーについての骨子です。 新 API 案の詳細については、こちらからご覧いただけます。

例: Chromium のリソースでアプリを強化する​

多くの Electron アプリは、バニラの (変更されていない) Electronではアクセスできない Chromium 内部と直接対話するために、独自のフォークをメンテナンスしています。 これらのリソースを C API レイヤーで公開することで、このコードを Electron のネイティブモジュールとして共存させることができ、アプリ開発者のメンテナンスの負担を軽減できる可能性があります。

Chromium の UI レイヤーの公開 (Views API)​

Chrome のツールバー、タブ、ボタンなどのユーザーインターフェース (UI) のうち、ウェブサイト以外の部分は Views と呼ばれるフレームワークで構築されています。 Views API の提案は、このフレームワークの一部を Electron の JavaScript クラスとして導入し、開発者が Electron アプリケーションに非ウェブ UI 要素を作成できるようにすることを最終的な目標としています。 これにより、アプリがウェブコンテンツを改造する手間を省くことができます。

この新しい API を実現するための下準備が現在進行中です。 ここでは、近い将来に最初から期待できる機能をご紹介します。

例: WebContentsView でのウインドウモデルのリファクタ​

最初に予定している変更は、Chrome の WebContentsView を Electron の API で表向きに公開することです。これは既存の BrowserView API (名前に反して Chromium Views とは関係のない Electron 固有のコード) の後継となるものです。 WebContentsView が公開されれば、ウェブコンテンツを表示できる再利用可能な View オブジェクトができ、BrowserWindow クラスを純粋な JavaScript にする道が開かれ、さらにコードの複雑性が解消されます。

この変更はアプリ開発者に多くの新機能を提供するものではありませんが、舞台裏の多くのコードを削除する大規模なリファクタリングであり、Chromium のアップグレードを簡素化してメジャーバージョン間で新しいバグが現れるリスクを低減します。

もし BrowserView を使用している Electron 開発者の方でしたら、心配いりません。あなたのことも忘れていませんよ! 既存の BrowserView クラスを WebContentsView の緩衝材として、新しい API に移行する際のバッファとすることを計画しています。

参照: electron/electron#35658

例: ScrollView でスクロール可能なウェブコンテンツ​

Stack に取り組んでいる友人は、Chromium の ScrollView コンポーネントを Electron の API に公開する取り組みを推進しています。 この新しい API により、任意の子 View コンポーネントを水平または垂直方向へスクロール可能にできます。

この新しい API は 1 つの小さな機能を満たすものですが、チームの最終的な目標は、より複雑な非 HTML インターフェースを構築するためのツールキットとして使用できる、ユーティリティ View コンポーネントの集合体を構築することです。

活動に参加する​

Electron アプリの開発者の方でいらっしゃいましたら、これらの API 提案のどちらかに興味をお持ちいただけましたか? まださらなる RFC の受付は完了しておりませんが、今後の詳細についてもぜひご期待ください!

Electron Forge v6 安定版リリース​

このフレームワークの創始以来、Electron のビルドツールのエコシステムは主にコミュニティ主導で、多くの小さな単一目的のパッケージ (electron-winstaller、electron-packager、electron-notarize、electron-osx-sign など) で構成されてきました。 これらのツールはうまくいっていますが、ビルドパイプラインの構築はユーザーにとって気が重いものです。

Electron の開発者にとってより使いやすい環境を構築するために、私たちは Electron Forge という既存のツール群を一つのインターフェースにまとめたオールインワンのソリューションを構築しました。 Forge は 2017 年から開発されていましたが、プロジェクトはここ数年休止状態でした。 しかし、Electron のビルドツールの状態に関するコミュニティのフィードバックを受け、私たちは Forge の次世代安定メジャーバージョンのリリースに懸命に取り組んでいます。

Electron Forge 6 は、第一級の TypeScript と Webpack サポート、開発者が独自のプラグインやインストーラーを作成できる拡張性の高い API を搭載しています。

お楽しみに: またすぐにお知らせできます​

Forge を使ったプロジェクトの構築、または Forge の拡張可能なサードパーティ API を使ったテンプレートやプラグインの構築に興味がある方は、今月中に行われる Forge v6 安定版リリースに関する公式アナウンスをお待ちください!

今後の予定は?​

上記以外にも、アプリ開発者やエンドユーザーにとって Electron の体験をより良いものにするために、私たちチームは常にたくさんの予備的プロジェクトを考えています。 更新ツール、API レビュープロセス、ドキュメントの強化なども私たちは実験しています。 近い将来、さらに多くのニュースをお伝えしたいと思います!

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

Electron 21 では、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 ヒープ外でのメモリ割り当て (例えば malloc や new の使用) を行い、その外部メモリを 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 21 以降をサポートしたいです。 どうすればいいですか？​

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 をガベージコレクトし、解放後に使用してしまうエラーを引き起こす可能性があります。

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

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

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

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

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

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 年が楽しみで、きっと良いことが起こると期待しています!

2021 年 9 月から、Electron は 8 週間ごとに新規メジャー安定版をリリースするようになります。

2019 年、Chromium の 6 週間のリリースサイクルに合わせて Electron は 12 週間のリリースサイクルに移行 しました。 先日、Chrome と Microsoft の両方が変更を発表し、Electron の現在のリリースサイクルを再考することになりました。

1. Chromium は、2021 年 9 月 21 日の Chrome 94 を皮切りに、4 週間 ごとに新規マイルストーンをリリースする予定です。また、このリリースサイクルでは 8 週間ごとに新しい拡張安定版オプションが追加され、すべてのセキュリティ修正が更新されます。

2. Microsoft Store では、Chromium ベースのアプリが最新から 2 つのメジャーバージョン以内であることを要求するようになります。 例えば、Chromium の最新のメジャーバージョンが 85 の場合、Chromium をベースにしたブラウザは最低でも Chromium バージョン 83 以上でなければなりません。 このルールは Electron アプリも含みます。

Chromium の 8 週間の拡張安定版リリースに合わせて、Electron は 2021 年 9 月より 8 週間ごとに新しいメジャー安定版をリリースする予定です。

Chromium 拡張安定版での最初のリリースは、Electron 15 の 2021 年 9 月 21 日 になります。

リリースケイデンスの変更は下流の他のアプリケーションにも影響を与えることがわかっているため、できるだけ早く開発者コミュニティに知らせたいと思っております。 2021 年のリリーススケジュールの詳細はこちらをご覧ください。

Electron 15: 臨時アルファ​

当初の Electron 15 のリリースは拡張安定版ではないバージョンを対象としていたため (Chromium の拡張安定版バージョンは偶数番号のバージョンをベースにしています)、当初の目標リリース日を変更する必要がありました。 しかし、Electron アプリを Microsoft Store に登録するためには Chromium の最新から 2 つ以内のメジャーバージョンを使用する必要がありましたが、Chromium のバージョンを 2 つ待つことはできません。

この 2 つの要件を満たそうと、チームはタイミングのジレンマに陥りました。 Electron 15 に Chromium M94 を搭載することで、アプリケーション開発者は Chromium の最初の拡張安定版バージョンを利用できるようになりますが、ベータ版から安定版へのサイクルはわずか 3 週間にまで短くなります。

この切り替えを支援するため、Electron は Electron 15 リリースのみを対象とした臨時の アルファビルド を提供します。 このアルファビルドは開発者が Electron 15 のリリースに向けてテストや計画を立てるための時間を確保するためのもので、現在の nightly よりも安定したビルドになっています。

このアルファチャンネルビルドは、Electron 15 として 2021 年 7 月 20 日 に頒布されます。 2021 年 9 月 1 日 にベータ版リリースに移行し、2021 年 9 月 21 日 に安定版リリースを行う予定です。 その後の Electron のリリースではアルファ版のリリースはありません。

2021 年のリリース計画​

現在の 2021 年のリリース予定は以下の通りです。

アルファチャンネルの追加により、Electron 15 のリリースまでの開発期間は 3 週間から 9 週間に延長されました。新しい 8 週間のサイクルに近づきつつ、Windows Store への提出要件を満たせます。

アプリ開発者をさらに支援するために、2021 年の残りの期間から 2022 年 5 月まで、サポートされるバージョンのポリシーを最新 3 バージョンから最新 4 バージョンの Electron に拡張することも決定しました。つまり、アップグレードのスケジュールをすぐに変更できなくても、古いバージョンの Electron にはセキュリティアップデートや修正プログラムが提供されるということです。

懸念事項への対応​

リリースサイクルの変更予定よりかなり前に、この記事を公開しているのには理由があります。 リリースサイクルの高速化は、Electron アプリに大きな影響を与えると考えています。中には、私たちのメジャーリリースのペースがすでに積極的すぎると感じている人もいるかもしれません。

以下に、よくある質問をまとめてみました。

❓ なぜこの変更を行うのでしょうか? 12 週間のリリース周期を維持しないのですか?​

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

加えて、現在の 12 週間のリリースサイクルでは、Microsoft Store の新しい提出要件に対応できません。 Electron の最新の安定版を使用しているアプリであっても、約 2 週間の間は新しいセキュリティ要件によりアプリが拒否される可能性があります。

Chromium の各新規リリースには、新機能、バグ修正/セキュリティ修正、V8 の改善が含まれています。 アプリ開発者の皆様にはこれらの変更をタイムリーに受けていただきたいので、安定版のリリース日は他の Chromium 安定版のリリース日と一致させています。 アプリケーション開発者は、Chromium や V8 の新機能や修正に、これまでよりも早くアクセスできるようになります。

❓ 既存の 12 週間のリリーススケジュールでも、既に早いです。 アップグレードを容易にするには、チームでどのような段階を踏めばよいでしょうか?​

より頻繁にリリースすることの利点は、より小さい リリースができることです。 Electron のメジャーバージョンのアップグレードは大変だと思います。 リリースを小さくするほど、1 回のリリースにおける Chromium や Node のメジャーの変更や破壊的変更が少なくなることを期待しています。

❓ 今後の Electron のバージョンに対応したアルファ版のリリースはありますか?​

現時点では、恒久的にアルファリリースをサポートする予定はありません。 このアルファは Electron 15 のみを対象としており、短いリリース期間の中で開発者がより簡単にアップグレードできるようにするためのものです。

❓ Electron はバージョンのサポート数を増やしていくのでしょうか?​

2022 年 5 月の Electron 19 のリリースまでは、サポートバージョンポリシーを最新 3 つから最新 4 つのバージョンに拡張する予定です。 Electron 19 のリリース後は、ベータや nightly リリースと同じく 最新のメジャーバージョン 3 つ をサポートする体制に戻ります。

質問?​

📨 ご質問やご不明な点がございましたら、info@electronjs.org までメールでお問い合わせしていただくか、Discord に参加して ご連絡ください。 この変更が多くのアプリケーションや開発者に影響を与えることは承知しており、皆様からのフィードバックは私たちにとって非常に重要です。 ご連絡をお待ちしております!