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 シリーズのパッチを、Electron が 22.x のサポートを終了する 2023 年 5 月 30 日までリリースし続けます (サポートタイムラインに従って)。

なぜ非推奨にするのか？​

Electron は、Chromium 109 でサポートを非推奨にする予定の Chromium の計画された非推奨ポリシーに従っています (Chromium のタイムラインの詳細はこちら)。Electron 23 には、古いバージョンの Windows をサポートしない Chromium 110 が含まれます。

したがって、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週間はNightly版とAlpha版のリリースもありません。
2. いくつかの例外を除き、プルリクエストのレビューやマージは行われません。
3. どのリポジトリでもIssueトラッカーの更新はありません。
4. メンテナーによるDiscordでのデバッグヘルプはありません。
5. ソーシャルメディアコンテンツの更新はありません。

なぜこうなるのですか？​

2021年12月のQuiet Monthの成功を受けて、2022年も復活させることにしました。12月はほとんどの企業にとって静かな月であるため、メンテナーが充電する機会を提供したいと考えています。誰もが2023年を楽しみにしています。良いことが起こることを期待しています！他のプロジェクトも同様の措置を検討することをお勧めします。

Electron Forge v6.0.0 が利用可能になったことをお知らせします！このリリースは、2018年以来Forgeの最初のメジャーリリースであり、プロジェクトがelectron-userlandからGithubのメインのelectron組織に移行します。

新機能と、アプリで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の新機能​

完全に書き直し​

v1からv5まで、Electron Forgeは現在廃止されている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ドキュメントのはじめにガイドを参照してください。

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

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のインポートドキュメントに記載されています。 お困りの場合は、Discordサーバーにお立ち寄りください！

Forgeに切り替える理由​

Electronアプリのパッケージングと公開のためのツールが既にある場合でも、Electron Forgeの採用に関連する利点は、初期の切り替えコストを上回る可能性があります。

Forgeを使用することには主に2つのメリットがあると考えています

1. Forgeは、Electronでサポートされるとすぐにアプリケーション構築の新機能を受け取ります。 この場合、新しいツールサポートを自分で組み込んだり、他のパッケージでそのサポートが最終的に実装されるのを待ってからアップグレードしたりする必要はありません。 最近の例については、macOSユニバーサルバイナリとASAR整合性チェックを参照してください。

2. Forgeのマルチパッケージアーキテクチャにより、理解と拡張が容易になります。 Forgeは明確な責任を持つ多くの小さなパッケージで構成されているため、コードフローを追跡するのが簡単です。 さらに、Forgeの拡張可能なAPI設計は、高度なユースケースのために、提供されている構成オプションとは別に、独自の追加のビルドロジックを記述できることを意味します。 カスタムForgeプラグイン、メーカー、およびパブリッシャーの作成の詳細については、ドキュメントのElectron Forgeの拡張セクションを参照してください。

破壊的な変更​

Forge 6はベータ段階で長い時間を費やしており、リリース頻度は徐々に遅くなっています。 ただし、2022年後半に開発を加速し、いくつかの最終的な破壊的な変更をv6.0.0の安定版リリース前にプッシュするために、最後のいくつかのリリースを使用しました。

Electron Forge 6ベータユーザーの場合は、最近のベータ版（>=6.0.0-beta.65）で行われた破壊的な変更のリストについては、v6.0.0 GitHubリリースノートを参照してください。

変更とコミットの完全なリストは、リポジトリのCHANGELOG.mdにあります。

フィードバックを送信してください！​

必要なものをお知らせください！ Electron Forgeチームは、常にユーザーにより適したプロジェクトを構築しようとしています。

機能リクエストを送信したり、issuesを投稿したり、フィードバックをお知らせいただくことで、Electron Forgeの改善にご協力いただけます。 また、公式のElectron Discordサーバーに参加することもできます。そこには、Electron Forgeディスカッション専用のチャネルがあります。

https://electronforge.dokyumento.jpのForgeドキュメントに関するフィードバックをご希望の場合は、electron-forge/electron-forge-docsリポジトリに同期されたGitBookインスタンスがあります。

先月、Electronのメンテナーグループがカナダのバンクーバーに集まり、2023年以降のプロジェクトの方向性について話し合いました。 会議室で4日間、コアメンテナーと招待された共同作業者が、新しいイニシアチブ、メンテナンスの痛点、および一般的なプロジェクトの健全性について話し合いました。

今後、チームは、定期的な迅速なChromiumアップグレードのリリース、バグの修正、およびすべての人にとってElectronをより安全かつパフォーマンスを向上させることに引き続き専念します。 また、コミュニティと共有したいエキサイティングなプロジェクトがいくつかあります！

変革をもたらす新しいAPI​

コンセンサスが必要なElectronプロジェクトの主要なAPI提案は、APIワーキンググループのメンバーによってレビューされるRequest for Comments（RFC）プロセスを経ます。

今年、Electronアプリの機能に新しい次元の可能性を解き放つ可能性のある2つの主要な提案を推進しました。 これらの提案は非常に実験的ですが、期待できることの概要を以下に示します！

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

この提案では、Electronの内部リソースとインターフェースする独自のネイティブNodeアドオンを、Node自身のNode-APIと同様に、アプリ開発者が記述できるようにする新しいElectron C APIレイヤーの概要を説明します。提案された新しいAPIの詳細については、こちらを参照してください。

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

多くのElectronアプリは、バニラ（未修正）のElectronではアクセスできないChromiumの内部機能と直接やり取りするために、独自のフォークを維持しています。これらのリソースをC APIレイヤーで公開することで、このコードはElectronとともにネイティブモジュールとして存在でき、アプリ開発者のメンテナンス負担を軽減できる可能性があります。

ChromiumのUIレイヤー（Views API）の公開​

内部的には、ツールバー、タブ、ボタンなど、Chromeのユーザーインターフェース（UI）のWebサイト以外の部分は、Viewsと呼ばれるフレームワークで構築されています。Views APIの提案では、このフレームワークの一部をElectronのJavaScriptクラスとして導入し、最終的には開発者がElectronアプリケーションにWeb以外のUI要素を作成できるようにすることを目標としています。これにより、アプリがWebコンテンツをハックして組み合わせる必要がなくなります。

この新しいAPIセットを可能にするための準備作業が現在進行中です。近い将来に期待できる最初のいくつかのことを以下に示します。

例：WebContentsViewを使用したウィンドウモデルのリファクタリング​

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

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

もしあなたがアプリでBrowserViewを使用しているElectron開発者であれば、ご安心ください。私たちはあなたを忘れていません！私たちは、より新しいAPIへの移行を支援するために、既存のBrowserViewクラスをWebContentsViewのシムにすることを計画しています。

参照：electron/electron#35658

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

Stackの友人たちが、Chromium ScrollViewコンポーネントをElectronのAPIに公開するイニシアチブを推進しています。この新しいAPIを使用すると、任意の子Viewコンポーネントを水平または垂直にスクロール可能にすることができます。

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

参加する​

これらのAPI提案のいずれかに興味のあるElectronアプリ開発者ですか？追加の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でインストールするか、リリースWebサイトからダウンロードできます。このリリースに関する詳細については、引き続きお読みください。

フィードバックがある場合は、Twitterで共有するか、コミュニティDiscordに参加してください！バグや機能リクエストは、Electronのissue trackerで報告できます。

注目すべき変更点​

スタックの変更​

• Chromium 106
  • Chrome 106の新機能
  • Chrome 105の新機能
  • DevTools 106の新機能
  • DevTools 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では、Chrome 103で同様の決定を下したChromeに続いて、V8サンドボックスポインターが有効になります。これは、ネイティブモジュールにいくつかの影響を与えます。この機能にはパフォーマンスとセキュリティのメリットがありますが、ネイティブモジュールにいくつかの新しい制限、例えば、外部（「オフヒープ」）メモリを指す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の新機能
  • DevToolsの新機能
• 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では、ChromeのChrome 103で同様の決定をしたことに倣い、ElectronでV8サンドボックスポインターを有効にします。これは、ネイティブモジュールにいくつかの影響があります。また、以前に、関連テクノロジーであるポインター圧縮をElectron 14で有効にしました。当時はあまり話題にしませんでしたが、ポインター圧縮はV8ヒープサイズの最大値に影響を与えます。

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

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

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

Electron Upgradesワーキンググループは、ポインター圧縮と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チームによる高レベル設計ドキュメントでしょう。

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

ネイティブモジュールをリファクタリングして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によって割り当てられたメモリにリソースを初期化します。リソースのライフタイムの間、Bufferオブジェクトへのnapi_refを保持することが重要です。そうしないと、V8がBufferをガベージコレクションし、use-after-freeエラーが発生する可能性があります。

Electron 19.0.0がリリースされました！ Chromium 102、V8 10.2、Node.js 16.14.2へのアップグレードが含まれています。詳細については以下をお読みください！

Electronチームは、Electron 19.0.0のリリースを発表できることを嬉しく思います！ npmを使用してnpm install electron@latestでインストールするか、リリースWebサイトからダウンロードできます。このリリースに関する詳細を読み進め、フィードバックがあれば共有してください！

注目すべき変更点​

Electronのリリース頻度の変更​

プロジェクトは、最新の3つのメジャーバージョンをサポートするという以前のポリシーに戻ります。Electronのバージョン管理に関するドキュメントで、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​

BrowserWindowコンストラクタオプションskipTaskbarは、Linuxではサポートされなくなりました。#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で問題を提起し、お知らせください。

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

Electron 18.0.0がリリースされました！ Chromium 100、V8 10.0、Node.js 16.13.2へのアップグレードが含まれています。詳細については以下をお読みください！

Electronチームは、Electron 18.0.0のリリースを発表できることを嬉しく思います！ npmを使用してnpm install electron@latestでインストールするか、リリースWebサイトからダウンロードできます。このリリースに関する詳細を読み進め、フィードバックがあれば共有してください！

注目すべき変更点​

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
• window.open の古い BrowserWindowProxy ベースの実装が削除されました。これにより、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 での window.open のドキュメントをご覧ください。#29405 で削除されました。

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

Electron 14.x.y は、プロジェクトの サポートポリシーに従ってサポートが終了しました。開発者とアプリケーションは、より新しいバージョンの Electron にアップグレードすることをお勧めします。

Electron 15 以降、サポート対象バージョンは最新の3バージョンから最新の4バージョンに、2022年5月の Electron 19 まで変更されました。Electron 19 以降は、最新の3バージョンをサポートする体制に戻ります。このバージョンサポートの変更は、新しいケイデンス変更の一部です。詳細については、ブログ記事をご覧ください。

次は何ですか​

短期的には、チームはChromium、Node、V8など、Electronを構成する主要コンポーネントの開発に追随することに引き続き注力すると予想できます。リリース日については約束をしないように注意していますが、約2か月ごとに、これらのコンポーネントの新しいバージョンを含むElectronの新しいメジャーバージョンをリリースする予定です。

Electronの公開タイムラインはこちらで確認できます。

今後の変更の詳細については、計画された破壊的な変更ページをご覧ください。