アーキテクチャがバンドルされていない: 4 つのフロントエンド モジュールがスタンドアロン + OSS ミラー強化

R4: フロントエンドを真に独立したモジュールに分割する

スタジオのフロントエンドは十分に大きくなり、その 4 つの最も重いパッケージ (チャット、ワークベンチ、設定、ダッシュボード) はすべてメイン リポジトリに埋め込まれ、一緒にコンパイルされ、一緒にリリースされました。開発者にとって、チャットで 1 行変更することは、フロントエンド全体が再構築されるまで待つことを意味します。アーキテクチャ的には、4 つのブロック間のもつれた依存関係を解くのがますます困難になってきました。この日の R4 計画では、これら 4 つのパッケージをそれぞれ独立したサブモジュールとして登録し、それぞれが独自のリポジトリ、独自のバージョン、独自の CI を持ちました。利点はすぐに現れました。各モジュールは独立して反復およびテストでき、チャットに触れてもワークベンチの再構築が強制されることはありません。欠点も明らかです。管理するサブモジュールが増えることです。しかし、プロジェクトが「迅速なプロトタイプ」から「長期保守可能」に移行する場合、このステップは遅かれ早かれ来る必要があり、早い方が良いです。

CLI 依存関係クロージャはスタンドアロンにもなります

フロントエンドだけではありません。この日はまた、CLI の依存関係クロージャー (コントラクト、エージェントホスト、プラットフォーム IO、コア) をメイン リポジトリからスタンドアロンのサブモジュール リポジトリに抽出しました。以前は、これらはメイン リポジトリのサブディレクトリとして存在し、1 つの node_modules と 1 つのビルド パイプラインを共有していました。ただし、CLI は基本的に独立した製品であり、異なる Studio バージョン間で互換性を維持する必要があり、モノリポジトリに埋め込まれているため柔軟性が制限されました。抽出後は、CLI で個別にバージョン管理とテストを行うことができ、OSS ミラーはこれらのリポジトリを同期して完全にビルドするだけで済みます。これまでは、依存関係が欠落しているため、パブリック ミラーの「bun install」が失敗し続けていました。

OSS ミラー: 「閲覧可能」から「構築可能」へ

この日は、パブリック OSS ミラー (ForgeaX-Games/forgeax-studio) を徹底的に強化しました。最大の変更点: パブリック リポジトリへのコードのプッシュは、メインに直接送信されなくなりました。PR + 自動マージ フローを経由する必要があります。つまり、すべての同期が CI チェック、レビュー証跡、ロールバック ポイントを取得することになります。同時に、パブリック リポジトリには初めて実際のビルド CI が追加されました。タイプ チェック、「bun fx setup」、スモーク テストがエンドツーエンドで実行され、オープンソース ユーザーが実際にコンパイルされたコードを確実に受け取ることができます。セキュリティ ホールも塞がれました。以前は管理者がブランチ保護をバイパスして直接プッシュできました。ここで「enforce_admins=true」はそのパスを閉じます。 MIRROR_TOKEN リークも修正され、PR 時間ミラーのドライラン ゲートが追加されました。一言で言えば、ミラーは「参照できるがビルドできない可能性のあるコード」から「CI はビルドを保証し、プロセスは追跡可能であることを保証する」に変わりました。

ビューポート 2×2 再設計: 実行 × 表示直交モード

この日は、ビューポート 2×2 の再設計という重要な設計仕様も実現しました。中心となるアイデアは、「実行モード」(編集/再生) を「表示モード」(シーン/ゲーム) から 2 つの直交する次元に分離し、2×2 マトリックスを形成することです。以前は、エディタの編集と再生は相互に排他的な 2 つの状態であり、ビューポート全体が切り替え時に再構築されました。新しいデザインでは、さまざまな実行状態に応じて、シーン ビューとゲーム ビューの両方を同時に表示できます。これは、UE5 のエディター エクスペリエンスと一致させるための一歩であり、前後に切り替えることなく 1 つの画面で編集とプレビューを行うことができます。

v0.3.3 自動夜間リリース + 大量のビルド修正

この日、夜間のリリース パイプラインによって v0.3.3 が自動的に生成されることに成功しました。しかし、このプロセスでは、途中でかなりの数の問題も明らかになり修正されました。デスクトップ ビルドには Bun サイドカー バイナリが欠落し、再帰的サブモジュール チェックアウトは断続的に失敗し、再試行メカニズムが必要でした。Vite エイリアス パスはパッケージ名の再構築に追いついていませんでした。また、Tauri ビルドはコントラクトから移動した型定義を見つけることができませんでした。また、サーバー側ワークベンチの GUID 再マッピングのバグと、プラットフォーム IO アセット ルートが 1 つずつオフになる問題も修正されました。それぞれの修正自体は小規模ですが、それらを組み合わせると、「自動リリース パイプラインが実行可能」から「自動リリース パイプラインが確実に実行される」までの重要なステップとなります。

この日が意味するもの

この日のキーワードは「境界」。プロジェクトがラピッド プロトタイピングから成熟期に移行するときに、最も重要なことの 1 つは、コード内に明確な境界線を引くことです。つまり、どの部分が独立したモジュールで、誰が誰に依存し、どれが単独でリリースできるかです。 R4 分割と CLI 依存関係の抽出により、メイン リポジトリ内に境界が描画されます。 OSS ミラーを強化すると、内部リポジトリとパブリック リポジトリの間に境界線が引かれます。ブランチ保護と PR フローは、「人」と「コード変更」の間に境界線を引きます。境界が明確になると、各部分が独立して進化、テスト、リリースできるようになり、プロジェクトは「1 人で大きな泥のボールを押す」状態から「それぞれが独自に前進する明確なモジュールのセット」に移行できます。