【ITニュース解説】Build-Time, End to End - From federation.config to remoteEntry.json

Native Federation v4は、複数の独立したウェブアプリケーション（マイクロフロントエンド）を連携させ、共通の機能やライブラリを効率的に共有するための技術である。この技術は、個々のアプリケーションを独立して開発・デプロイできる柔軟性を提供しつつ、ユーザー体験を損なわないようコードの重複を避けることを目指している。この記事では、Native Federation v4プロジェクトのビルド時、つまりソースコードが実行可能な状態に変換されるまでの過程に焦点を当て、設定ファイルから最終的な出力ファイルに至るまでの流れを解説する。

まず、Native Federationにおける基本的な役割を理解する必要がある。ホストは、他のアプリケーションの機能を取り込み、自身のアプリケーション内で表示する側の役割を担う。一方、リモートは、自身の機能や部品（例: UIコンポーネント、ルーティング設定）をホストに提供する側のアプリケーションである。これらのホストとリモートが共有する共通のライブラリやフレームワークは「共有依存関係（shared dependency）」と呼ばれ、これによりアプリケーション間で同じコードを再利用し、ダウンロード量を減らすことができる。

プロジェクトのビルド設定は、federation.config.mjsというファイルに記述される。このファイルは、どのような機能を外部に公開し、どのライブラリを共有依存関係とするかを定義する中心的な役割を果たす。 設定項目の一つであるnameは、そのアプリケーションを識別するためのユニークな名前を指定する。リモートの場合、この名前を通じてホストからそのリモートが参照される。 exposesでは、そのアプリケーションが外部に公開するモジュール（特定のコンポーネントファイルなど）を指定する。ホストは、この設定を通じてリモートが提供する機能を自身のアプリケーション内で利用可能にする。 最も重要な設定の一つがsharedである。ここでは、どのライブラリを共有依存関係として扱うかを定義する。通常、fromPackageJson()というヘルパー関数を使い、プロジェクトのpackage.jsonに記載された依存関係をまとめて共有対象とすることが推奨される。この共有設定には、いくつかの重要なプロパティがある。 singleton: trueを設定すると、そのライブラリはアプリケーション全体で常に一つのインスタンスのみが使われるようになる。これはAngularのようなフレームワークにおいて、異なるバージョンが混在して不具合を引き起こすのを防ぐために不可欠である。 strictVersion: trueは、もし他のアプリケーションが必要とするバージョンと互換性がない場合に、共有ライブラリの使用を厳しく制限する設定だ。 requiredVersionは、そのアプリケーションが受け入れるライブラリのバージョン範囲を示し、'auto'を指定するとpackage.jsonのバージョン指定が自動的に使用される。 versionは、そのアプリケーションが実際にビルドされた際に使用したライブラリの厳密なバージョンを指す。 これらの設定は、実行時にブラウザが最適な共有ライブラリのバージョンを選択する際の判断材料となる。デフォルトでは、すべてのライブラリが厳密なシングルトンとして共有されるため、安全性が高いが、バージョンに関する警告が表示される可能性があることに留意する必要がある。 skip設定は、特定のライブラリを共有対象から意図的に除外する際に使用される。除外されたライブラリは共有されず、そのアプリケーション自身のバンドル内に含まれることになる。例えば、ほとんどのアプリケーションで使われないRxJSの一部機能などを共有から外すために利用される。 また、shared内の特定のライブラリに対してincludeSecondaries: { keepAll: true }を設定することがある。これは、@angular/coreのように、メインのパッケージだけでなく、そのサブパス（例: @angular/core/rxjs-interop）もすべて共有対象に含めるための設定だ。この設定は、異なるアプリケーション間でフレームワークのサブパスが異なるバージョンでロードされることによって発生する問題を回避し、フレームワーク全体の一貫性を保つために重要である。

Native Federationのビルドプロセスは、次のステップで実行される。 まず、federation.config.mjsの設定が読み込まれ、デフォルト値の適用、スキップリストの処理、最終的な共有リストの確定が行われる。 次に、ignoreUnusedDepsという機能が動作し、実際にコード内でインポートされている共有ライブラリのみが共有リストに残される。このスキャンは、ホストであればsrc/main.tsから、リモートであればexposesで指定されたファイルから開始される。このため、リモート自身の起動コード（main.tsやbootstrap.ts）だけで使われているライブラリは共有されず、リモート自身のバンドルに含まれることになる。 その後、確定された共有ライブラリはそれぞれ個別のファイルとしてビルドされる。これらのビルド成果物はキャッシュされ、変更がない限り次回のビルドで再利用される。続けて、exposesで指定された公開モジュールもビルドされる。 最終的に、remoteEntry.jsonとimportmap.jsonという二つの重要なファイルが生成され、その後、Angularのビルドプロセスに処理が引き継がれる。この段階で、共有ライブラリはAngularのビルドからは外部依存関係として扱われ、アプリケーション自身のバンドルには含まれない。ビルドに失敗した場合、これらの連邦化ファイルは一切生成されないため、不完全なファイルが公開される心配はない。

生成されるファイルのうち、remoteEntry.jsonは、そのアプリケーションが他のアプリケーションに何を提供しているか、そして自身がどのような共有ライブラリを必要としているかを記述したファイルである。ここには、アプリケーション名、公開されているモジュールのリスト、そして共有ライブラリの名前、バージョン、必要なバージョン、singletonやstrictVersionといった設定情報が含まれる。他のアプリケーション（ホスト）は、このremoteEntry.jsonを読み込むことで、リモートが提供する機能や共有ライブラリの情報を得ることができる。 もう一つのファイルであるimportmap.jsonは、そのアプリケーション自身の視点から見た、共有ライブラリのファイルパスをマッピングしたファイルだ。例えば、@angular/coreというライブラリが、どのビルド成果物ファイル（例: angular-core-HASH.js）に該当するかを記述する。このファイルは主にそのアプリケーションが自身の外部依存関係を解決するために使われる。ブラウザで実際に動作するインポートマップは、ホストと全てのリモートのremoteEntry.jsonを統合し、実行時に動的に生成される。

ホストアプリケーションがリモートのURLをどのように知るかには、主に二つの方法がある。一つは「静的リモート」で、リモートのURLをホストのコード（例: main.ts）に直接記述する方法である。この方法はシンプルだが、リモートのURLが変更されるたびにホストを再ビルドする必要があるという欠点がある。もう一つは、より推奨される「動的リモート」で、リモートのURLリストをfederation.manifest.jsonのような外部ファイルに記述し、ホストは起動時にこのファイルを読み込む。この方法であれば、リモートのURLが変更されてもホストを再ビルドする必要がなく、同じホストのビルド成果物を複数の環境で柔軟に使い回すことができる。 また、ホストは自身のremoteEntry.jsonも公開し、実行時にホストとリモートで同じライブラリが共有対象である場合、ホストが提供するバージョンが優先されるようになっている。

このように、Native Federationのビルドプロセスでは、federation.config.mjsの設定に基づき、アプリケーションが提供する機能や共有するライブラリの情報がremoteEntry.jsonとしてまとめられる。このビルド時に行われるのは、どのバージョンを使用するかという最終的な「決定」ではなく、どのバージョンを持っているか、どのバージョンを受け入れるかという「記録」だけである。実際にアプリケーションが起動し、ブラウザ上で動作する際、様々なアプリケーションのremoteEntry.jsonが集約され、最終的にどのバージョンのライブラリを使用するかというバージョン解決が実行時に行われる。この実行時のバージョン解決の仕組みを理解することは、複雑なマイクロフロントエンド環境を管理する上で非常に重要である。