巨大な配布ファイルとの決別
Electronアプリを実行するたびに数百メガバイトのChromiumバイナリを一緒に配布するのは非効率だ。個人開発者にとって、配布ファイルのサイズはインストール率に直結する。Deno DesktopはOSネイティブのWebビューを使用する。既存の180MB規模のアプリを19MBレベルにまで削減可能だ。単なる技術変更ではなく、運用環境の重荷を軽減する作業である。
マイグレーションスプリントのチェックリスト
10日以内にリファクタリングを終えるには、既存の構造を捨てる必要がある。
- package.jsonの複雑な依存関係の代わりにdeno.lockを使用し、キャッシュ管理体系を簡素化する。
- Electron Builderやasarのような重いツールを削除し、Deno内部ビルドエンジンを設定する。
- ipcMainとipcRendererの通信レイヤーを削除し、win.bind()メソッドでプロセス制御権を統合する。
この作業を終えれば、ビルドプロセスの時間を40%短縮できる。
プラットフォーム別のWebビュー差異の制御
Mac、Windows、LinuxではWebエンジンが異なる。WKWebViewとWebView2はレンダリング結果がそれぞれ異なる。CSS仕様を解釈する方法さえ異なる。特にLinuxの古いWebKitGTKはレイアウトを頻繁に崩す。
プラットフォーム間の異質感（違和感）を減らすには、補正スクリプトをデプロイパイプラインに組み込む必要がある。
- CSSリセットコードで、すべてのブラウザのデフォルト余白を0に強制する。
- ブートストラップ段階でbindings.getPlatformMetadata()を呼び出し、実行中のOSを判別する。
- macOSではフレームレスモード時に信号機エリアを考慮して28pxの高さの余白をラッパーdivで確保し、Windowsではダークモードの検知可否に応じてCSSクラスを注入する。
この方式を適用すれば、OSごとに個別にUIを修正するコストが削減される。
ネイティブAPI呼び出しのセキュリティラッパー実装
ElectronのIPCチャネルはセキュリティ事故が多い。Deno Desktopはダイレクトバインディングでデータを伝達し、セキュリティを高める。OS機能を安全に制御するには、ラッパークラスを直接実装しなければならない。
- ファイル入出力は必ずサンドボックスパスである /app_sandbox_storage 内に限定する。
- クラスコンストラクタにPath Traversal（パストラバーサル）防止ロジックを含め、パス内の .. 文字を即座に遮断する。
- 通知などのシステム機能を呼び出す際は、引数として渡されたリソースがホワイトリストにあるか確認し、base64エンコードデータのみを使用する。
GitHub Actionsによるデプロイ自動化
OSごとに環境を設定してビルドしてはならない。GitHub Actionsの行列（マトリックス）戦略を使えば、一度のコミットでWindowsのmsi、LinuxのAppImage、Macのdmgファイルを同時に生成できる。
- ubuntu-latest環境でWindowsとLinuxを、macos-14でMacバイナリをビルドする。
- deno desktop --target コマンドに --compress=xz オプションを追加し、最終ファイルの容量を削減する。
- Linuxの成果物はxvfb-runを実行して、仮想環境で実際の動作可否をテストする。
このパイプラインを構築すれば、手動ビルドよりもデプロイサイクルが2倍速くなる。Denoへの転換は、軽量バイナリとサンドボックスセキュリティという2つの利点をもたらす。
