TSコード生成を完全にASTで実装する

[omochi]

C2TS 1.6.0 でTSのAST対応を増やしたので、
それを使ってTSコードの生成をするように書き換えました。
(というか、C2TSの改修内容は、ここで必要になるものを追加しました。)

これにより、import が必要なシンボルの列挙を、
C2TSの DependencyScanner に任せる事ができるようになりました。
そして、シンボルの利用を追跡するロジックを削除することができました。

---

現状では必要なシンボルがどのファイルにあるのかは、わからないので、
ImportMap の利用は継続しています。

生成コードのASTから、「そのソースコードでexportされたシンボル一覧」
を取得する機能を作ればC2TSだけで対応する事もできそうです。
これはimportが必要なシンボルを求める時に、
内部的には取得している情報なので、実現できそうです。

---

残念ながら、文字列を直接組み立てるのと比べると、
ASTを組み立てるコードは量が多くなってしまいます。

SwiftSyntaxは同様の問題に対して、
文字列をパースしてASTに変換するAPIを用意することで、
文字列のほうが楽な場合はそこだけ文字列合成でASTを実装できます。

ですが、これをやるにはSwift実装のTypeScriptパーサが必要になるので、
対応は厳しそうです。

---

ASTが未対応のコードを生成したい場合、
C2TSの対応を待たずに実装するためには、
TSCustomDecl, TSCustomStmt, TSCustomExpr を使用する事ができます。
これらのノードは任意の文字列をAST中に挿入できます。

しかし、この文字列に対してはシンボル解析ができないので、
カスタムノード中で新たなシンボル利用があると、
生成されるimport文に不足が出てしまいます。

ここについては、カスタムノード自身が、
ソースコード文字列とは別で、
利用しているシンボルリストを保持できる改修をすれば、
解決できます。

---

メリットとデメリットのある変更ですが、
CallableKitのTSコードの生成内容が変化する見込みが薄いのであれば、
デメリットが顕在化するリスクは低いと思いますが、
いかがでしょうか。

[sidepelican]

シンボルの利用を追跡するロジックを削除することができました。

これが嬉しいですね。手続き的な処理で試行錯誤して維持できていただけの機能なので、仕組みで検査できるようになったのは嬉しいです。

ASTを組み立てるコードは量が多くなってしまいます。

個人的には密度が下がっただけで複雑さに変化はないと思ったので、ここは問題ないと思いました。
ただ自分が書きたいコードがASTノードのどれに該当するかを調べる必要はあるので、そこが文字列でやるより大変な部分だなと思いました。

ただこのの実装ですでにいろんなASTの組み立てパターンが記述されてるので、それを見ながらやればある程度ショートカットできそうです。

他個人的には生成ファイルの改行が冗長なのが気になりました。import文とinferfaceは前の生成コードのように短いと嬉しいです。このファイルは IHogeClient の定義ジャンプで見る機会が多いため、違和感を減らしたいです。
見た目だけの話であるためこのPRではこのままでも良いです。

[sidepelican]

単純にここだけ消えるのは何か変そう？ローカルエディット機能とか使ってましたか？

[omochi]

Xcodeのローカルエディットが壊れてるので、
Package.swift を書き換えてローカルパッケージ参照に切り替えて作業していました。
その影響がコミットされてしまったと思います、すいません。

[omochi]

たしかにTypeScriptの文法は知っているからコードは書ける状況でも、
ASTではどういうノードの名前になっているのか、
は別の知識なのでそこに難しさがありますね。
ましてや僕が定義したASTで、TypeScriptの正当な何かでもないし・・・。