SingleSPAは機能します。Import Mapは自律的に管理されません
SingleSPAは機能します。React、Vue、Angularのアプリを一つのページ上で実行でき、それらは独立してロードされます。フレームワークは期待通りの働きをします。
問題はフレームワークではありません。その周囲のエコシステムにあります。
分散アーキテクチャでは、オーナーシップ、監査、そしてガバナンスが必要です。SingleSPAは、import mapが調整の中心的役割を果たすため、これらの必要性を可視化します。
import mapはroot config内に存在します。それはJSONファイルです。すべてのmicro frontend (MFE) に対して、どのバージョンのReactをロードすべきかを指示します。理論上、それは「信頼できる唯一の情報源（source of truth）」ですが、実際には誰もその管理責任を負っていません。
各チームは自身のMFEを所有していますが、mapを所有している人は誰もいません。
これにより、以下のような問題が発生します：
- チームがMFEを廃止しても、map内にエントリが残ったままになる。
- 新しい依存関係が登場しても、誰もそれをmapに追加しない。
- 無視している間に、mapが形骸化していく。
私たちのmapの中に、8ヶ月間デプロイされていないMFEがあることを発見しました。それはすでに機能していませんでしたが、本番環境では依然としてロードされていました。誰も見ていなかったため、誰も気づきませんでした。
ビルド時にmapを自動生成することを考えるかもしれません。私たちも試しましたが、新たな問題、つまりマージコンフリクトが発生しました。14ものチームがデプロイのたびに一つのJSONファイルに書き込もうとすれば、CIパイプラインは混乱を極めることになります。
もう一つの問題はドリフト（乖離）です。 パターンは単純です。config内でReactをexternalとしてマークし、import mapに提供させます。これにより、バンドルの重複を防ぐことができます。
しかし、誰かがコードをリファクタリングしたとき、誤ってReactを再びMFE内にバンドルしてしまうことがあります。ビルドは通り、テストも通り、デプロイも成功（green）します。
気づくのは、以下のような時だけです：
- バンドルサイズが急増したとき。
- バージョンの不一致によってコンポーネントが壊れたとき。
- Chrome DevToolsでReactが2回ロードされているのを見たとき。
システムを監査したところ、独自のReactを同梱してしまっているMFEが2つ見つかりました。それらのビルドは成功しており、彼らはコンプライアンス違反に陥っていることに全く気づいていませんでした。
import mapとpackage.jsonファイルは、2つの別々の入力です。それらは静かに乖離していきます。
CIチェックで重複したバンドルを見つけることはできますが、バージョンの不一致を見つけることはできません。MFE AがReact 18.2を使用し、MFE Bが18.3を使用している場合、ビルドは失敗しません。しかし、実行時に共有コンポーネントが壊れることになります。
Reactをアップデートする必要があるとき、私たちは14もの異なるリポジトリをgrepして回るのに何時間も費やしています。これは非効率的です。
これを解決するために、私たちはツールを構築しました。このツールは2つのことを行います。
- すべてのMFEのpackage.jsonからバージョンマトリックスを作成します。
- そのマトリックスをimport mapと比較します。
このツールは、その乖離（ギャップ）を可視化します。どのチームが準拠しており、どのチームが乖離しているかを示します。また、古いエントリや壊れたURLも見つけ出します。私たちは毎週月曜日の朝にこれを実行しています。所要時間はわずか12秒です。
私たちが学んだ教訓は、技術的なことではありませんでした。あらゆる分散アーキテクチャには、共有インフラストラクチャの責任者（オーナー）が必要です。SingleSPAにおいて、import mapはインフラストラクチャです。それを単なる共有ファイルとして扱わないでください。管理された資産（マネージド・アセット）として扱ってください。
あなたはどう対処していますか？import mapのオーナーはいますか？それとも、月曜日の朝をファイルのgrepに費やしていますか？
出典: https://dev.to/siongsheng/singlespa-works-import-maps-dont-manage-themselves-4jbe