PagageGeneratorで依存先モジュールの依存対象ファイルを生成対象にする

[sidepelican]

課題

Core ← Entities ← Appのように依存関係があるコードベースにおいて。
Entitiesの一部の型に対してコード生成を試みたい場合に、もしEntitiesがCoreの型に依存している場合、現在はCoreも明示的にコード生成をする必要があります。
ここで、実際に必要なCoreの型はごく少数で、Coreの全ての型を生成対象にしたくはありません。

方針

PackageGeneratorはcontextと生成対象のmodulesをそれぞれ渡してコード生成を行うインターフェースとなっています。
もしmodulesが依存している型がcontextに含まれていた場合、その型もコード生成の対象となるようにします。

これにより、読み取りは広く行ってコード生成する範囲は狭くする、という運用が可能になります。
読み取りは未解決のシンボルなどを含められるため広く行うことができ、本当に必要な場面のみシンボルの解決が必要な形にすることで、C2TS導入の敷居を下げます。

変更内容

コード生成のロジックを全体的に改修し、以下の3つのステップに分けて実行します。

1. contextから全ての型をスキャンして、exportされるTSシンボルを収集する
   • この際、エラーを無視することで変換できないファイルを読み取れるようにする
2. TSシンボルからそれが含まれるファイルを特定する逆引き辞書を作る
3. modulesに指定された型についてTSへの変換を実行する。依存されたシンボルを2で作った辞書から調べ、まだ変換されてなければ変換キューに追加する。これをキューが空になるまで繰り返す。

注意点として、変換は型単位ではなくファイル単位となっています。これは単にファイル内のシンボル間依存関係も調べる必要があってそこまで頑張れてないからです。

[omochi]

なるほど。
CoreとEntitiesを読み込ませるが、明示的な変換対象はEntitiesだけ指定して、
Coreは必要なところだけ変換させるんですね。
いいアイデアだと思います。

実装は難しそうだったので今度見ます。

[omochi]

よくわからない部分が多いので解説が欲しいです

[sidepelican]

@omochi 方針を見直し、改修しました。PRのdescriptionも更新しました。再度レビューをお願いします

[omochi]

ありがとうございます。
機能アイデアと実装方針良いと思います。

コードとロジックもわかりやすかったです。

変換対象のソースをスタックで持ってループして、
再訪問を防ぐためのチェックリストを合わせて持っているだけですね。

新しい変換対象ソースを見つけ出すところが、
TS側のインポート文の生成と連動してるのがわかりやすいです。

[omochi]

マージします