クラウドワークス エンジニアブログ

日本最大級のクラウドソーシング「クラウドワークス」の開発の裏側をお届けするエンジニアブログ

TSKaigi 2024参加レポート

アイキャッチ:TSKaigi 2024参加レポート

皆様こんにちは。クラウドソーシングサービス「クラウドワークス」にてエンジニアをしております@okuto_oyamaです。今回は、5月11日に開催されたTSKaigi 2024に参加してきたのでその参加レポートをお届けします。

TSKaigi 2024とは

tskaigi.org

TSKaigi 2024は、日本最大級のTypeScriptをテーマとした技術カンファレンスです。会場は昨年のVue Fes Japan 2023のときと同様に、中野セントラルパーク カンファレンスにて開催されました。

TSKaigiのロゴとスポンサー情報が載ってあるスライドがプロジェクターを介して投影されている

オフライン参加とオンライン視聴を含めた総参加者は2400人以上となっており、とても注目が集まった技術カンファレンスになったと言えます。

TSKaigi 2024では合計3トラックに分かれており、セッション30分・LT5分でそれぞれ発表が行われていました。フロントエンド開発にとどまらず、バックエンド開発や生成AIとの開発、ハードウェアにおけるTypeScript、AST、型システムについて等、幅広いトピックが取り上げられていました。

会場ではお弁当も提供されており、各トラックにてスポンサーLTを聴きながら食事を楽しむことができました。

お昼の時間に提供されていた特製幕の内弁当の写真

スポンサーブースでも様々な参加型の展示が展開されていました。TypeScriptと関連したブースだと、株式会社ビットキーのブースでは「こんなTypeScriptは嫌だ!」というボードが設置されており、各々の嫌なTypeScriptについてを投稿できたり、株式会社ASCENDのブースでは各人に配られた型のカードに対して値のカードが一致するかの神経衰弱が遊べました。その他、リフレッシュメントスポンサーやコーヒースポンサー、ビールスポンサーといった形でスポンサー提供している企業もありました。

株式会社ビットキーのスポンサーブースの光景。「こんなTypeScriptは嫌だ!」というボードが設置してありポストイットで各々が思う嫌なTypeScriptのことが貼り付けられている

ちたみに私は個人スポンサー枠で参加させていただきました。公式サイトへの掲載やTシャツをもらえた以外にも、会場での個人スポンサーの特典として前列を優先席として確保してもらっておりました。こちらの席は一定の時間が過ぎたら一般参加者にも開放される運用となっておりました。

「TSKaigi 個人スポンサー優先席」と書かれた幕がかけられた椅子が並んでいる

これまでのTypeScriptの進化を振り返る

キーノートはTypeScriptのプリンシパルプロダクトマネージャーを務めるDaniel Rosenwasser氏による「What's New in TypeScript」でした。

TypeScriptは2012年10月1日に公開されてから今年で12年目を迎えようとしています。GitHubが公開しているレポートの「GitHub Octoverse」の2016年での使用されている言語のランキングでは、JavaScriptと比較して遥かに下位のランクでした。そこから2018年にはトップ10入りして、2023年にはトップ3にランクインするまでに成長してきました。

JavaScriptサーベイでもある「State of JavaScript」のアンケート結果において、JavaScriptとTypeScriptのバランスを見ると、JavaScriptで100%書かれているのが8.2%に対して、TypeScriptで100%書かれているのが20.7%となっています。更にTypeScriptで書かれている率がJavaScriptだけで書かれている率よりも高く、このことより開発者がJavaScriptよりもTypeScriptを使用して時間をかけた開発していることがわかります。

セッションではTypeScript 5.4から導入されたNo Inferと5.5からのInferred Type Predicatesの機能についてをライブコーディングで解説していました。No InferとInferred Type Predicatesについての詳細は以下記事を参照してください。

そのほかJSDoc内でのType Importsが使えるようになる、正規表現チェック、Isolated Declarationsについても紹介されていました。貴重な講演を日本でしていただき、ありがとうございました!

参加したセッションを振り返る

TypeScript ASTを利用したコードジェネレーターの実装入門

openapi-typescript-code-generatorの作者であるHimenonさんによるTypeScript AST(Abstract Syntax Tree = 抽象木構文)が具体的にどのようなことをしているかの紹介と、ASTを活用してコードジェネレーターはどのようにして作られているかを自身の経験を交えて解説していました。

TypeScirpt ASTを確認するにあたり、TypeScript AST Viewerを活用します。たとえば "Hello World" という文字列は「ExpressionStatement > StringLiteral」という式文と文字列という抽象木構文で表されます。

コードジェネレーターではそこから生成されるFactory Codeという生成パターンを活用していきます。しかしFactoryでは利用しないパラメーターも記述する必要があるため、命令が長いものほどどんどん冗長になるためラッパーが欲しくなってくるという事情を抱えています。

以前業務内でとあるTypeScriptコード群を一括で置き換え対応するためにts-morphを活用させてもらうことがありましたが、今回のセッションを拝聴していると、ts-morphがいかに面倒くさいことを隠蔽してくれてるのかを実感することができました。

スライドリンク
TSKaigi 2024 TypeScript ASTを利用したコードジェネレーターの実装入門 | ドクセル

TypeScript関数型バックエンド開発のリアル

株式会社一休の開発ではTypeScriptによるGraphQLバックエンド開発にてドメインレイヤーの実装において関数型プログラミングを採用しているということで、その実装方法についてを紹介してくれました。

バックエンド開発にて関数型プログラミングを導入するにあたり参考にしたものとして「Domain Modeling Made Functional」という書籍があります。この本ではDDDにて関数型をやっていくにあたり、ドメインオブジェクトに型を多くつけていくことを推奨しています。今回の実践においてすべて書籍通りにやるのではなく、I/O層でRepositoryパターンを導入してみたり、関数型はドメインレイヤーのみだけに注力するようにしていました。I/O層とドメインレイヤーを明確に分離関数型を運用していくためにオニオンアーキテクチャを採用することで、関数による純粋な表現ができるようになっているとのことです。

そもそもなぜ関数型を採用したいかについては、1つに型を多く活用していくので静的型付けの恩恵が得られるということ、もう1つにオブジェクトの変更を関数適用による状態遷移にすることで明示的なコードとなり型が記述しやすくなるから、ということが示されていました。

型安全にエラーハンドリングをするために「Railway Oriented Programming」という手法も用いられ、Result型で返ってくる関数にして、一本道の処理フローを作るようにしているそうです。具体的な実装手順については「TypeScript開発にRailway Orientedを持ち込み、より型安全なエラーハンドリングへ - Sansan Tech Blog」が参考になると思います。

スライドリンク
TypeScript 関数型スタイルでバックエンド開発のリアル - Speaker Deck

複雑なビジネスルールに挑む:正確性と効率性を両立するfp-tsのチーム活用術

SaaSエンタープライズ対応において行政や大規模な組織に導入する際に遭遇しがちな「Excelファイル一括入稿」という複雑な仕様と向き合うためにfp-tsを活用している話が紹介されていました。

表形式のデータで、1つの行やセルごとに検査していく中でエラーが発生すると都度その修正が必要となり、どれだけエラーとなるものが入っているかが分かりづらい課題がありました。その課題を解決するために、fp-tsのEither型(Result型)を導入し、エラー合成をするようにしたことでデータ検証時に一度にエラーが返ってくるようになったため顧客への価値提供に寄与しているとのことです。

fp-tsをチーム内で運用していくために、まず関数型プログラミングの知識が必要になること、日本語ドキュメントが実用例が少ないといった問題についても触れられていました。オンボーディングで必要なコンテキストを減らしてモブプログラミングで同期的な作業を経て認知負荷を減らすようにしたり、社内向けのレシピ集やプレイグラウンドを用意するなどの工夫をされているとのことです。

スライドリンク
複雑なビジネスルールに挑む:正確性と効率性を両立するfp-tsのチーム活用術 / Strike a balance between correctness and efficiency with fp-ts - Speaker Deck

tRPCを実務に導入して分かった旨味と苦味

個人的にtRPCについて気になっていたので注目していたセッションです。

tRPCはTypeScriptで型安全にRPCを開発するためのライブラリで、GraphQLと違ってスキーマを定義せずに、クライアントアプリ側からインポートされたAppRouter typeからサーバーへの型導出されるクライアントがサーバーとで依存している仕組みになっています。

ゼストさんでは、サーバーとフロントエンドとでフルスタックなTypeScript開発をしていくために導入されたとのことです。その他モノレポにしてサーバー側からクライアントを参照できるようにしていたり、いくつか工夫をされて運用されていることが紹介されていました。

まだまだ知見が少ないライブラリとのことで研究の余地はありそうなライブラリですが、フルスタックなTypeScript開発における協業のしやすさという点で選択肢に入ってくるものとして感じました。

イベント後に、そういえばtRPCはT3 Stackというフロントエンド開発手法で用いられてる技術スタックだったな、と思い出したりしました。

スライドリンク
tRPCを実務に導入して分かった旨味と苦味 - Speaker Deck

サービス開発におけるVue3とTypeScriptの親和性について

Vue.jsとTypeScript、というとVue2の頃のTypeScriptサポートに苦い思い出があった方がいるかもしれません。私は幸いそうした時期を経ずに今のTypeScriptサポートのある状態からガッツリとVue.jsに携わっていましたが、一定数「Vue.jsとTypeScriptは相性が良くないのでは?」という印象が残っている気がしています。

しかし現在のVue3においてはいくつかのアプローチを経てTypeScriptとの親和性が高まっています。セッションではComposition APIdefineComponent() の登場によりVue.js内部がTypeScriptフレンドリーになってきたこと、Vue Language Serverの発達とIDEサポートの充実が紹介されており、現在どのようなVue.jsとTypeScriptでの開発ができるかなどが紹介されています。

TypeScriptサポートといえばReact.jsの一級市民として扱われていた印象がありますが、現在のVue.jsにおいても同等にTypeScriptフレンドリーな環境が整うようになってきています。あまり良い印象がないと思っている人にこそ改めて読んでもらいたいセッションでした。

スライドリンク
サービス開発におけるVue3とTypeScriptの親和性について - Speaker Deck

TypeScriptとGraphQLで実現する型安全なAPI実装

APIの型をつけたいときの選択肢としてOpenAPIやgRPC、GraphQLが候補としてあげられます。このセッションではGraphQLに焦点を当て、GrapghQL Codegenを活用したクライアントサイドとサーバーサイドの型安全なAPI実装を紹介してくれました。

クライアントサイドでの型を利用するのはスキーマから生成されたものを使うものだと思っていたのですが、クエリで特定のレスポンスを参照しない場合に発行されたすべての型とで一致せず undefined になったりするため、クエリ側から生成する型を使ったほうがいいというのは学びになりました。

Fragmentで定義されたクエリフィールドだけのものを使えるFragment Colocationや、特定のFragment以外で使えないようにするFragment Maskingといった手法があることも知ることができました。

スライドリンク
TypeScriptとGraphQLで実現する 型安全なAPI実装 / TSKaigi 2024 - Speaker Deck

Prettierの未来を考える

PrettierメンテナーでもあるSosuke Suzuki氏による、Prettierのこれまでとこれからのことについての発表もありました。

Prettierは2017年にリリースされて以来、多くの開発者に利用されているコードフォーマッターです。多くの言語で利用できるようになっており、弊社でも活用させてもらっているツールの1つです。7年経った現在、新たなフォーマッターツールとしてBiomeが登場し、Prettierにはない利点をもっているものとしてよく比較されています。

PrettierとBiomeについて最近あった出来事では、Rustを使ってPrettierの95%以上のテストケースをパスした場合、$10,000の賞金が提供されるチャレンジ「The Prettier Challenge」が開催された際に、Biomeプロジェクトが優勝して賞金を獲得していったということがありました。

このセッションではそんなBiomeについてを、アルゴリズム・単一ファイルと複数ファイルでの実行パフォーマンス、インテグレーション、サポートする言語、プラグイン対応、記述されている言語のそれぞれの観点から比較し、Prettierは今後どのような点を改善・注力していくべきなのかが紹介されていました。

Biomeの人気や採用事例も増えてきていますが、Prettierもまだまだフロントエンド開発においてはなくてはならない存在だと思います。今後も双方ともに健全な競合関係として、より良い進化を遂げていってほしいと願っております。

スピーカーノートリンク
TSKaigi 2024 Prettierの未来を考える スピーカーノート

言語化対応におけるTypeScriptの型定義を通して開発のしやすさについて考えた

最後はTypeScriptと多言語化対応にまつわるセッションでした。react-intlというライブラリを活用して多言語化対応をされていたのですが、通常のままだと運用に難があった点を型定義によって解消していったことが紹介されていました。やはり as const satisfies は非常に強力で便利ですね。

スライドリンク
多言語化対応における TypeScript の型定義を通して開発のしやすさについて考えた / TSKaigi TypeScript Multilingualization - Speaker Deck

おわりに

以前、TypeScriptに関する国内コミュニティとしてTypeScript JPが活動をしておりカンファレンスとしてTSConf JP 2020も企画されていたのですが、コロナ禍による影響にて中止になり、昨年をもってコミュニティ自体も解散してしまいました。そんな中、その後継となるような形でTSKaigi 2024で開催されたのは非常に感慨深いものでした。カンファレンス運営に携わっていた皆様、ありがとうございました。

現在、弊社のプロダクト開発においても様々な形でTypeScriptが活用されています。Vue.jsやReact.jsといったUIライブラリ内での開発から、Denoを活用した社内ツールやSlackアプリ開発など、その用途は多岐にわたっています。逆にTypeScriptが使えない状態の開発に戻れるかというと、非常に厳しいくらいに日々の開発生産性に寄与しているものの1つになっています。

今後もTypeScriptを活用した開発をしていくことは間違いありません。TypeScriptのように漸進的に活用していって、TSKaigi 2024で得た知見を業務内で活かしつつ今後の動向についてもウォッチしていこうと思っています。

参加レポートは以上となります。最後までご覧いただきありがとうございました。

© 2016 CrowdWorks, Inc., All rights reserved.