Electronプロジェクトは2023年12月は一時停止し、2024年1月にフルスピードで再開します。

via 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エディター のバックボーンとして構築されました。当時利用可能だったWebベースのデスクトップフレームワーク（node-webkitとChromium Embedded Framework）の代替として、ゼロから構築されました。キラー機能がありました。それは、Node.jsとChromiumを埋め込み、Webテクノロジーに強力なデスクトップランタイムを提供することです。

1年以内に、Atom Shell は機能と人気が大幅に向上し始めました。大企業、スタートアップ、個人開発者も同様に、それを使ってアプリを構築し始めていました（初期の採用者には、Slack、GitKraken、WebTorrent などがあります）。そして、プロジェクトは適切に Electron に名前が変更されました。

それ以来、Electron は走り出し、止まることはありませんでした。これは、npmtrends.com の提供による、時間の経過に伴う週ごとのダウンロード数です。

Electron v1 は 2016 年にリリースされ、API の安定性の向上とドキュメントとツールの改善を約束しました。Electron v2 は 2018 年にリリースされ、セマンティックバージョニングが導入され、Electron 開発者がリリースサイクルを簡単に追跡できるようになりました。

Electron v6 までに、Chromium に合わせて、12 週ごとの定期的なメジャーリリースサイクルに移行しました。この決定は、プロジェクトのメンタリティの変化であり、「最新の Chromium バージョンを搭載すること」を、あって嬉しいものから優先事項へと変えました。これにより、アップグレード間の技術的負債が減少し、Electron の更新とセキュリティ保護を維持することが容易になりました。

それ以来、私たちは順調に動き、すべてのChromiumの安定版と同じ日に新しいElectronバージョンをリリースしています。2021年にChromiumがリリーススケジュールを4週間に短縮したときまでに、私たちは肩をすくめて、それに応じてリリースサイクルを8週間に増やすことができました。

私たちは現在、Electron v23（そして今後も増え続ける）を使用しており、クロスプラットフォームのデスクトップアプリケーションを構築するための最高のランタイムを構築することに尽力しています。近年、JavaScript開発者ツールが急増しているにもかかわらず、Electronはデスクトップアプリフレームワークの分野において、安定した、実戦でテスト済みの確固たる存在であり続けています。Electronアプリは今日ではどこにでも存在します。Visual Studio Codeでプログラミングをしたり、Figmaでデザインをしたり、Slackでコミュニケーションをとったり、Notionでメモをとったりすることができます（その他多くのユースケースがあります）。私たちはこの成果を非常に誇りに思っており、それを可能にしてくれたすべての人々に感謝しています。

ここまでの道のりで何を学んだでしょうか？​

10年という節目を迎えるまでの道のりは長く、曲がりくねったものでした。持続可能な大規模オープンソースプロジェクトを運営する上で役立った重要な点をいくつか紹介します。

ガバナンスモデルによる分散型意思決定の拡大​

私たちが克服しなければならなかった課題の1つは、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に移管しました。元のコアチームは現在もマイクロソフトに在籍していますが、彼らはElectronガバナンスを形成するより大きな協力者グループの一部にすぎません。²

このモデルは完璧ではありませんが、世界的なパンデミックと進行中のマクロ経済の逆風の中で、私たちによく適合してきました。今後は、Electronの20年目を導くために、ガバナンス憲章を刷新する予定です。

コミュニティ​

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

コミュニティでの存在感を高めるために、私たちはどのような活動をしてきたのでしょうか？

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

• 2020年、私たちはコミュニティDiscordサーバーを立ち上げました。以前はAtomのフォーラムにセクションがありましたが、メンテナーとElectron開発者間の議論や一般的なデバッグヘルプのためのスペースを設けるために、より非公式なメッセージングプラットフォームを導入することにしました。
• 2021年、私たちは@BlackHole1の協力を得て、Electron Chinaユーザーグループを設立しました。このグループは、中国の急成長する技術シーンからのユーザーのElectronの成長に不可欠な役割を果たしており、アイデアを共同で検討したり、英語圏以外の場所でElectronについて話し合ったりするためのスペースを提供しています。また、npmの中国語ミラーでElectronのナイトリーリリースをサポートしてくれたcnpmにも感謝します。

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

• 私たちは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をコンパイルするための最低限の要件となりました！

継続的二要素認証​

継続的二要素認証（CFA）は、npmの二要素認証（2FA）システムの周辺の自動化レイヤーであり、semantic-releaseと組み合わせて、さまざまな@electron/ npmパッケージの安全かつ自動化されたリリースを管理します。

semantic-releaseはすでにnpmパッケージの公開プロセスを自動化していますが、二要素認証をオフにしたり、この制限をバイパスする秘密トークンを渡したりする必要があります。

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

私たちはCFAをSlack統合フロントエンドで使用しており、メンテナーはTOTPジェネレーターを手元に持っていれば、Slackを使用できる任意のデバイスからパッケージの公開を検証できます。

Sheriff​

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

Sheriffの主な価値提案は、権限管理が透明なプロセスであるべきだということです。上記にリストされたすべてのサービス全体で権限を指定する単一のYAML設定ファイルを使用します。Sheriffを使用すると、リポジトリで共同作成者のステータスを取得したり、新しいメーリングリストを作成したりすることが、PRを承認してマージするのと同じくらい簡単になります。

Sheriffには、Slackに投稿される監査ログもあり、Electron組織内のどこかで不審なアクティビティが発生した場合に管理者に警告します。

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

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

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

全体として、私たちの小さなボットファミリーは、開発者の生産性を大幅に向上させてくれました！

次は？​

プロジェクトとして2回目の10年を迎えるにあたり、Electronの次はどうなるのか？と疑問に思われるかもしれません。

私たちは、Chromiumのリリース頻度に合わせて、Electronの新しいメジャーバージョンを8週間ごとにリリースし、エンタープライズグレードのアプリケーションの安定性とセキュリティを維持しながら、最新かつ最高のWebプラットフォームと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のサポートを終了します。これは、MicrosoftによるWindows 7 ESUおよびWindows 8.1拡張の2023年1月10日のサポート終了と一致しています。

Electron 22は、10より古いWindowsバージョンをサポートする最後のElectronメジャーバージョンになります。Windows 7/8/8.1は、Electron 23以降のメジャーリリースではサポートされません。古いバージョンのElectronはWindows 7で引き続き機能し、Electron 22.xシリーズのパッチは、2023年5月30日にElectronが22.xのサポートを終了するまでリリースし続けます(当社のサポートタイムラインに従って)。

廃止の理由​

Electronは、Chromium 109でサポートを廃止する計画されたChromium廃止ポリシーに従います(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に関連する新しい問題は、Electron 23より古いElectronバージョンで受け入れられます。
  • 新しい問題は、新しいリリースラインでは受け入れられません。
• Electron 22がサポートサイクルの終了に達すると、Windows 7/8/8.1に関連する既存のすべての問題がクローズされます。

次は何ですか​

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

Electronプロジェクトは2022年12月は一時停止し、2023年1月に全速力で戻ります。

via 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提案は、APIワーキンググループのメンバーによってレビューされるRequest for Comments(RFC)プロセスを経ます。

今年は、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)のWebサイト以外の部分は、Viewsと呼ばれるフレームワークで構築されています。Views APIの提案では、このフレームワークの一部をElectronのJavaScriptクラスとして導入し、最終的には開発者がWeb以外のUI要素をElectronアプリケーションに作成できるようにすることを目指しています。これにより、アプリがWebコンテンツをハックする必要がなくなります。

この新しいAPIセットを可能にするための基礎は現在進行中です。近い将来に期待できる最初のことを以下に示します。

例：WebContentsViewでウィンドウモデルをリファクタリングする​

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

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

アプリでBrowserViewsを使用しているElectron開発者の方は、ご心配なく。既存のBrowserViewクラスをWebContentsViewのシムにして、新しいAPIへの移行時のバッファを提供することを計画しています。

参照：electron/electron#35658

例：ScrollView を使用したスクロール可能なウェブコンテンツ​

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

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

参加する​

これらのAPI提案のいずれかに興味のあるElectronアプリの開発者ですか？追加のRFCを受け入れる準備はまだできていませんが、今後の詳細についてはご期待ください！

Electron Forge v6 安定版リリース​

Electron のフレームワークの発足以来、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では、Chrome の Chrome 103 での決定 に従い、Electron で V8 サンドボックスポインタ を有効にする予定です。これには、ネイティブモジュールにいくつかの影響があります。また、以前に、関連技術である ポインタ圧縮 を Electron 14 で有効にしました。当時、あまり話題にはしませんでしたが、ポインタ圧縮は V8 ヒープの最大サイズに影響を与えます。

これらの 2 つの技術は、有効にすると、セキュリティ、パフォーマンス、メモリ使用量に非常に有益です。ただし、有効にすることにはいくつかの欠点もあります。

サンドボックスポインタを有効にする主な欠点は、外部（「オフヒープ」）メモリを指す ArrayBuffer が許可されなくなることです。これは、V8 でこの機能に依存しているネイティブモジュールは、Electron 20 以降で動作を継続するためにリファクタリングする必要があることを意味します。

ポインタ圧縮を有効にする主な欠点は、V8 ヒープが最大 4GB に制限されることです。この詳細については少し複雑です。たとえば、ArrayBuffer は V8 ヒープの残りの部分とは別にカウントされますが、独自の制限があります。

Electron Upgrades Working Group は、ポインタ圧縮とV8メモリケージの利点が欠点を上回ると考えています。そうする主な理由は 3 つあります。

1. Electron を Chromium に近づけます。V8 の構成などの複雑な内部の詳細で Electron が Chromium から乖離するほど、バグやセキュリティの脆弱性を誤って導入する可能性が低くなります。Chromium のセキュリティチームは手強く、彼らの成果を確実に活用したいと考えています。さらに、Chromium で使用されていない構成にのみ影響するバグの場合、修正は Chromium チームにとって優先順位が高くなる可能性は低いです。
2. パフォーマンスが向上します。ポインタ圧縮により、V8 ヒープサイズが最大 40% 削減され、CPU および GC のパフォーマンスが 5% ～ 10% 向上します。4GB のヒープサイズ制限に達することのない、外部バッファを必要とするネイティブモジュールを使用しないほとんどの Electron アプリケーションにとって、これらは大幅なパフォーマンス向上となります。
3. より安全です。一部の Electron アプリは信頼されていない JavaScript を実行します（セキュリティに関する推奨事項に従うことを願っています！）。これらのアプリでは、V8 メモリケージを有効にすることで、V8 の広範な脆弱性から保護されます。

最後に、本当に大きなヒープサイズが必要なアプリには回避策があります。たとえば、ポインタ圧縮が無効になっている状態でビルドされた Node.js のコピーをアプリに含め、メモリを大量に使用する処理を子プロセスに移動することができます。少し複雑ですが、特定のユースケースで異なるトレードオフが必要な場合は、ポインタ圧縮を無効にしてカスタムバージョンの Electron をビルドすることもできます。最後に、そう遠くない将来、wasm64 により、WebAssembly で構築された Web および Electron の両方のアプリは、4GB を大幅に超えるメモリを使用できるようになります。

FAQ​

アプリがこの変更の影響を受けるかどうかをどのように知ることができますか？​

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

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

アプリが4GB制限に近いかどうかを知るために、アプリが使用しているV8ヒープメモリの量をどのように測定できますか？​

レンダラープロセスでは、performance.memory.usedJSHeapSize を使用できます。これにより、V8 ヒープの使用量がバイト単位で返されます。メインプロセスでは、process.memoryUsage().heapUsed を使用できます。これは同等のものです。

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

一部のドキュメントでは「V8サンドボックス」と呼んでいますが、その用語は Chromium で発生する他の種類のサンドボックスと混同しやすいので、「メモリケージ」という用語を使用します。

次のような、かなり一般的な V8 エクスプロイトがあります。

1. V8 の JIT エンジンでバグを見つけます。JIT エンジンは、低速なランタイム型チェックを省略し、高速なマシンコードを生成できるようにコードを分析します。ロジックエラーにより、この分析が誤って行われ、実際には必要であった型チェックが省略される場合があります。たとえば、x が文字列であると考えていても、実際にはオブジェクトである場合です。
2. この混乱を悪用して、V8 ヒープ内のメモリの一部、たとえば ArrayBuffer の先頭へのポインタを上書きします。
3. これで、好きな場所を指す ArrayBuffer ができたので、V8 が通常アクセスできないメモリを含め、プロセス内の任意のメモリを読み書きできます。

V8 メモリケージは、この種の攻撃をカテゴリ的に防止するように設計された手法です。これを達成する方法は、V8 ヒープにポインタを格納しないことです。代わりに、V8 ヒープ内の他のメモリへのすべての参照は、予約された領域の先頭からのオフセットとして格納されます。次に、攻撃者が V8 の型混乱エラーを悪用するなどして、たとえば ArrayBuffer のベースアドレスを破損させることができたとしても、最悪の場合、ケージ内のメモリを読み書きすることしかできず、おそらくすでに可能でしょう。V8 メモリケージの仕組みについて読むべきことはたくさんあるので、ここでは詳しく説明しません。読み始めるのに最適な場所は、おそらく Chromium チームのハイレベルな設計ドキュメントでしょう。

Electron 21+をサポートするようにNodeネイティブモジュールをリファクタリングしたいのですが、どうすればよいですか？​

ネイティブモジュールをV8メモリケージと互換性を持たせるためにリファクタリングする方法は2つあります。1つ目は、外部で作成されたバッファをJavaScriptに渡す前に、V8メモリケージにコピーすることです。これは一般的に単純なリファクタリングですが、バッファが大きい場合は遅くなる可能性があります。もう1つの方法は、最終的にJavaScriptに渡す予定のメモリを割り当てるためにV8のメモリアロケータを使用することです。これは少し複雑ですが、コピーを回避できるため、大きなバッファのパフォーマンスが向上します。

これをより具体的にするために、外部配列バッファを使用するN-APIモジュールの例を次に示します。

// Create some externally-allocated buffer.
// |create_external_resource| allocates memory via malloc().
size_t length = 0;
void* data = create_external_resource(&length);
// Wrap it in a Buffer--will fail if the memory cage is enabled!
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);
// Create a new Buffer by copying the data into V8-allocated memory
napi_value result;
void* copied_data = NULL;
napi_create_buffer_copy(env, length, data, &copied_data, &result);
// If you need to access the new copy, |copied_data| is a pointer
// to it!

これにより、データは V8 メモリケージ内の新しく割り当てられたメモリ領域にコピーされます。オプションで、後で変更したり参照したりする必要がある場合に備えて、N-API は新しくコピーされたデータへのポインターを提供することもできます。

V8 のメモリアロケータを使用するようにリファクタリングするのは少し複雑です。なぜなら、create_external_resource 関数を、malloc を使用する代わりに V8 によって割り当てられたメモリを使用するように変更する必要があるからです。これは、create_external_resource の定義を制御しているかどうかによって、実現可能性が変わる可能性があります。アイデアとしては、まず V8 を使用して、例えば napi_create_buffer でバッファを作成し、V8 によって割り当てられたメモリにリソースを初期化することです。 リソースの有効期間中は、バッファオブジェクトへの napi_ref を保持することが重要です。そうしないと、V8 がバッファをガベージコレクションして、use-after-free エラーが発生する可能性があります。

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 で問題を提起し、お知らせください。

現在の gh-contractor-zcbenz S3 バケットは、積極的に削除されることはありません。ただし、そのバケットがいつまで存続するかは保証できません。できるだけ早く新しいバケットをターゲットにするように更新することを強くお勧めします。

Electron プロジェクトは、2021 年 12 月に一時停止し、2022 年 1 月にフルスピードに戻ります。

via 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 年に、Electron は Chromium の 6 週間ごとのリリースサイクルに合わせて 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 週間の拡張安定版リリースに合わせて、2021 年 9 月から、Electron は 8 週間ごとに新しいメジャー安定版をリリースします。

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

リリースサイクルの変更が他の下流アプリケーションに影響を与える可能性があることを認識しているため、開発者コミュニティにできるだけ早く知らせたいと思いました。2021 年のリリーススケジュールに関する詳細については、以下をお読みください。

Electron 15: 一時的なアルファ版​

元の Electron 15 のリリースが非拡張安定版 (Chromium の拡張安定版は偶数番号のバージョンに基づいています) をターゲットにしていたことを考えると、元のターゲットリリース日を変更する必要がありました。ただし、Electron アプリは Microsoft Store で受け入れられるためには、最新の 2 つのメジャーバージョンの Chromium を使用する必要があるため、2 つの Chromium バージョンを待つのは不可能でした。

これらの 2 つの要件により、私たちのチームはタイミングのジレンマに直面しました。Electron 15 を Chromium M94 を含めるように移行すると、アプリ開発者は Chromium の最初の拡張安定版を入手できるようになります。ただし、ベータ版から安定版へのサイクルも 3 週間のみに短縮されます。

この切り替えを支援するために、Electron は Electron 15 リリースのみを対象とした一時的なアルファ版ビルドを提供します。このアルファ版ビルドにより、開発者は、現在のナイトリーよりも安定したビルドで、Electron 15 リリースをテストおよび計画するための時間をより多く確保できます。

アルファチャネルビルドは、2021 年 7 月 20 日に Electron 15 用に出荷されます。これは、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 のスケジュールに合わせる必要があります。Chromium のリリースサイクルに関する詳細については、こちらをご覧ください。

さらに、現在の 12 週間ごとのリリースサイクルは、Microsoft Store の新しい提出要件では維持できません。最新の安定版の Electron を使用しているアプリでも、新しいセキュリティ要件の下では、アプリが拒否される可能性がある約 2 週間の期間が発生します。

すべての新しい Chromium リリースには、新機能、バグ修正/セキュリティ修正、および V8 の改善が含まれています。アプリ開発者の皆様には、これらの変更をタイムリーに利用できるようにしたいと考えています。そのため、安定版のリリース日は、他のすべての Chromium 安定版リリースに合わせていきます。アプリ開発者は、以前よりも早く新しい Chromium および V8 の機能と修正にアクセスできるようになります。

❓ 既存の 12 週間のリリーススケジュールはすでに速く進んでいます。チームはアップグレードを容易にするためにどのような手順を踏んでいますか？​

リリース頻度が高くなることの利点の 1 つは、小さなリリースになることです。Electron のメジャーバージョンのアップグレードは難しい場合があることを理解しています。小さなリリースでは、リリースごとに、より少ないメジャーな Chromium および Node の変更と、より少ない破壊的な変更が導入されることを願っています。

❓ 将来の Electron バージョンでアルファ版リリースは利用可能になりますか？​

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

❓ Electron はサポート対象バージョンの数を拡張しますか？​

Electron 19 のリリースまでの 2022 年 5 月まで、サポート対象バージョンのポリシーを最新の 3 バージョンから最新の 4 バージョンの Electron に拡張します。Electron 19 がリリースされた後、ベータ版とナイトリーリリースだけでなく、最新の 3 つのメジャーバージョンをサポートする予定です。

質問がありますか？​

📨 ご質問や懸念事項がありましたら、info@electronjs.org までメールでお問い合わせいただくか、Discord にご参加ください。今回の変更は多くのアプリや開発者に影響を与える可能性があることを承知しており、皆様からのフィードバックは非常に重要です。ぜひご意見をお聞かせください！

本日午前、OpenJS World にて、Electron が正式に OpenJS Foundation のインキュベーションプログラムを卒業し、OpenJS Foundation のインパクトプロジェクトになったことを発表しました。

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

詳細はこちら​

財団、そのミッション、およびメンバーについては、OpenJSF のウェブサイトで詳しく読むことができます。OpenJS Foundation は、jQuery、Node.js、webpack など、多数のオープンソース JavaScript プロジェクトをホストしています。GoDaddy、Google、IBM、Intel、Joyent、Microsoft を含む30の企業およびエンドユーザーメンバーによってサポートされています。

Electron は、Web テクノロジーを使用してクロスプラットフォームのデスクトップアプリケーションを構築するためのオープンソースフレームワークです。Electron の背後にいる人々とその協力方法について詳しくは、ガバナンスページをご覧ください。

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