TSKaigi2025 Day2 メモ会場

後方互換性を完璧に保つためには、実装を 1:1 で Go に書き換えるしかなかった
- 言語処理系は後方互換性がすべて
- Plug and Play であるべき！
- こうすると、古いバージョンをメンテしなくて良くなる (単に置き換えればいいので)
もう IPC 版の API も触れるっぽいな
なぜプロジェクトを 4 分割するのか
- 毎回同じ分割にしないと、分割結果が決定的でなくなるので、型エラーの順番が変わる可能性がある
並列化によって、Union 型などに明確に順序を与えないと結果が決定的でなくなるので、そこは挙動を変更している
API 使っているとしんどい
- ts-morph
  - https://github.com/dsherret/ts-morph/issues/1621
- typia も相当しんどそう、ts-patch とかも使えなくなるんじゃないだろうか...
  - MS が空気読んで ts-patch レベルで介入できる API を提供してくれることを祈るしか

Volar.js すごい
- CreateVirtualCode, Mapping
既存の TS / CSS の LanguageServer を共存させないと完全な言語機能が動かなくて困る
- 1 file に複数 LS をつなぐのは、LSP の標準仕様には規定されていない
- が、メジャーなエディタはだいたい自前実装しているので事実上動くと見て良い
壊れかけの CSS をパースする技術
- https://github.com/postcss/postcss-safe-parser
LS の競合しんどいな
- エディタ組み込みの LS ってオーバーライドするの想定されていないだろうから、Rename Request が吸われる問題まあまあどうしようもないんじゃないだろうか...

消し忘れるのわかるわ
- 誰も興味ない、わかる
FeatureFlag の取得結果を定数とみなせば順当に静的にやれるのはそうだな
定数伝搬は、実際にコードを変えるのでなく内部で「ここは定数ですよ」と言っていく
テスト消すのたしかになぁ
- たしかに、true に安定化するならシンプルに mock 消すだけで終わりか。そりゃそうだ
- 問題は多分リリース前の方のテストだよな
  - これはケースごと消すのかな？
  - 当たりだ！そりゃそうだよね
とはいえデッドコードの削除には限界があるよね
- 副作用とか、定数だけを返している関数を消していいのか...
  - これはチームごとのコンテキストや、設計文化に依存している