こんにちは、TwoGateの本間です。今回は、2024年5月11日に初開催されたTSKaigi2024へ参加したので、参加レポートをいたします。
株式会社TwoGateは「TSKaigi 2024」にBronze Sponsorとして協賛しました。TwoGateでは主にフロントエンドのフレームワークとしてAngularを採用しており、TypeScriptで開発をしています。
入口から企業ブースへ下る様子
Keynote: What's New in TypeScript
TypeScriptチームのDaniel RosenwasserさんによるKeynoteでした。
内容は主に、TypeScriptのこれまでの歩みと、今年3月にリリースされたTypeScript 5.4、今後リリース予定であるTypeScript 5.5 Betaで発表されている新機能についての解説でした。
TypeScript 5.4
- The NoInfer Utility Type
- Preserved Narrowing in Closures Following Last Assignments
TypeScript 5.5 Beta
- Type Imports in JSDoc
- Regular Expression Syntax Checking
- Inferred Type Predicates
- Isolated Declarations
発表の最後には、「12年前の開発当初には、TypeScriptがこんなにも広く使われて、こうして基調講演のために日本のコミュニティの前で発表するとは思っていなかった。」と開発者ならではの熱いメッセージを頂き、感慨深い気持ちになりました。
セッションとその感想
発表内容は大きく分けると、「型」、「AST」、「ハードウェア」の３つでした。特にハードウェアの開発言語としてTypeScriptが採用されているのは驚きでした。
聴講したセッションの中で、印象深かったものの感想を書きます。私は普段の開発でAngularを利用しているため、その目線からの感想になります。
TypeScript 関数型バックエンド開発のリアル
関数型バックエンド開発で重要視するべき点を、要点的かつ具体的に知ることができました。ドメイン層ではしっかりと型付けをし、それ以外の部分は従来と変わらない実装方針とのことです。他の発表でもTypeScriptをバックエンドに採用した事例が多く見られたので、プロダクトレベルで採用されてきているんだなと感じました。一方で、TypeScriptは関数型言語として足りない機能も多く、外部ライブラリに頼ったResult型やOption型は、例えば処理が入れ子になった際に複雑になるなどの問題もあるようです。
弊社ではバックエンド開発にTypeScriptを使用した事例は少ないですが、Ruby on RailsにSorbetを使用して静的型付けをしている事例があります。
TypeScript の抽象構文木を用いた、数百を超える API の大規模リファクタリング戦略
約400のAPIを持つExpressからNest.jsへのリプレイスをする際に、正規表現では置換が難しいため、AST（抽象構文木）による構造化した置換をした話でした。また、一気に置換するのではなく、簡易的な部分と複雑な部分を分けて段階的な移行をしたり、レビュー用のコメントも付与するなど、現実的な解法も参考になりました。
migration scriptを書くほどではないときには、ast-grep VSCodeを使うと、お手軽にASTを使用した置換ができるという知見を得ました。VSCodeで置換をする際に、同じコードだけど改行があったりなかったりする場合に簡単に置換できそうです。
Type-safety in Angular
Angularがバージョンアップすると共に、TypeScriptの型の力をより引き出せるようになったよ、という話でした。
AngularはAngularJSの時代の悪い印象を持たれがちですが、最近のアップデートではStandAlone ComponentsやSignalsなどによって開発体験が大きく向上しています。
最近のアップデートを知ると、Angularを使ってみたくなるのではないでしょうか。
ライブコーディングではCopilotがふんだんに使われていて、Copilotが賢すぎると会場でもウケていました（笑）。TypeScriptは利用事例が多いため、Copilotによる補完がとても強いと日頃から使っていて感じています。
AngularがTemplateの型チェックをするために、TCB（Type-Check Block）という仕組みがあるのは初耳でした。TCBとは、ngtscがテンプレートと意味的に同等なTypeScriptコードを生成し、それをtscで実行した際に発生したエラーをそのまま利用するという仕組みとのことです。
Prettierの未来を考える
メンテナの方による、Prettierの今後の展望の話でした。
TypeScriptを開発で利用している多くの人が、PrettierとESLintも同時に利用するかと思うので、それらを組み合わせたときの環境構築のつらさは理解に容易いでしょう。それらが解決されている最近のツールとして、DenoやBiomeを挙げていました。
BiomeとPrettierは記述されている言語が大きな違いであることは勿論ですが、BiomeはParserを内製しているのに対し、Prettierは外部のParserを使用していることがとても重要な違いであるとのことです。そして、Parserの違いがBiomeとPrettierの比較表へ如実に現れていました。Biomeは高速なParserを内製しているためパフォーマンスが優れていますが、ある言語をサポートするにはそれ用のParserを内製するため、サポートするには労力が必要です。一方で、Prettierは外部のParserを利用しているため、比較的サポートが容易とのことです。
このような内情を聞くと、BiomeがAngularをサポートするのはなかなか難しいと感じました。
日々、Angularのために記述された独自構文満載のファイルをPrettierで整形してもらっている身としては、今後もPrettierの開発を応援していきたいです。
多言語化対応における TypeScript の型定義を通して開発のしやすさについて考えた
多言語化対応のために使用している react-intl に渡す翻訳ファイルへ型定義をした話でした。
また、型定義をした際にチームメンバーから開発のしやすさで意見をもらい、 さらに as const satisfies で型定義を保ちつつ、開発のしやすさを向上したようです。
弊社でも同様の事例があり、多言語化などしたファイル[1]に型定義をおこない、inlay hintとしてエディタ上に表示させる内製VSCode Pluginを利用しています。
懇親会
CloudbaseさんのオリジナルIPAビールが振舞われていました。なんと、モルトやホップから仕込みをしたということで、本気度が伺えます。
懇親会の最後には主催から挨拶があり、締めの言葉の「TypeScriptだけに、片（型）付けて帰りましょう！」という言葉が印象的でした[2]。
おわりに
私自身こういったカンファレンスは初参加で、知り合いが全く居ない中参加しましたが、企業ブースや懇親会ではTypeScriptやそうでない事に関しても楽しく会話できました。
弊社ではTypeScriptを多く利用しているため、今後もTypeScriptの動向を積極的に追っていきたいです。
Discussion