メインコンテンツへ飛ぶ

侵入を防ごう: サンドボックスでアプリを強化

· 読むのにかかる時間 1 分

CVE-2023-4863: WebP のヒープバッファオーバーフロー が公開されたことで、この 1 週間以上は webp を描画するソフトウェアの新規リリースの連続でした。macOS、iOS、Chrome、Firefox、そして多くの Linux ディストリビューションすべてが更新を受け取ったことでしょう。 これは Citizen Lab の調査に伴うもので、「ワシントン DC を拠点とする市民団体」の使用する iPhone が iMessage 内でゼロクリック攻撃を受けたことを発見したものです。

Electron も同日、新バージョンをリリースしました。もしあなたのアプリがユーザー提供のコンテンツを描画する場合、Electron のバージョンを更新すべきです。Electron の v27.0.0-beta.2、v26.2.1、v25.8.1、v24.8.3、v22.3.24 すべてに、webp 画像のレンダリングを行うライブラリ libwebp の修正版を含んでいます。

「画像をレンダリングする」という無邪気な操作が、潜在的に危険な行為であることを私たち全員が再認識した今、私たちはこの機会を利用して、Electron にさらなる大きな攻撃が来た時、付属のプロセスサンドボックスでそれが何であろうとその爆発半径を制限できることを皆さんにお知らせしたいと思います。

サンドボックスは Electron v1 以来ずっと利用可能で、v20 ではデフォルトで有効になっています。しかし、多くのアプリ (特に以前からあるアプリ) はコードのどこかで sandbox: false としていたり、nodeIntegration: true になっていることがあります。これらは明示的に sandbox を設定しない限り、等しくサンドボックスを無効化します。 そのような行いも理解できます。ご寵愛頂いてきた方であれば、おそらく require("child_process")require("fs") を HTML/CSS と同じコードに投げ込んで実行する強力さを味わってきたことでしょう。

どうやって サンドボックスに移行するのかについて話す前に、まずは なぜ 移行したいのかについてご説明します。

サンドボックスは、すべてのレンダラープロセスを硬い檻で囲い、内部で何が起ころうと、コードが制限された環境内で実行されることを保証します。 コンセプトとしては Chromium よりもずっと古く、すべての主要なオペレーティングシステムで一つの機能として提供されています。 Electron と Chromium のサンドボックスは、これらのシステム機能の上に構築されています。 ユーザー生成コンテンツを表示しない場合でも、レンダラーが侵害される可能性を考慮すべきです。サプライチェーン攻撃のような巧妙なシナリオから、ちょっとしたバグのような単純なシナリオまで、レンダラーはあなたが意図しない動作をする可能性があります。

そうなったプロセスは CPU サイクルとメモリを自由に使うことができます。サンドボックスはこういった恐ろしい筋書きをかなり軽減してくれます。 プロセスはディスクに書き込んだり、自分自身のウィンドウを表示したりできません。 例の libwep バグの場合、サンドボックスは攻撃者がマルウェアをインストールしたり実行したりできないようにします。 実際、従業員の iPhone を狙ったオリジナルの Pegasus 攻撃の場合、通常だとサンドボックス化されている iMessage の境界を突破して携帯電話へのアクセスを得るために、サンドボックス化されていない画像処理を特に狙っていました。 この例のような CVE が発表された場合、Electron アプリを安全なバージョンにアップグレードする必要があります。しかし、その間に攻撃者が起こせる被害は劇的に制限されます。

Electron アプリケーションを sandbox: false から sandbox: true に移行するのは大変な作業です。 というのも、Electron セキュリティガイドライン の最初の草稿を私自身が書いたにもかかわらず、私自身のアプリは 1 つも移行できていないからです。 それらは今週末に変更いたしましたので、皆さんも変更してみることをお勧めします。

変更行数に怯える必要はありません。このほとんどは package-lock.json のものです。

取り組むべきことは 2 つあります。

  1. preload スクリプトや実際の WebContents で Node.js のコードを使用している場合は、Node.js とのやり取りをすべてメインプロセス (言うなればユーティリティプロセス) に移す必要があります。 レンダラーがの強力さを考えると、コードの大部分はリファクタリングの必要がない可能性が高いです。

    プロセス間通信 のドキュメントもご参照ください。 私の場合、多くのコードを移動させて ipcRenderer.invoke()ipcMain.handle() でラップすれば、メインプロセスは簡単ですぐに終わりました。 ここであなたの API 設計にはお気をつけください。もし executeCodeAsRoot(code) のような API を作成したら、サンドボックスはユーザーを守れなくなります。

  2. サンドボックスを有効にすると、プリロードスクリプトの Node.js 統合が無効になるため、require("../my-script") を使用できなくなります。 つまり、プリロードスクリプトは単一のファイルである必要があります。

    この実現には複数の方法があります。Webpack、esbuild、parcel、rollup はすべて、この役割を担います。 私は Electron Forge の優れた Webpack プラグイン を使いました。同じくらい人気のある electron-builder のユーザーの方は、electron-webpack を利用できるでしょう。

これで全てです。Webpack の巨大なパワーを使いこなすために頭を悩ませたことや、他の方法へコードをリファクタリングする機会にしようと決めたことも含めると、全体の処置には 4 日ほどかかりました。

Electron 26.0.0

· 読むのにかかる時間 1 分

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


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

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

注目すべき変更

累積的変更

破壊的変更

非推奨: webContents.getPrinters

webContents.getPrinters メソッドは非推奨となりました。 代わりに webContents.getPrintersAsync を使用してください。

const w = new BrowserWindow({ show: false });

// 非推奨
console.log(w.webContents.getPrinters());
// こちらで置き換えてください
w.webContents.getPrintersAsync().then((printers) => {
console.log(printers);
});

非推奨: systemPreferences.{get,set}AppLevelAppearancesystemPreferences.appLevelAppearance

systemPreferences.appLevelAppearance プロパティと同様に、systemPreferences.getAppLevelAppearancesystemPreferences.setAppLevelAppearance メソッドも非推奨になりました。 代わりに nativeTheme モジュールを使用してください。

// 非推奨
systemPreferences.getAppLevelAppearance();
// こちらで置き換えてください
nativeTheme.shouldUseDarkColors;

// 非推奨
systemPreferences.appLevelAppearance;
// こちらで置き換えてください
nativeTheme.shouldUseDarkColors;

// 非推奨
systemPreferences.setAppLevelAppearance('dark');
// こちらで置き換えてください
nativeTheme.themeSource = 'dark';

非推奨: systemPreferences.getColor での alternate-selected-control-text の値

systemPreferences.getColor での alternate-selected-control-text の値は非推奨になりました。 代わりに selected-content-background を使用してください。

// 非推奨
systemPreferences.getColor('alternate-selected-control-text');
// こちらで置き換えてください
systemPreferences.getColor('selected-content-background');

新機能

  • safeStorage.setUsePlainTextEncryptionsafeStorage.getSelectedStorageBackend の API を追加しました。 #39107
  • safeStorage.setUsePlainTextEncryptionsafeStorage.getSelectedStorageBackend の API を追加しました。 #39155
  • ipcRenderer.sendTo() 経由で送信されたメッセージに senderIsMainFrame を追加しました。 #39206
  • Menu にキーボードで呼び出されたときのフラグを立てるサポートが追加されました。 #38954

23.x.y サポートの終了

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

E26 (Aug'23)E27 (Oct'23)E28 (Jan'24)
26.x.y27.x.y28.x.y
25.x.y26.x.y27.x.y
24.x.y25.x.y26.x.y
22.x.y

次回予告

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

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

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

Electron 25.0.0

· 読むのにかかる時間 1 分

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


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

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

注目すべき変更

ハイライト

  • Chromiumのネットワークスタックを使用して、Electron のネットモジュール内に net.fetch を実装しました。 これは、Node.js の HTTP スタックを使用する Node の fetch()とは異なります。 #36733#36606を参照してください。
  • protocol.handleを追加しました。これは非推奨になった protocol.{register,intercept}{String,Buffer,Stream,Http,File}Protocol を置き換えます。 #36674
  • ChromiumとMicrosoftのWindows 7/8/8.1の非推奨プランと一致するように、Electron 22の拡張サポート。 詳細はこのブログ投稿の最後をご覧ください。

累積的変更

破壊的変更

非推奨: protocol.{register,intercept}{Buffer,String,Stream,File,Http}Protocol

protocol.register*Protocol メソッドと protocol.intercept*Protocol メソッドは protocol.handle に置き換えられました。

新しいメソッドは、新しいプロトコルを登録するか、既存のプロトコルを傍受するか、どのタイプの応答も可能です。

// Electron 25では非推奨
protocol.registerBufferProtocol('some-protocol', () => {
callback({ mimeType: 'text/html', data: Buffer.from('<h5>Response</h5>') });
});

// 以下で置き換えてください
protocol.handle('some-protocol', () => {
return new Response(
Buffer.from('<h5>Response</h5>'), // string または ReadableStream になりえる
{ headers: { 'content-type': 'text/html' } }
);
});
// Electron 25 で非推奨
protocol.registerHttpProtocol('some-protocol', () => {
callback({ url: 'https://electronjs.org' });
});

// 以下で置き換えてください。
protocol.handle('some-protocol', () => {
return net.fetch('https://electronjs.org');
});
// Electron 25 では非推奨
protocol.registerFileProtocol('some-protocol', () => {
callback({ filePath: '/path/to/my/file' });
});

// 以下で置き換えてください
protocol.handle('some-protocol', () => {
return net.fetch('file:///path/to/my/file');
});

非推奨: BrowserWindow.setTrafficLightPosition(position)

BrowserWindow.setTrafficLightPosition(position) は非推奨になり、代わりに BrowserWindow.setWindowButtonPosition(position) API を使うようになりました。こちらでシステム基底の位置へリセットする際には、{ x: 0, y: 0 } の代わりに null を受け付けるようになっています。

// Electron 25 では非推奨
win.setTrafficLightPosition({ x: 10, y: 10 });
win.setTrafficLightPosition({ x: 0, y: 0 });

// 以下で置き換えてください
win.setWindowButtonPosition({ x: 10, y: 10 });
win.setWindowButtonPosition(null);

非推奨: BrowserWindow.getTrafficLightPosition()

BrowserWindow.getTrafficLightPosition() は非推奨になり、代わりに BrowserWindow.getWindowButtonPosition() API を使うようになりました。こちらでカスタム位置が無いときは、{ x: 0, y: 0 } の代わりに null を受け付けるようになっています。

// Electron 25 で非推奨
const pos = win.getTrafficLightPosition();
if (pos.x === 0 && pos.y === 0) {
// カスタム位置が無い場合。
}

// 以下で置き換えてください
const ret = win.getWindowButtonPosition();
if (ret === null) {
// カスタム位置が無い場合。
}

新機能

  • net.fetch() を追加しました。 #36733
    • net.fetchfile: URL と protocol.register*Protocol で登録したカスタムプロトコルへのリクエストをサポートしています。 #36606
  • BrowserWindow.set/getWindowButtonPosition API を追加しました。 #37094
  • protocol.handle を追加しました。これは protocol.{register,intercept}{String,Buffer,Stream,Http,File}Protocol を置き換え非推奨にするものです。 #36674
  • webContents<webview> タグに will-frame-navigate イベントを追加しました。これは、フレーム階層内の任意のフレームがナビゲーションしようとするたびに発生します。 #34418
  • ナビゲーションが起きるイベントに、それを引き起こした存在の情報を追加しました。 この情報により、子フレームによって開始されるナビゲーションに対して、ナビゲーションを引き起こすような window.open を親フレームから区別できます。 #37085
  • net.resolveHost を追加しました。これは defaultSession オブジェクトを用いてホストを解決します。 #38152
  • app に新しく 'did-resign-active' イベントを追加しました。 #38018
  • webContents.print() にいくつかの標準ページサイズのオプションを追加しました。 #37159
  • enableLocalEcho フラグをセッションハンドラー ses.setDisplayMediaRequestHandler() のコールバックに追加しました。これは audioWebFrameMain の場合に、リモートのオーディオ入力をローカル出力ストリームにエコーできます。 #37315
  • powerMonitor に熱管理情報を追加しました。 #38028
  • session.fromPath() API に絶対パスを渡せるようにしました。 #37604
  • webContents にて audio-state-changed イベントを公開しました。 #37366

22.x.y 継続サポート

さらば、Windows 7/8/8.1 で述べた通り、Electron 22 (Chromium 108) の EOL 予定日は 2023 年 5 月 30 日から 2023 年 10 月 10 日へと延長されました。 Electron チームは、2023 年 10 月 10 日までこのプログラムの一部であるセキュリティ修正の Electron 22 へのバックポートを継続する予定です。 10 月のサポート日は Chromium と Microsoft 両方の延長サポート日に従っています。 10 月 11 日時点で、Electron チームは最新から 3 つの安定版メジャーバージョンが Windows 7/8/8.1 サポートすることを終了します。

E25 (May'23)E26 (Aug'23)E27 (Oct'23)
25.x.y26.x.y27.x.y
24.x.y25.x.y26.x.y
23.x.y24.x.y25.x.y
22.x.y22.x.y--

次回予告

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

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

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

Electron 24.0.0

· 読むのにかかる時間 1 分

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


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

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

注目すべき変更

累積的変更

破壊的変更

API 変更: nativeImage.createThumbnailFromPath(path, size)

maxSize 引数は size に変更されました。これに渡されたサイズがサムネイルの作成サイズになります。 以前は、Windows は maxSize より小さいときでは画像を拡大せず、macOS は常にサイズを maxSize にしていました。 この挙動がプラットフォーム間で同じなります。

// 128x128 の画像。
const imagePath = path.join('path', 'to', 'capybara.png');

// 小さい画像を拡大します。
const upSize = { width: 256, height: 256 };
nativeImage.createThumbnailFromPath(imagePath, upSize).then((result) => {
console.log(result.getSize()); // { width: 256, height: 256 }
});

// 大きい画像を縮小します。
const downSize = { width: 64, height: 64 };
nativeImage.createThumbnailFromPath(imagePath, downSize).then((result) => {
console.log(result.getSize()); // { width: 64, height: 64 }
});

新機能

  • cookies.get()HttpOnly な Cookie をフィルターできる機能を追加しました。 #37365
  • logUsageshell.openExternal() のオプションに追加しました。これにより、Windows で SEE_MASK_FLAG_LOG_USAGE フラグを ShellExecuteEx に渡せます。 SEE_MASK_FLAG_LOG_USAGE フラグは、頻繁に使用されるプログラムやその他の動作をトラッキングできる形でユーザーが起動し始めたことを示します。 #37291
  • typeswebRequest フィルターに追加し、リッスンするリクエストをフィルターする機能を追加しました。#37427
  • 新しく devtools-open-url イベントを追加し、webContents で開発者が新しいウインドウを開けるようになりました。 #36774
  • webContents.print() にいくつかの標準ページサイズのオプションを追加しました。 #37265
  • enableLocalEcho フラグをセッションハンドラー ses.setDisplayMediaRequestHandler() のコールバックに追加しました。これは audioWebFrameMain の場合に、リモートのオーディオ入力をローカル出力ストリームにエコーできます。 #37528
  • アプリケーション固有のユーザー名を inAppPurchase.purchaseProduct() に渡せるようになりました。 #35902
  • window.invalidateShadow() が公開され、これは macOS での残留する視覚効果を消去できます。 #32452
  • プログラム全体の最適化が、Electron の Node のヘッダー構成ファイルにて既定で有効になりました。これにより、コンパイラは (コンパイルの) モジュールベースではなくプログラム内のすべてのモジュールからの情報を使用して最適化を実行できます。 #36937
  • SystemPreferences::CanPromptTouchID (macOS) が Apple Watch をサポートするようになりました。 #36935

21.x.y サポートの終了

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

さらば、Windows 7/8/8.1 で述べた通り、Electron 22 (Chromium 108) の EOL 予定日は 2023 年 5 月 30 日から 2023 年 10 月 10 日へと延長されました。 Electron チームは、2023 年 10 月 10 日までこのプログラムの一部であるセキュリティ修正の Electron 22 へのバックポートを継続する予定です。

E24 (Apr'23)E25 (May'23)E26 (Aug'23)
24.x.y25.x.y26.x.y
23.x.y24.x.y25.x.y
22.x.y23.x.y24.x.y
--22.x.y22.x.y

次回予告

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

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

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

10 年目の Electron 🎉

· 読むのにかかる時間 1 分

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

electron/electron での @aroben による最初のコミット

その後、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 でアプリを作り始め (初期の採用企業は SlackGitKrakenWebTorrent など)、このプロジェクトは Electron という適切な名前に変更されました。

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

Electron の週間ダウンロード数の時間変化のグラフ

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の管理体制を形成する、より大きな協力者のグループの一部に過ぎません。2

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

info

詳しく知りたい方は、electron/governance リポジトリをご確認ください!

コミュニティ

オープンソースにおけるコミュニティの分野は難しいです。アウトリーチのチームが「コミュニティマネージャー」と書かれたトレンチコートを着た十数人のエンジニアである場合は特に難しくなります。 とはいえ、大規模なオープンソースプロジェクトであるということは、多くのユーザーを抱えているということであり、彼らの 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 をコンパイルできるようになりました!

info

オープンソース貢献者の方は、Electron Build Tools にてデフォルトで利用できる Not Goma の読み取り専用キャッシュをお試しいただけます。

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 のあるどのデバイスからでもパッケージの公開を検証できます。

info

自分のプロジェクトで CFA を試してみたい方は、その GitHub リポジトリドキュメント をご確認ください。 CI プロバイダとして CircleCI をご利用の場合、CFA を使ったプロジェクトの基盤を素早く組むための 便利なオーブ も用意されています。

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 による最新で最高のフレームワークを保ち続けます。

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

Footnotes

  1. これは実際には、2017 年に Electron に吸収されて git 履歴がマージされたelectron-archive/brightray プロジェクト での最初のコミットです。 でも細かいことはいいでしょう? 誕生日ですから、ルールはこちらで決めちゃいました!

  2. 一般に信じられていることとは異なり、なんとElectronはGitHubやMicrosoftの所有ではなく、OpenJS Foundationの一部となっています。

Electron 23.0.0

· 読むのにかかる時間 1 分

Electron 23.0.0 がリリースされました! これには Chromium 110、V8 11.0、Node.js 18.12.1 へのアップグレードが含まれています。 さらに、Windows 7/8/8.1 のサポートは廃止されました。 詳しくは以下をご覧ください!


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

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

注目すべき変更

累積的変更

新機能

  • label プロパティを Display オブジェクトに追加しました。 #36933
  • ユーザーのシステム言語を返す app.getPreferredSystemLanguages() API を追加しました。 #36035
  • WebUSB API のサポートを追加しました。 #36289
  • SerialPort.forget() のサポートを追加しました。これは、特定のオリジンが拒否されたときに Session オブジェクトで発生する新規イベント serial-port-revoked の利用と同様です。 #35310
  • 開発者が macOS での Mission Control をオプトアウトできるように、新しく win.setHiddenInMissionControl API を追加しました。 #36092

Windows 7/8/8.1 のサポートの削除

Electron 23 は Windows 7/8/8.1 に対応しなくなります。 Electron は予定されている Chromium の非推奨ポリシーに従っており、そちらは Chromium 109 におけるWindows 7/8/8.1、および Windows Server 2012 と 2012 R2 のサポートを非推奨 (詳細はこちら) としています。

API の破壊的変更

以下は、Electron 23 での破壊的変更点です。 これらの変更と今後の変更については、破壊的変更の計画 のページで詳しく説明されています。

削除: BrowserWindow の scroll-touch-* イベント

非推奨となっていた BrowserWindow の scroll-touch-beginscroll-touch-end 及び scroll-touch-edge のイベントは削除されました。 代わりに、新しく利用可能となった WebContents の input-event イベント を使用してください。

// Electron 23.0 で削除
-win.on('scroll-touch-begin', scrollTouchBegin)
-win.on('scroll-touch-edge', scrollTouchEdge)
-win.on('scroll-touch-end', scrollTouchEnd)

// こちらに置換
+win.webContents.on('input-event', (_, event) => {
+ if (event.type === 'gestureScrollBegin') {
+ scrollTouchBegin()
+ } else if (event.type === 'gestureScrollUpdate') +{
+ scrollTouchEdge()
+ } else if (event.type === 'gestureScrollEnd') {
+ scrollTouchEnd()
+ }
+})

20.x.y サポートの終了

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

E22 (Nov'22)E23 (Feb'23)E24 (Apr'23)E25 (May'23)E26 (Aug'23)
22.x.y23.x.y24.x.y25.x.y26.x.y
21.x.y22.x.y23.x.y24.x.y25.x.y
20.x.y21.x.y22.x.y23.x.y24.x.y

次回予告

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

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

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

Electron 22.0.0

· 読むのにかかる時間 1 分

Electron 22.0.0 がリリースされました! これには新しいユーティリティプロセス API、 Windows 7/8/8.1 サポートの更新と、Chromium 108、V8 10.8、Node.js 16.17.1 へのアップグレードが含まれています。 詳しくは以下をご覧ください!


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

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

注目すべき変更

累積的変更

注目の機能

UtilityProcess API #36089

新しい UtilityProcess メインプロセスモジュールは、Node.js のみと統合した軽量の Chromium 子プロセスを作成できる一方、MessageChannel でサンドボックス化したレンダラとの通信もできます。 API は Node.js の child_process.fork をベースに設計されており、移行が容易です。主な違いはそのエントリポイントの modulePath がアプリケーションのパッケージ内でなければならず、信頼できるスクリプトのみがロードできます。 さらに、このモジュールはデフォルトでレンダラーとの通信チャンネルを確立しないので、メインプロセスがアプリケーションで唯一信頼できるプロセスであるという契約を維持します。

新しい UtilityProcess API については、こちらのドキュメント で詳しく説明しています。

Windows 7/8/8.1 サポートの更新

info

2023/02/16: Windows Server 2012 サポートの更新情報

先月、Google は Chrome 109 が Windows Server 2012 および Windows Server 2012 R2 に対して 2023 年 10 月 10 日まで致命的なセキュリティ修正を受け続ける ことを発表しました。 これに伴い、Electron 22 (Chromium 108) の EOL の予定日を 2023 年 5 月 30 日から 2023 年 10 月 10 日に延長します。 Electron チームは、2023 年 10 月 10 日までこのプログラムの一部であるセキュリティ修正の Electron 22 へのバックポートを継続する予定です。

なお、Windows 7/8/8.1 についてはさらなるセキュリティ修正を行いません。 Electron 23 (Chromium 110) も、既報の通り Windows 10 以上でのみ機能します。

Electron 22 は、Windows 7/8/8.1 をサポートする最後の Electron メジャーバージョンとなります。 Electron は Chromium の非推奨の方針の予定に従っており、Chromium 109 での Windows 7/8/8.1 サポートが非推奨になります (詳細はこちら)

Electron 23 以降のメジャーリリースでは、Windows 7/8/8.1 には対応しません。

さらなる注目の変更

  • Linux と Windows で Web Bluetooth の PIN ペアリングに対応しました。 #35416
  • 新しい Fuse として LoadBrowserProcessSpecificV8Snapshot を追加し、メイン/ブラウザプロセスで browser_v8_context_snapshot.bin ファイルからその v8 スナップショットを読み込めるようにしました。 それ以外のプロセスでは、現在使っているのと同じパスを使用します。 #35266
  • そのウインドウを開いたウインドウにアクセスするための WebContents.opener と、WebFrameMain インスタンスに対応する WebContents を取得するための webContents.fromFrame(frame) を追加しました。 #35140
  • 新しいセッションハンドラ ses.setDisplayMediaRequestHandler による navigator.mediaDevices.getDisplayMedia のサポートを追加しました。 #30702

API の破壊的変更

以下は、Electron 22 での破壊的変更点です。 これらの変更と今後の変更については、破壊的変更の計画 のページで詳しく説明されています。

非推奨: webContents.incrementCapturerCount(stayHidden, stayAwake)

webContents.incrementCapturerCount(stayHidden, stayAwake) は非推奨になります。 ページのキャプチャ完了時に webContents.capturePage で自動的に処理されるようになりました。

const w = new BrowserWindow({ show: false })

- w.webContents.incrementCapturerCount()
- w.capturePage().then(image => {
- console.log(image.toDataURL())
- w.webContents.decrementCapturerCount()
- })

+ w.capturePage().then(image => {
+ console.log(image.toDataURL())
+ })

非推奨: webContents.decrementCapturerCount(stayHidden, stayAwake)

webContents.decrementCapturerCount(stayHidden, stayAwake) は非推奨になります。 ページのキャプチャ完了時に webContents.capturePage で自動的に処理されるようになりました。

const w = new BrowserWindow({ show: false })

- w.webContents.incrementCapturerCount()
- w.capturePage().then(image => {
- console.log(image.toDataURL())
- w.webContents.decrementCapturerCount()
- })

+ w.capturePage().then(image => {
+ console.log(image.toDataURL())
+ })

削除: WebContents の new-window イベント

WebContents の new-window イベントは削除されました。 これは webContents.setWindowOpenHandler() に置き換えられます。

- webContents.on('new-window', (event) => {
- event.preventDefault()
- })

+ webContents.setWindowOpenHandler((details) => {
+ return { action: 'deny' }
+ })

非推奨: BrowserWindow の scroll-touch-* イベント

BrowserWindow の scroll-touch-beginscroll-touch-end 及び scroll-touch-edge のイベントは非推奨になりました。 代わりに、新しく利用可能となった WebContents の input-event イベント を使用してください。

// 非推奨
- win.on('scroll-touch-begin', scrollTouchBegin)
- win.on('scroll-touch-edge', scrollTouchEdge)
- win.on('scroll-touch-end', scrollTouchEnd)

// こちらに置換
+ win.webContents.on('input-event', (_, event) => {
+ if (event.type === 'gestureScrollBegin') {
+ scrollTouchBegin()
+ } else if (event.type === 'gestureScrollUpdate') {
+ scrollTouchEdge()
+ } else if (event.type === 'gestureScrollEnd') {
+ scrollTouchEnd()
+ }
+ })

19.x.y サポートの終了

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

E19 (May'22)E20 (Aug'22)E21 (Sep'22)E22 (Nov'22)E23 (Jan'23)
19.x.y20.x.y21.x.y22.x.y23.x.y
18.x.y19.x.y20.x.y21.x.y22.x.y
17.x.y18.x.y19.x.y20.x.y21.x.y

次回予告

Electron プロジェクトは 2022 年 12 月の 1 ヶ月間休止し、2023 年 1 月から復帰します。 詳細については、12 月の休止のブログ記事 をご覧ください。

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

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

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

さらば、Windows 7/8/8.1

· 読むのにかかる時間 1 分

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 ESUWindows 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

2023/02/16: Windows Server 2012 サポートの更新情報

先月、Google は Chrome 109 が Windows Server 2012 および Windows Server 2012 R2 に対して 2023 年 10 月 10 日まで致命的なセキュリティ修正を受け続ける ことを発表しました。 これに伴い、Electron 22 (Chromium 108) の EOL の予定日を 2023 年 5 月 30 日から 2023 年 10 月 10 日に延長します。 Electron チームは、2023 年 10 月 10 日までこのプログラムの一部であるセキュリティ修正の Electron 22 へのバックポートを継続する予定です。

なお、Windows 7/8/8.1 についてはさらなるセキュリティ修正を行いません。 Electron 23 (Chromium 110) も、既報の通り Windows 10 以上でのみ機能します。

今後の予定

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

安息の冬 その 2 (12 月 22 日)

· 読むのにかかる時間 1 分

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 6 の紹介

· 読むのにかかる時間 1 分

待望の 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
関連項目

Forge の理念やアーキテクチャについては、Why Electron Forge 解説ドキュメントをご覧ください。

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

完全な書き直し

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

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

違うパッケージをインストールしないように

バージョン 5 以前では、Electron Forge は npm 上に electron-forge パッケージとして公開していました。 v6 での書き換えから、Forge は代わりに多くの小さなプロジェクトを持つ monorepo プロジェクトとして構成されるようになりました。

公式サポート

これまで 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

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

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

第一級の webpack サポート

上記のスニペットは Forge の Webpack Template を使用するもので、新規 Electron プロジェクトのスタート地点として推奨しています。 このテンプレートは @electron-forge/plugin-webpack プラグインを中心に構築されており、webpack と Electron Forge を以下の方法で統合しています。

  • webpack-dev-server によるローカル開発フローの強化、レンダラーにおける HMR のサポートも含む。
  • アプリケーションのパッケージ化の前に webpack バンドル用のビルドロジックの処理。
  • webpack のバンドル処理におけるネイティブ Node モジュールのサポートの追加。

TypeScript のサポートが必要な場合は、代わりに Webpack + TypeScript Template の利用を検討してください。

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

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

cd my-app
yarn add --dev @electron-forge/cli
yarn 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 レポジトリに同期していますのでそちらにお願いします。