推移的な依存関係によって引き起こされるモジュール依存関係チェーンの悪夢を回避するにはどうすればよいですか？

多くの（ほとんど？）AngularJSの人々は、AngularJSアプリを多くのモジュールに分割することを提唱しているようです。

Brian Fordは彼のブログで、レイヤー（コントローラー、サービスなど）ごとのパッケージ化は「ばかげた」概念であると既に述べているので、ここでは説明しません。（http://briantford.com/blog/huuuuuge-angular-appsを参照してください。）

ただし、アプリを機能ごとにモジュール化するとします。おそらく、これらの機能モジュールをロードするための標準のappモジュールに加えて、usersモジュールとmessagesモジュールがあります。ユーザー機能に関連するルートをユーザーモジュールに、メッセージ関連のルートをメッセージモジュールに慎重に配置します。今、私の心の中で、あなたはngRouteの各機能モジュールに依存関係を作成しました。したがって、各モジュールは、依存関係の配列に「ngRoute」をリストする必要がありますよね？

残念ながら、AngularJSはそれを台無しにすることを非常に簡単にします。あなたの場合はアプリのモジュールがロードの両方のユーザーとメッセージが、唯一のユーザーのリストを依存関係として「ngRoute」、それは実行時に問題ではない：$ routeProviderはまだで、あなたの設定機能の中に注入されるメッセージの本質的により解決された、ユーザーのモジュールのngRouteへの依存。

私の問題は、さまざまな機能モジュールをロード/参照する「アプリ」モジュールの一般的なパターンにある可能性があります。推移的な依存関係と同様に、このパターンは私にとって意味があります。問題なのは、Angularの特定の実装が、モジュールがそのモジュールの依存関係を間接的に参照しない場合をマスクできることです。モジュールは特定のアプリのコンテキストで機能する可能性があります（モジュールが別の「アプリ」モジュールによって参照されており、その依存関係も直接または間接的に参照されているため）。ただし、モジュールを別のアプリにコピーすると、失敗します。依存関係がないため。

ほとんどの人は、usersモジュールが基本的にmessagesモジュールの依存関係になっているという事実をあまり考慮しないだろうという印象を受けます。しかし、それは私が過去を見るのに苦労している問題です。私にとって、機能モジュール間にこれらの混乱する依存関係を作成する可能性がある場合、それはモジュール化の正味の利点を実際に減少させ、アプリのすべての機能のすべてのコンポーネントをカプセル化する単一のアプリモジュールを用意するだけです。

私は多くの小さなモジュールを主張しません、それらの利益は小さすぎます。角度モジュールは、実際にはモジュールシステムではありません。それらは実際の名前空間を提供せず、厳密でもありません。他のアクティブなモジュールが依存関係を「インポート」すると、通常は機能します（前述のとおり）など。このため、モジュールごとに依存関係を「文書化」するのに役立ちません。不完全になります。

非常に粗い/大きいモジュールに固執するだけです。私は主にそれらを依存関係の注入コンテナー構成と見なすことを学び、それほど「コンポーネント化」する手段ではありませんでした。これらすべての「モジュール」は通常、とにかくアプリを実行しなかったかのように、YAGNIに違反します。再利用に関する考慮事項は、ほとんどの場合ほとんど実現されない約束です。

最近では、TypeScriptのモジュールを使用してコードを分割しています。Angularモジュールの依存関係私は、主にサードパーティのもののために予約しています。