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 Forge v6.0.0 がリリースされましたことをお知らせします! このリリースは 2018 年以来の Forge のメジャーリリースとなり、GitHub 上のこのプロジェクトは electron-userland からメインのelectron Organization に移動されました。

ここでは Electron Forge の新機能と、あなたのアプリでの利用方法についてご紹介します。

Electron Forge とは何ですか?​

Electron Forge は、Electron アプリケーションをパッケージ化および頒布するツールです。 これは Electron のビルドツールエコシステムを単一の拡張可能なインターフェイスに統一し、誰でもすぐに Electron アプリを作れるようにします。

主な機能は次のとおりです。

• 📦 アプリケーションのパッケージ化とコード署名
• 🚚 Windows、macOS、Linux のカスタマイズ可能なインストーラー (DMG、deb、MSI、PKG、AppX など)。
• ☁️ クラウドプロバイダ (GitHub、S3、Bitbucket など) 向けの自動公開フロー。
• ⚡️ webpack や TypeScript 向けの使いやすい定型テンプレート
• ⚙️ ネイティブ Node.js モジュールのサポート
• 🔌 拡張可能な JavaScript プラグイン API

v6 の新機能はなんですか?​

完全な書き直し​

Electron Forge は v1 から v5 まで、現在では廃止されている electron-compile プロジェクトをベースにしていました。 Forge 6 は、Electron アプリケーションのニーズに合わせて拡張可能な新しいモジュール式アーキテクチャを採用し、プロジェクトを完全に書き直しました。

過去数年間で、Forge v6.0.0-beta は v5 と同等の機能を達成し、コードの乱れが減り、一般的に採用できるツールになりました。

公式サポート​

これまで Electron のメンテナはビルドツールに関して無関心で、様々なコミュニティパッケージに仕事を任せてきました。 しかし、Electron がプロジェクトとして成熟するにつれ、Electron の新規開発者がアプリを構築し頒布するために必要なツールの理解が難しくなってきました。

Electron 開発者の頒布プロセスを支援するために、私たちは Forge を Electron の公式ですぐに使えるビルドパイプラインとする ことを決めました。

この 1 年間で、私たちは徐々に Forge を Electron の公式ドキュメントに統合してきました。そして最近になって、Forge をかつての electron-userland/electron-forge から electron/forge レポジトリに移動させました。 これで、いよいよ Electron Forge を一般公開する準備ができました!

はじめましょう​

新規 Forge プロジェクトの初期化​

新しい Electron Forge プロジェクトの準備は create-electron-app CLI スクリプトでできます。

yarn create electron-app my-app --template=webpack
cd my-app
yarn start

npm init electron-app@latest my-app -- --template=webpack
cd my-app
npm start

このスクリプトは、完全な JavaScript のバンドルと、あらかじめ構成されたビルドパイプラインを、my-app フォルダの Electron プロジェクトに作成します。

詳細については、Forge ドキュメント内の Getting Started ガイドをご参照ください。

既存のプロジェクトをインポートする​

Electron Forge CLI には、既存の Electron プロジェクト用のインポートコマンドも用意されています。

cd my-app
yarn add --dev @electron-forge/cli
yarn electron-forge import

cd my-app
npm install --save-dev @electron-forge/cli
npm exec --package=@electron-forge/cli -c "electron-forge import"

import コマンドを使用すると、Electron Forge はいくつかのコアの依存関係を追加し、新しい forge.config.js 設定を作成します。 既存のビルドツール (Electron Packager、Electron Builder、Forge 5 など) がある場合、できるだけ多くの設定を移行しようと試みます。 既存の設定の一部は、手動で移行する必要があります。

手動による移行の詳細は、Forge の import ドキュメント に記載されています。 もし助けが必要でしたら、私たちの Discord サーバー をお訪ねください!

なぜ Forge に切り替えるのでしょうか？​

Electron アプリのパッケージ化や公開を行うツールをすでにお持ちの場合でも、Electron Forge の導入により初期導入コストを上回るメリットを得ることができます。

Forge を使うメリットは、大きく分けて 2 つあると考えています。

1. Forge は Electron がサポートしているので、アプリケーション構築のための新機能が提供されてもすぐに享受できます。 こうすれば、新しいツールのサポートを自分で対応したり、アップグレードがあっても他のパッケージがサポートするまで実装を待つ必要はありません。 最近の例としては、macOS ユニバーサルバイナリ や ASAR 整合性検査 をご覧ください。

2. Forge はマルチパッケージアーキテクチャを採用しているため、理解しやすく拡張も容易です。 Forge は責任の所在が明確なたくさんの小さなパッケージで構成されているため、コードの流れを追いやすくなっています。 さらに、Forge の拡張可能な API 設計は、高度なユースケースのために、提供された設定オプションとは別に独自の追加ビルドロジックを書けるのです。 カスタム Forge プラグイン、メーカー、パブリッシャーの作成に関する詳細は、ドキュメントの Extending Electron Forge のセクションを参照してください。

破壊的変更​

Forge 6 はベータ版として長い時間を過ごしており、そのリリース間隔は徐々に遅くなっています。 しかし 2022 年後半に開発を加速させ、v6.0.0 の安定版リリース前に最後の破壊的変更を押し進めるために、直近で何回かのリリースがありました。

Electron Forge 6 のベータ版の利用者の方は、v6.0.0 GitHub リリースノート に最新のベータ版 (>=6.0.0-beta.65) で行われた変更点のリストがありますので、そちらをご覧ください。

変更とコミットの完全なリストは、リポジトリの CHANGELOG.md で閲覧できます。

フィードバックをお送りください!​

欲しいものを教えてください! Electron Forge チームは、常にユーザーにとってより良いプロジェクトを構築することを目指しています。

機能リクエストの提出、Issue の投稿、またはご意見を寄せていただければ、Electron Forge の改善に役立ちます。 また、公式 Electron Discordサーバー では、Electron Forge のディスカッション用チャンネルが用意されていますので、そちらからもご参加できます。

https://electronforge.io の Forge ドキュメントにフィードバックをしたい方は、GitBook インスタンスを electron-forge/electron-forge-docs レポジトリに同期していますのでそちらにお願いします。

先月、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.0.0 がリリースされました! これには Chromium 106、V8 10.6、Node.js 16.16.0 へのアップグレードが含まれています。 詳しくは以下をご覧ください!

Electron チームは、Electron 21.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細は続きをご覧ください。

フィードバックがあれば、Twitterで共有するか、コミュニティ Discordに参加してください！ バグや機能の要望は Electron の Issue トラッカー で報告できます。

注目すべき変更​

累積的変更​

• Chromium 106
  • Chrome 106 の新機能
  • Chrome 105 の新機能
  • デベロッパー ツール 106 の新機能
  • デベロッパー ツール 105 の新機能
• Node.js 16.16.0
  • Node 16.16.0 ブログ記事
• V8 10.6

新機能​

• webFrameMain.origin を追加しました。 #35534
• 新しい WebContents.ipc と WebFrameMain.ipc API を追加しました。 #35231
• パネルのような動作のサポートを追加しました。 フルスクリーンにしたアプリの上にウインドウを浮かべることができます。 #34388
• macOS アプリ向けに APNS からのプッシュ通知サポートを追加しました。 #33574

破壊的な API の変更​

以下は、Electron 21 での破壊的変更点です。

V8 メモリケージの有効化​

Electron 21 では V8 のサンドボックス化ポインタ を有効にします。これは Chrome の Chrome 103 での同様の決定 に従ったものです。 これはネイティブモジュールにいくつかの影響を与えます。 この機能には、パフォーマンスやセキュリティ上の利点がありますが、外部 ("ヒープ外") のメモリを指す ArrayBuffer の使用など、ネイティブモジュールに新しい制限を課すことになります。 詳細は ブログ記事 をご参照ください。 #34724

webContents.printToPDF のリファクタリング​

Chromium のヘッドレス実装に合わせるために webContents.printToPDF をリファクタリングしました。 さらなる情報は #33654 をご参照ください。

これらの変更と将来の変更の詳細については、予定されている破壊的変更 のページを参照してください。

18.x.y サポートの終了​

Electron 18.x.y はプロジェクトの サポートポリシー に則りサポート終了となりました。 開発者とアプリケーションは新しいバージョンの Electron にアップグレードすることを推奨します。

次回予告​

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。

Electron の公開タイムラインはこちら になります。

将来の変更の詳細については、予定されている破壊的変更 のページをご参照ください。

Electron 20.0.0 がリリースされました! これには Chromium 104、V8 10.4、Node.js 16.15.0 へのアップグレードが含まれています。 詳しくは以下をご覧ください!

Electron チームは、Electron 20.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細については下に続きます。是非ご意見をお聞かせください!

注目すべき変更​

新機能​

• Windows に没入型ダークモードを追加しました。 #34549
• パネルのような動作のサポートを追加しました。 フルスクリーンにしたアプリの上にウインドウを浮かべることができます。 #34665
• Windows 11 でよりネイティブに見えるように Windows コントロールオーバーレイボタンを更新しました。 #34888
• nodeIntegration: true や sandbox: false が指定されない限り、デフォルトでレンダラーがサンドボックス化されるようになりました。 #35125
• nan でネイティブモジュールをビルドする際のセーフガードを追加しました。 #35160

累積的変更​

• Chromium 104
  • Chrome 104 の新機能
  • Chrome 103 の新機能
  • デベロッパー ツールの新機能
• Node.js 16.15.0
  • Node 16.15.0 ブログ記事
• V8 10.4

破壊的な API の変更​

以下は、Electron 20 での破壊的変更点です。 これらの変更と将来の変更の詳細については、予定されている破壊的変更 のページを参照してください。

省略値の変更: nodeIntegration: true 指定が無いレンダラーはデフォルトでサンドボックス化されます。​

これまで、プリロードスクリプトを指定したレンダラーはデフォルトでサンドボックス化されていませんでした。 つまり、プリロードスクリプトはデフォルトで Node.js へのアクセス権を持っていたということです。 Electron 20 では、この省略値が変更されました。 Electron 20 以降、レンダラーに nodeIntegration: true または sandbox: false が指定されていない限り、デフォルトでサンドボックス化されます。

プリロードスクリプトが Node に依存していない場合、対応は不要です。 プリロードスクリプトが Node に依存している場合は、リファクタしてレンダラーから Node の使用部分を削除するか、そういったレンダラーでは sandbox: false を明示的に指定してください。

修正: nan ネイティブモジュールでの自発的クラッシュ​

Electron 20 では、ネイティブモジュールに関する 2 つの項目を変更しました。

1. V8 ヘッダはデフォルトで c++17 を使用するようになりました。 このフラグは electron-rebuild で付与されます。
2. nan に依存しているネイティブモジュールでインクルードファイルが見つからないと、自発的にクラッシュする問題を修正しました。

最大限安定させるために、ネイティブモジュール、特に nan に依存するモジュールをリビルドする際には、node-gyp>=8.4.0 と electron-rebuild>=3.2.9 の使用を推奨します。 詳細は electron の #35160 と node-gyp の #2497 を参照してください。

削除: Linux 上の .skipTaskbar​

X11 では、 skipTaskbar は _NET_WM_STATE_SKIP_TASKBAR メッセージを X11 ウインドウマネージャーに送信します。 Wayland には同等のものがなく、また既知の回避策にも許容できないトレードオフがあるため (例えば GNOME の Window.is_skip_taskbar はアンセーフモードが必要)、Electron はこの機能を Linux でサポートできません。

17.x.y サポートの終了​

Electron 17.x.y はプロジェクトの サポートポリシー に則りサポート終了となりました。 開発者とアプリケーションは新しいバージョンの Electron にアップグレードすることを推奨します。

次回予告​

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。 リリース日について約束しないように注意していますが、予定では 2 か月ごとに新しいメジャーバージョンの Electron を、各コンポーネントの新しいバージョンに対してリリースします。

Electron の公開タイムラインはこちら になります。

将来の変更の詳細については、予定されている破壊的変更 のページをご参照ください。

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 19.0.0 がリリースされました! これには Chromium 102、V8 10.2、Node.js 16.14.2 へのアップグレードが含まれています。 詳しくは以下をご覧ください!

Electron チームは、Electron 19.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細については下に続きます。是非ご意見をお聞かせください!

注目すべき変更​

Electron リリースケイデンスの変更​

このプロジェクトは、以前の方針である最新の 3 つのメジャーバージョンのサポートに戻りつつあります。 Electron のバージョン管理およびサポートについてのより詳細な情報は、バージョン管理のドキュメント をご覧ください。 Electron 15 から始まった新しいリリースサイクルにユーザーが適応できるよう、一時的に 4 つのメジャーバージョンをサポートしていました。 詳細はこちら でご覧いただけます。

累積的変更​

• Chromium 102
  • Chrome 102 の新機能
  • Chrome 101 の新機能
• Node.js 16.14.2
  • Node 16.14.2 ブログ記事
• V8 10.2

破壊的な API の変更​

以下は、Electron 19 での破壊的変更点です。 これらの変更と将来の変更の詳細については、予定されている破壊的変更 のページを参照してください。

Linux での非対応化: .skipTaskbar​

Linux では BrowserWindow コンストラクタのオプション skipTaskbar がサポートされなくなりました。 #33226 での変更

WebPreferences.preloadURL の削除​

準ドキュメント化されていた preloadURL プロパティは、WebPreferences から削除されました。 #33228. WebPreferences.preload を代わりに使用してください。

15.x.y と 16.x.y のサポート終了​

Electron 14.x.y と 15.x.y はどちらも既にサポート終了しています。 これにより、Electron は最新の 3 つのメジャーバージョンをサポートする 従来の方針 に 戻ります。 開発者とアプリケーションは新しいバージョンの Electron にアップグレードすることを推奨します。

次回予告​

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。 リリース日について約束しないように注意していますが、予定では 2 か月ごとに新しいメジャーバージョンの Electron を、各コンポーネントの新しいバージョンに対してリリースします。

Electron の公開タイムラインはこちら になります。

将来の変更の詳細については、予定されている破壊的変更 のページをご参照ください。

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 18.0.0 がリリースされました! これには Chromium 100、V8 10.0、Node.js 16.13.2 へのアップグレードが含まれています。 詳しくは以下をご覧ください!

Electron チームは、Electron 18.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細については下に続きます。是非ご意見をお聞かせください!

注目すべき変更​

Electron リリースケイデンスの変更​

Electron 15 にて、Electron は 8 週間ごとに新規メジャー安定版をリリースするようになります。 詳細はこちら でご覧いただけます。

また、Electron は 2022 年 5 月まで、サポートするバージョンを最新の 3 つのバージョンから最新の 4 つのバージョンに変更しています。 Electron のバージョン管理の詳細については バージョン管理のドキュメントを参照してください。 2022 年 5 月以降は、最新の 3 つのバージョンのサポートに戻ります。

累積的変更​

• Chromium 100
  • Chrome 100 の新機能
• Node.js 16.13.2
  • Node 16.13.2 ブログ記事
• V8 10.0

注目の機能​

• コードキャッシュのディレクトリを設定する ses.setCodeCachePath() API を追加しました。 #33286
• 古い BrowserWindowProxy ベースの window.open の実装を削除しました。 さらに webPreferences から nativeWindowOpen オプションを削除しました。 #29405
• WebContents に 'focus' と 'blur' のイベントを追加しました。 #25873
• macOS 上に右記の代替メニューロールを追加しました: showSubstitutions、toggleSmartQuotes、toggleSmartDashes、toggleTextReplacement。 #32024
• app.requestSingleInstanceLock() フローに first-instance-ack イベントが追加されました。これによりユーザーが最初のインスタンスから 2 番目のインスタンスへデータをシームレスに転送できます。 #31460
• より多くの色形式サポートを setBackgroundColor に追加しました。 #33364

新機能と変更の完全なリストは、18.0.0 リリースノート を参照してください。

破壊的な API の変更​

以下は、Electron 18 での破壊的変更点です。 これらの変更と将来の変更の詳細については、予定されている破壊的変更 のページを参照してください。

削除: nativeWindowOpen​

Electron 15 より前の window.open は既定で BrowserWindowProxy を使用していました。 このため、window.open('about:blank') では同期的にスクリプトで操作可能な子ウィンドウを開くことができないなどといった、非互換性がありました。 Electron 15 から、nativeWindowOpen が既定で有効になりました。

詳細については、Electron の windows.open のドキュメント をご参照ください。 #29405 で削除されました

14.x.y サポート終了​

Electron 14.x.y はプロジェクトの サポートポリシー に則りサポート終了となりました。 開発者とアプリケーションは新しいバージョンの Electron にアップグレードすることを推奨します。

Electron 15 にて、2022 年 5 月の Electron 19 までの間だけ、サポートするバージョンを最新の 3 つのバージョンから最新の 4 つのバージョンに変更しています。 Electron 19 以降は、最新の 3 つのバージョンのサポートに戻ります。 このバージョンサポートの変更は、新しいケイデンス変更の一環です。 完全な詳細についてはこちらのブログ記事 をご参照ください。

次回予告​

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。 リリース日について約束しないように注意していますが、予定では 2 か月ごとに新しいメジャーバージョンの Electron を、各コンポーネントの新しいバージョンに対してリリースします。

Electron の公開タイムラインはこちら になります。

将来の変更の詳細については、予定されている破壊的変更 のページをご参照ください。

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 学生/コントリビューターガイド