Electron は Google Summer of Code (GSoC) 2025 のメンター組織として再び採用されました！ Google Summer of Code は、オープンソースソフトウェア開発に新たな貢献者を呼び込むことに重点を置いた国際プログラムです。

詳細については、Google の Summer of Code のホームページ をご覧ください。

私たちについて​

Electron は、ウェブ技術を用いたクロスプラットフォームのデスクトップアプリケーションを構築する JavaScript フレームワークです。 Electron フレームワークのコアは Chromium と Node.js で構築されたコンパイル済みバイナリ実行形式であり、主に C++ で書かれています。

Electron のコア リポジトリ以外では、Electron エコシステムをサポートするいくつかのプロジェクトを管理しています：

• エンドユーザの頒布ツール (例えば Electron Forge や update.electronjs.org)。
• Electron 開発者向けの学習教材 (例えば electronjs.org や Electron Fiddle)。
• 開発者の生産性を効率化する内部ツール (例えば Electron Build Tools や Sheriff)。

As a GSoC contributor, you will have the opportunity to collaborate with some of Electron’s core contributors on one of many projects under the github.com/electron umbrella.

応募する前に​

If you aren’t very familiar with Electron, we would recommend you start by reading the documentation and trying out some of the examples in Electron Fiddle.

To learn more about distributing Electron apps, try creating a sample application with Electron Forge:

npm init electron-app@latest my-app

コードに少し慣れたら、Electron の Discord サーバー での会話にご参加ください。

プロジェクトの貢献者​

あなたが興味のあるプロジェクトのアイデアに関連するリポジトリを見てみることをお勧めします。 あなたの研究を行う一つの方法は、バグを報告したり、 既存の問題をトリアージしたり、プルリクエストを送信したりすることです。 そうすることはコードベースで実践的な練習をする効果的な方法ですが、提案の提出には必須ではありません。 巧みに作られた提案は、過去の貢献を参照することなくコードの理解を示すことができるはずです。

提案を提出する前に、Electron に貢献したい場合は、以下のヒントをご覧ください：

1. 投稿を送信する際は、記述的な課題またはPR記述を入力してください。 Regardless of the code itself, putting effort into the written part of a contribution shows us that you can be an effective communicator in a collaborative environment.
2. PRs are always welcome for open issues. You do not need to comment on an issue asking a maintainer if you can be assigned to it. Note that we still encourage you to discuss potential solutions on an issue if you need to refine an idea for a solution, but comments strictly asking if you can work on something are redundant and add noise to the issue tracker.
3. Low-effort project contributions (e.g. invalid issue reports, trivial wording changes in a repo README, or minor stylistic changes to front-end code) will negatively impact your final proposal, as they take up limited maintainer time and do not provide any net benefit to the Electron project.
4. While AI coding assistants can be an effective tool for debugging and understanding new concepts, we highly discourage contributions that are copy/pasted directly from AI-generated output. These often turn out to be of low quality, and it's often more effort for maintainers to clean up code generated from an LLM than for us to just reject a PR altogether.

Crafting your proposal​

Electron との共同開発に興味を持てましたか? まずは、私たちが用意した 7 つのプロジェクトアイデア案 をご覧ください。 掲載されているアイデアは、企画のために公開中のものです。

あなたがリストにないユニークなアイデアを持っているならば、私たちはそれを検討することを開いています。 しかし、あなたの提案が詳細で徹底的に概説されていることを確認してください。 あまり自信がないのであれば、リストのアイデアに従うことをお勧めします。

応募には以下のものがあるとよいでしょう。

• A detailed proposal outlining what you plan to achieve over the summer.
• 開発者としての経歴。 履歴書がある場合は、コピーを添付してください。 そうでなければ、過去の技術経験についてお教えください。
  • 特定の分野での経験不足で不合格となることはありませんが、私たちメンターがあなたを最大限にサポートし、あなたの夏のプロジェクトが成功するよう計画を立てるのに役立ちます。

Electron アプリケーションの一部として何を提出するかの詳細なガイドはこちら。 Google Summer of Code ポータルに直接提案を送信します。 Proposals emailed to the Electron team will not be considered as final submissions.

For more guidance on your proposal, we recommend you follow the official Google Summer of Code proposal writing advice here.

Applications open on March 24th, 2025 and close on April 8th, 2025.

質問?​

If you have questions we didn’t address in this blog post or inquiries about your proposal draft, please send us an email at summer-of-code@electronjs.org or check the GSoC FAQ. Please read our contributor guidance before emailing.

リソース​

• Electron の Google Summer of Code 2025 アイデアリスト
• Electron Google Summer of Code 2025 貢献者ガイダンス
• Google Summer of Code 学生/貢献者ガイド

In early 2025, Electron’s npm ecosystem repos (under the @electron/ and @electron-forge/ namespaces) will move to Node.js 22 as the minimum supported version.

What does this mean?​

In the past, packages in Electron’s npm ecosystem (Forge, Packager, etc) have supported Node versions for as long as possible, even after a version has reached its End-Of-Life (EOL) date. This is done to make sure we don’t fragment the ecosystem—we understand that many projects depend on older versions of Node, and we don’t want to risk stranding those projects unless there was a pressing reason to upgrade.

Over time, using Node.js 14 as our minimum version has become increasingly difficult for a few reasons:

• Lack of official Node.js 14 macOS ARM64 builds requires us to maintain CI infrastructure workarounds to provide full test coverage.
• engines requirements for upstream package dependencies have moved forward, making it increasingly difficult to resolve supply chain security issues with dependency bumps.

Additionally, newer versions of Node.js have included many improvements that we would like to leverage, such as runtime-native common utilities (e.g. fs.glob and util.parseArgs) and entire new batteries-included modules (e.g. node:test, node:sqlite).

Why upgrade now?​

In July 2024, Electron’s Ecosystem Working Group decided to upgrade all packages to the earliest Node version where require()of synchronous ESM graphs will be supported (see nodejs/node#51977 and nodejs/node#53500) at a future point after that version reaches its LTS date.

We’ve decided to set that update time to January/February 2025. After this upgrade occurs, Node 22 will be the minimum supported version in existing ecosystem packages.

What action do I need to take?​

We’ll strive to maintain compatibility as much as possible. However, to ensure the best support, we encourage you to upgrade your apps to Node 22 or higher.

Note that the Node version running in your project is unrelated to the Node version embedded into your current version of Electron.

今後の予定​

Please feel free to write to us at info@electronjs.org if you have any questions or concerns. You can also find community support in our official Electron Discord.

BrowserView has been deprecated since Electron 30 and is replaced by WebContentView. Thankfully, migrating is fairly painless.

Electron is moving from BrowserView to WebContentsView to align with Chromium’s UI framework, the Views API. WebContentsView offers a reusable view directly tied to Chromium’s rendering pipeline, simplifying future upgrades and opening up the possibility for developers to integrate non-web UI elements to their Electron apps. By adopting WebContentsView, applications are not only prepared for upcoming updates but also benefit from reduced code complexity and fewer potential bugs in the long run.

Developers familiar with BrowserWindows and BrowserViews should note that BrowserWindow and WebContentsView are subclasses inheriting from the BaseWindow and View base classes, respectively. To fully understand the available instance variables and methods, be sure to consult the documentation for these base classes.

Migration steps​

1. Upgrade Electron to 30.0.0 or higher​

2. Familiarize yourself with where your application uses BrowserViews​

One way to do this is to search your codebase for new BrowserView(. This should give you a sense for how your application is using BrowserViews and how many call sites need to be migrated.

3. Migrate each usage of BrowserView​

1. Migrate the instantiation. This should be fairly straightforward because WebContentsView and BrowserView’s constructors have essentially the same shape. Both accept WebPreferences via the webPreferences param.

   - this.tabBar = new BrowserView({
   + this.tabBar = new WebContentsView({
   

   info

   By default, WebContentsView instantiates with a white background, while BrowserView instantiates with a transparent background. To get a transparent background in WebContentsView, set its background color to an RGBA hex value with an alpha (opaqueness) channel set to 00:

   + this.webContentsView.setBackgroundColor("#00000000");
   

2. Migrate where the BrowserView gets added to its parent window.

   - this.browserWindow.addBrowserView(this.tabBar)
   + this.browserWindow.contentView.addChildView(this.tabBar);
   

3. Migrate BrowserView instance method calls on the parent window.

   Old Method	New Method	ノート
   win.setBrowserView	win.contentView.removeChildView + win.contentView.addChildView
   win.getBrowserView	win.contentView.children
   win.removeBrowserView	win.contentView.removeChildView
   win.setTopBrowserView	win.contentView.addChildView	Calling addChildView on an existing view reorders it to the top.
   win.getBrowserViews	win.contentView.children

4. Migrate the setAutoResize instance method to a resize listener.

   - this.browserView.setAutoResize({
   -   vertical: true,
   - })
   
   + this.browserWindow.on('resize', () => {
   +   if (!this.browserWindow || !this.webContentsView) {
   +     return;
   +   }
   +   const bounds = this.browserWindow.getBounds();
   +   this.webContentsView.setBounds({
   +     x: 0,
   +     y: 0,
   +     width: bounds.width,
   +     height: bounds.height,
   +    });
   +  });
   

   ヒント

   All existing usage of browserView.webContents and instance methods browserView.setBounds, browserView.getBounds , and browserView.setBackgroundColor do not need to be migrated and should work with a WebContentsView instance out of the box!

4) Test and commit your changes​

Running into issues? Check the WebContentsView tag on Electron's issue tracker to see if the issue you're encountering has been reported. If you don't see your issue there, feel free to add a new bug report. Including testcase gists will help us better triage your issue!

Congrats, you’ve migrated onto WebContentsViews! 🎉

Electron API の履歴がドキュメント内で詳解されるようになります。

こんにちは 👋、2024 年 Google Summer of Code (GSoC) の Electron のコントリビューターの、Peter です。

GSoC プログラムの過程で、Electron ドキュメントとその関数、クラスなどに API の履歴の機能を実装しました。これは、Node.js ドキュメント と同様の方法で、API ドキュメントの Markdown ファイルにシンプルかつ強力な YAML スキーマを使用できるようにし、Electron ドキュメントのウェブサイトでわかりやすく表示することで実現しました。

Electron が第 20 回 Google Summer of Code (GSoC) 2024 のメンター組織として承認されたことをお知らせします! Google Summer of Code は、オープンソースソフトウェア開発に新たな貢献者を呼び込むことに重点を置いた国際プログラムです。

プログラムの詳細については、Google の Summer of Code のホームページ をご覧ください。

私たちについて​

Electron は、ウェブ技術を用いたクロスプラットフォームのデスクトップアプリケーションを構築する JavaScript フレームワークです。 Electron フレームワークのコアは Chromium と Node.js で構築されたコンパイル済みバイナリ実行形式であり、主に C++ で書かれています。

Electron のコア以外にも以下のように、Electron 組織の維持に役立つ様々なプロジェクトに取り組んでいます。

• エンドユーザの頒布ツール (例えば Electron Forge や update.electronjs.org)。
• Electron 開発者向けの学習教材 (例えば electronjs.org や Electron Fiddle)。
• 開発者の生産性を効率化する内部ツール (例えば Electron Build Tools や Sheriff)。

Summer of Code の貢献者の方は、github.com/electron 傘下の多くのプロジェクトのうちの 1 つで、Electron のコアの貢献者の一部と協力して頂きます。

応募する前に​

Electron にあまり詳しくない方は、ドキュメント を読んだり、Electron Fiddle のサンプルを試してみることをお勧めします。

Electron アプリの頒布形式の詳細について学ぶには、サンプルアプリケーションを作成して Electron Forge を試すのもよいでしょう。

npm init electron-app@latest my-app

コードに少し慣れたら、Electron の Discord サーバー での会話にご参加ください。

計画書の執筆​

Electron との共同開発に興味を持てましたか? まずは、私たちが用意した 7 つのプロジェクトアイデア案 をご覧ください。 掲載されているアイデアは、すべて企画のために現在公開中のものです。

この他に検討して欲しいアイデアをお持ちですか? 提案プロジェクトのリストにない新しいアイデアも歓迎しますが、アプローチを十分に概説し、かつ詳細に説明するようにしてください。 あまり自信がないのであれば、リストのアイデアに従うことをお勧めします。

応募には以下のものがあるとよいでしょう。

• 計画書: この夏のプログラムの間に達成する目標の計画を詳細に記した文書。
• 開発者としての経歴。 履歴書がある場合は、コピーを添付してください。 なければ、過去の技術経験についてお教えください。
  • 特定の分野での経験不足で不合格となることはありませんが、私たちメンターがあなたを最大限にサポートし、あなたの夏のプロジェクトが成功するよう計画を立てるのに役立ちます。

Electron の応募で提出する一式の詳細なガイドはこちらです。 計画書は Google Summer of Code ポータルに直接提出してください。 注意として、申請ポータルから送信せずに Electron チームへ電子メールで送信した計画書は、最終提出物とみなされません。

計画書についてさらに詳しいガイダンスが必要な場合や、何を書き込めばよいかわからない場合は、Google Summer of Code 公式の計画書作成アドバイス に従うこともお勧めします。

応募開始は 2024 年 3 月 18 日、締め切りは 2024 年 4 月 2 日 です。

質問?​

ブログ記事で取り上げられていない質問や計画書の執筆に関するお問い合わせは、summer-of-code@electronjs.org までメールしていただくか、GSoC FAQ をご確認ください。

リソース​

• Electron の Google Summer of Code 2024 アイデアリスト
• Electron Google Summer of Code 2024 貢献者ガイダンス
• Google Summer of Code 学生/貢献者ガイド

Electron の API ワーキング グループ は、Electron のコアへのより大きな変更を支援するために、オープンな Requests for Comments (RFC) プロセスを採用しようとしています。

なぜ RFC なのでしょうか?​

要するに、Electron のコアへの重要な変更を実装するプロセスをスムーズにしたいのです。

現在、新しいコードの変更は主に GitHub の Issue とプルリクエストを通じて議論されています。 Electron のほとんどの変更においては、これは良いシステムです。 多くのバグ修正、ドキュメントの変更、さらには新機能も、標準の GitHub フローを介せば非同期的にレビューおよびマージできるほど簡単です。

より重大な変更—たとえば大規模な API サーフェスや、Electron アプリの大部分に影響する重大な変更などの場合、コードの大部分が記述される前のアイデア段階でレビューを行うほうが合理的です。

このプロセスは一般公開されるように設計すべきです。そうすることで、Electron に導入される前に、オープンソースコミュニティ全体が潜在的な変更についてフィードバックを提供しやすくなります。

どのように動作するのですか?​

RFC 全体のプロセスは、GitHub 上の electron/rfcs リポジトリに保管されます。 プロセスの手順は、リポジトリの README で詳しく説明しています。

簡単に言うと、electron/rfcs リポジトリに PR が作成されると、RFC は 提唱 になります。 提唱の RFC は次のように遷移します。

• アクティブ は、PR がリポジトリの main ブランチにマージされた場合になります。つまり、Electron のメンテナが electron/electron での実装に同意できることを意味します。
• 拒絶 は PR が最終的に拒否された場合になります。

実装が electron/electron にマージされたとき、アクティブな RFC は 完了 になります。

誰が参加できますか?​

Electron コミュニティの誰もが、RFC を提出したり、electron/rfcs リポジトリにフィードバックを残したりできます!

• アクティブな RFC を一覧する場合は、リポジトリ内の text フォルダ を参照してください。
• 提唱状態の RFC にフィードバックを残す場合は、開かれている PR のリスト を確認してください。
• 新しい RFC を提出する場合は、レポジトリの README と RFC テンプレート を確認してください。

私たちは、このプロセスを双方向の対話にして、コミュニティの参加を奨励し、将来これらの API を使用する可能性のある Electron アプリからの多様な意見を得たいと考えていました。 現在提唱状態の RFC にフィードバックを残したい方向けに、Electron のメンテナが既に作成したいくつかの RFC を下記します。

• Electron の C API
• サービスワーカー向けのプリロードレルム

クレジット​

Electron の RFC プロセスは、多くの確立されたオープンソースの RFC プロセスに基づいてモデル化されました。 多くのアイデアやコピーライティングの主要部分のインスピレーションは、以下から得ました。

• emberjs/rfcs
• reactjs/rfcs
• rust-lang/rfcs
• tauri-apps/rfcs
• vuejs/rfcs
• yarnpkg/rfcs

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 チームは、今年初めて Google Summer of Code に参加することをお知らせします!

Google Summer of Code とは何ですか?​

Google Summer of Code (GSoC) は、オープンソースソフトウェアプロジェクトと潜在的な貢献者をつなぐ、年に一回のメンタリングプログラムです。 以前は学生だけでしたが、現在は 18 歳以上であれば誰でも GSoC に登録できます。

詳しい情報については Summer of Code のホームページ をご確認ください。

登録方法は何ですか?​

Electron との共同開発に興味はありますか? オープンソースのコントリビューターを始めたばかり方や初心者であれば、ぜひご応募ください!

Google Summer of Code の Electron コントリビューターとして選ばれるためには、ご応募していただく必要があります。 応募開始は 2022 年 4 月 4 日、締め切りは 2022 年 4 月 19 日 となります。 Google Summer of Code の応募要項はこちらで更新しています。

応募をご希望ですか? まずは、私たちがご用意した 5 つのプロジェクトアイデア案 をご覧ください。 掲載されているアイデアは、すべて企画のために現在公開中のものです。 また、企画プロジェクトのリストにない新規アイデアも受け付けています。

応募には以下のものがあるとよいでしょう。

• 企画書。この夏のプログラムの間に達成する目標の計画を詳細に記した文書です。
• 開発者としての経歴。 レジュメをお持ちの方はコピーを添付してください。または、関連する技術的な経験を中心に、これまでの経験をお聞かせください。

Electron への応募にかかる提出物の詳細は、こちらをご覧ください。

また GSoC 学生/コントリビューター公式ガイド には、企画書を作成する際の重要なヒントが記載されていますので、ぜひご覧ください。

プロジェクトの企画について議論したい方や質問がある方は、#gsoc-general Discord チャンネル にぜひいらしてください!

リファレンス​

• Electron 企画ガイド
• Electron GitHub
• プロジェクトアイデアのドキュメント
• Google Summer of Code 学生/コントリビューターガイド

コミュニティの絆とオープンソースの1ヶ月間のお祝いのために私たちに参加してください。

Electron コミュニティの Discord の立ち上げ

Electronの Outreach ワーキンググループ は、 公式コミュニティ Discord サーバーの立ち上げを発表することを楽しみにしています！

なぜ新しいDiscordサーバーなのか？​

Atom テキスト エディタののバックボーンとして、Electron フレームワークに関するコミュニティでのディスカッションは、Atom の Slack ワークスペースの1チャネルで行われていました。 時間が経ち、2つのプロジェクトが分離していくにつれて、AtomワークスペースとElectronプロジェクトとの関連性は低下し、Slackチャンネルへのメンテナンの参加者も同様に低下しました。

これまで、招待を受け取るのに苦労したと多く人からの報告を受けました。コアメンテナンス担当者のほとんどがチャンネルを頻繁に行なっていたにもかかわらず、より広範なコミュニティをAtom Slackワークスペースにリダイレクトしていました。

この新しいサーバーは、Electron に関する最新情報を得ることができる、コミュニティの中心的な議論の場となるようにしています。

ぜひお越しください!​

今のところ、サーバーのメンバーシップは数人のメンターが協力して立ち上げていますが、皆さんとお話しできることをとても楽しみにしています。 助けを求めたり、Electron の最新情報を得たり、他の開発者と交流したりできます。 サーバーにアクセスできる便利な 招待リンク をご用意しました!

Hacktoberfest 2020

大規模で長期間実行されているオープンソースプロジェクトとして、Electronはコミュニティからの貢献なしにはほとんど成功しませんでした。 コードの提出からバグレポート、ドキュメントの変更まで様々です。 だからこそ、Hacktoberfest に参加することで、あらゆるスキルレベルの開発者たちがより広いコミュニティでプロジェクトに参加できるようになることが重要だと考えています。

寄せ集め物​

今年は、あなたにすべてを与えるより広いプロジェクトを持っていません。しかし、Electron JavaScript エコシステム全体に貢献する機会に焦点を当てたいと思います。

私達のさまざまリポジトリで hacktoberfest のタグのある課題をみてください。メインの electron/electron リポジトリ、electron/electronjs.org ウェブサイト、electron/fiddle、それに electron-userland/electron-forgeもあります。

P.S. 特に冒険したい方向けに、help wanted タグが付けられた Issue のバックログも用意しています。

つまづきましたか? 一緒にチャットしてみましょう!​

さらに、私たちの Discord サーバーのグランドオープンが、今年最大のオープンソースソフトウェアの祭典と重なったのも偶然ではありません。 Hacktoberfest の PR に協力してもらうためにも、#hacktoberfest チャンネルをチェックしてみましょう。 見逃した方のために、招待リンクをこちらに再びご用意しました!

Google Season of Docs 第 2 段に参加させていただき、Electron としては大変光栄です。このイニシアティブでは、オープンソース組織のメンターとテクニカルライターがペアを組み、プロジェクトのドキュメントを改善していきます。

Season of Docs とは何ですか?

Season of Docs は、テクニカルライターとオープンソースコミュニティのコラボレーションを促進し、両者の利益に貢献するプログラムです。 オープンソースのメンテナーは、ライターのテクニカルライティングの専門知識を活用して、ドキュメントの構造と内容を改善します。テクニカルライターは、指導者の指導のもとオープンソースのコミュニティへ派遣されます。 詳細は Google の Season of Docs ウェブサイト で解説しています。

このプログラムに初めて参加した弊社では、テクニカルライター 1 名をメンターとして迎え、Electron の エコシステム作業グループ と協力しドキュメントの大部分を再構築していきます。 プロジェクト全体のタイムラインについては、こちら をご覧ください。

登録方法は何ですか?

テクニカルライターとして弊社とのコラボレーションに興味がございますか? まずは、今年のプログラムのために Google の テクニカルライターガイド を把握し、用意した 2 つの プロジェクトのアイデア草稿 をご確認ください。

Season of Docs のテクニカルライターとして採用されるには、6 月 8 日から 7 月 9 日までの期間中に Google Season of Docs のウェブサイトから応募する必要があります。

応募書類には、3 ヶ月間 Electron ドキュメントで何を成し遂げようとしているのかを詳細に記述した提案書を添付してください。 この提案書は、プロジェクトのアイデア草稿に記載した出発点のいずれかを発展させた内容か、全く新しいものにして頂いて構いません。 どこから手を付ければいいのかわかりませんか? 昨年の 受理された提案書のリスト を閲覧して、知見を得ることもできますよ。

提案書とは別に、テクニカルライターとしての経歴も審査されます。 履歴書には、テクニカルライティングのサンプル (既存のドキュメント、チュートリアル、ブログ記事など) と、加えて関連するライティング経験を強調したコピーを添付してください。

プロジェクトの提案を議論したい場合は、season-of-docs@electronjs.org までメールでお問い合わせください。そこからお話しましょう!

リファレンス

• Electron ドキュメント
• Project のアイデアドキュメント
• Season of Docs テックライターガイド