色々セッションを聴いてきたので、その感想です。沢山ありすぎたので、聴いてて気になったものだけ感想書いてます。
The New Powerful ESLint Config with Type Safety
https://talks.antfu.me/2025/tskaigi/1
ESLint の Flat Config についてのセッション。新 config への移行を補助するツール (@eslint/migrate-config, Config Inspector) が色々紹介されていた。存在そのものは知っていたけど、実際どういうことができるのかとか、動いている様子とかは見たことがなかったので、そういうのがセッションで見れて良かった。
@eslint/migrate-config はまあ良さそうだけど、Config Inspector はそんなに必要な状況あるかなあとは思った。そもそもそれが必要になるほど config のデバッグに苦労する状況が良くないと思う。複雑な config は避けて、シンプルで挙動が予測しやすいものをまず志向すべきだと思う。まあでも本当にどうしようもなく難しい config を作ってしまった時に、デバッグするのには便利そう。
config の合成を補助する eslint-flat-config-utils というのも紹介されてたけど、これも本当に必要かな?と思った。config の合成が簡単にできるのは良いけど、ESLint の標準とは異なる方法で合成するから、その合成のルールを学ばないといけないと思う。新しいこと覚えるの手間なので、ESLint の標準的な方法で合成するので十分じゃないかと思う。
あと plugin で追加された rule の名前を rules の補完候補として出す「eslint-typegen」は面白かった！僕も補完できるようにしたいなとずっと思ってた。eslint 実行時に plugin が動的に型定義ファイルを生成して、その型定義を元に rules の補完ができるようにする、というのがだいぶカッコ良い。動的に型定義を生成する仕組み、だいぶハックっぽいのでもうちょっと単純な仕組みになって、かつ ESLint 側に組み込まれたらより良いかなと思った。
SignalとObservable―新たなデータモデルを解きほぐす
https://blog.lacolaco.net/posts/tskaigi-2025-slide/
Angular/Vue.js/SolidJS/Preact など現代的な View フレームワークに実装されている Singals は、実は昔から似たようなものがあるんですよ、という話がされていて良かった。現代的な View フレームワークから入った人の多くは知らないだろうから、そういう人に見てもらう資料として良いなと思った。
後半は Observable の解説があって、実は DOM API に追加されようとしてるんです、という話があってへーとなってた。あんまりこの辺の動向追ってなかったので、色々知れて良かった。
Language Serverと喋ろう
https://speakerdeck.com/pizzacat83/language-server-todie-rou-tskaigi-2025
エディタの Show Call Hierarchy 的なことをやって、ある処理が呼び出される経路を一覧するツールを作る、という話。TypeScript なら ts-morph 使えばシュッと実装できるけど、そうではなくて、どのような言語でも動くようにしたい。そのために Language Server Protocol を使う、という発想がすごく面白かった。
エディタの中で動くツールならまだしも、それ以外のツール (CLI ツールとか) で Language Server を使う事例は殆ど聞いたことないので、こういう使い方もできるんだなと思った。真面目な話をすると、自作ツールから Language Server を起動することで発生する面倒事も色々ありそうだなと思った。エディタは Language Server を起動するための推奨オプションを知ってるけど、自作ツールは知らない訳で、エディタの設定を見ながらオプションをハードコードすることになるはず。
AI Coding Agent Enablement in TypeScript
https://speakerdeck.com/yukukotani/ai-coding-agents-enablement-in-typescript
型チェックや Linter を駆使して、AI Coding Agent が脱線せずコーディングできるようにしましょう、という話。Linter が効くという話はよく効くけど、このトークでは実践的な話が色々なされていて面白かった。AI を激詰めしてから lint rule 作ってとお願いするのは今日からすぐ使えるテクニックだなと思った。
TypeScriptとReactで、WAI-ARIAの属性を正しく利用する
DAY1 で一番面白かったセッションだった。TypeScript コンパイラ側の仕様で、WAI-ARIA 属性の型チェックが緩くなる問題があり、それを解決するために色々なテクニックやツールを駆使する、という話だった。
問題の回避の方法が結構巧妙で、聞いていてなるほどと思った。良さそうと思いつつ、コードの書き方を変える必要があるから (親から受け取った props を aria-attribute-types で変換する) 、中々導入しづらい気はする。しかし他に良い方法もなさそうだし...うーん...と考えさせられるセッションだった。
コードの書き方はそのままで、問題を回避する方法があれば良いんですけどねえ。Linter や TypeScript Language Service Plugin 使ったら何とかならないかなあ。...と考えて色々 X にポストを投稿してた。けどやっぱり良い方法思いつかない！
React.createElement(...) の形式で型チェックが上手くいくのであれば、https://t.co/ulvDtjc454 と同じアプローチで TypeScript Language Service Plugin と Volar.js を使って JSX 部分を React.createElement(...)…
— mizdra (@mizdra) 2025年5月27日
Rust製JavaScript/TypeScript Linterにおけるプラグイン実装の裏側
https://speakerdeck.com/unvalley/typescript-linters
Rust 製の Linter で、Plugin を JavaScriptで書こうとすると、Rust => JavaScript に AST を転送する際に高コストなデシリアライズが必要になり、遅くなってしまう問題がある。それをどう解決するか、という話だった。この発表で紹介された話は https://marvinh.dev/blog/speeding-up-javascript-ecosystem-part-11/ で解説されてて、僕はそれを読んだことがあったので、ふんふんと頷きながら聴いていた。
AST を json-like な object にして、それを JSON としてデシリアライズすると高コストになってしまう。だから AST を1次元の数値の配列に何とかして変換して、それを送る。1次元の数値の配列なら、低コストで転送でき、遅延デシリアライズと組み合わせると、問題が解決する、というのがこのセッションの面白ポイントだった。AST の一部をどんどん簡略化していって、最終的に1次元の数値の配列になるというのがわかりやすく解説されてて良かった (まあ扱う問題が中々難しいので、なんとなくの理解に留まっている方も結構居そう)。
常にこういうアプローチを取れる訳ではなくて、lint rule は多くの場合 AST の全ての Node を走査することがない。rule の実装に必要な最小限の Node だけ走査されるので、その Node だけ遅延デシリアライズしたら良い。そういう lint rule 特有の実行特性があるからこのアプローチが取れる。AST の全 Node を走査する必要がある JavaScript Plugin システムでは、同様のアプローチを採用しても、パフォーマンス向上に寄与しない...という理解を僕はしている。それがこのアプローチの面白い点だと思っていて、折角なのでそういう話もセッションでされると良かったなーと思った。
TypeScriptネイティブ移植観察レポート TSKaigi 2025
https://speakerdeck.com/berlysia/typescript-native-porting-observation-tskaigi-2025
tsgo がどのようなもので、どういう戦略で開発されてるか、今どういう開発状況なのかがまとまってて良かった。P42 のまとめスライドが良いことばかり書いてあって良かった。『「本家本元がやる」だけでは埋まらない不安が「ちゃんと動いていて本当に速い」で吹き飛ぶ』というのは本当にそう思う。
TypeScript Language Service Plugin で CSS Modules の開発体験を改善する
聴いたというよりは発表しました。
技術書をソフトウェア開発する - jsprimerの10年から学ぶ継続的メンテナンスの技術
https://azu.github.io/slide/2025/tskaigi/jsprimer.html
JavaScript の仕様が変化していく中で技術書側をそれに追従させる工夫が、様々な観点で紹介されていて面白かった。単に丁寧にやっていくという話ではなくて、ツールを作って導入したり、章の流れを可視化して章の順序を決めるのに役立てたりなど、普通の書籍の執筆では見れれないような工夫が紹介されてたのが印象的だった。本当にソフトウェアを開発するかのように技術書の執筆をしていてすごい。
君だけのオリジナル async / await を作ろう
https://speakerdeck.com/susisu/tskaigi-2025
同僚の発表ということで聴いた。ジェネレータを使えば async/await っぽいことができる、というのは知っていたけど、実際どうそれを作るのかは知らなかったので、へーと言いながら聴いていた。意外とこれくらい単純なコードで実装できるんだなー。題材が難しかったけど、資料が分かりやすかったのですんなり頭に入ってきてよかった。
TS特化Clineプログラミング
https://tskaigi.mizchi.workers.dev/
AI Coding Agent 向けの実践的なテクニック集という感じだった。途中で TDD が大事という話があったけど、説明の根拠を聞く限りは TDD が大事というよりテストがあることが大事というふうにも理解できて、どうなんでしょうねと思った。TDD じゃなくてもテストがあれば、Agent が生成するコードの質そんな変わらないんじゃないのかな。
In Source Testing で、テストと実装を同じファイルに書くことで、Agent がテストコードと実装を一度に読み取れて扱いやすい、というのは確かになと思った。In Source Testing、流行ってるけどどうなんでしょうね。テスト向けのコードが production コードに bundle されてしまう恐れとかはないのかな。bundler が production ビルドする時に、テスト向けのコードをちゃんと dead code elimination なり tree shaking なりしてくれれば良いけど、どこまでやってくれるんでしょうね。エッジケースが怖くて僕はまだ In Source Testing 使えてない... まあでもどこかで試してみると良い気がする。
令和最新版TypeScriptでのnpmパッケージ開発
https://speakerdeck.com/lycorptech_jp/tskaigi-2025-odan
色々ビルドツールがあるけど、どういう時何使えば良いの? という疑問に答えてくれる発表だった。あと過剰に package 分割すべきではないよねという話がなされていて、うんうんと頷いてた。
最近 monorepo がトレンドになって、どんどんパッケージ分割するのが良い、みたいな風潮があるけど、そんな訳ないと思う。例えば関数1つごとにパッケージ1つ作ったら良いかというと、そんなわけがない。dependencies が増えてきたら分けるという人も居るけど、本来1つの package に収まっていて綺麗に書けていたものを、どうにかして分割すると、無理が出てくると思う。package を分けて運用するコストは無料じゃない。僕は運用したことないけど、マイクロサービスとかとも無理に分けまくって困るというのはよく聞く話で、それと似た話題だと思う。開発チームが違うとか、デプロイの単位が違うとか、責務が違うとか、そういう意味のある単位で分けて欲しい。分けるべき時が来たら分けたら良い。それまでは分けずに粘るべき。...という話を Ask the Speaker で話して盛り上がってた。
Project Referencesを活用した実行環境ごとのtsconfig最適化
Project References...というかSolution Style tsconfig を利用した、tsconfig.json の分割方法についての発表だった。簡潔にまとまってて、他の人にオススメしやすい資料だった。
types: [] を付けると、@types ディレクトリ配下の型定義ファイル全て (@types/node 以外のものも) 読み込めなくなる気がするけど、大丈夫なのかな、トラブル起きないのかなと思ったけど、どうなんでしょうね。今まで自動で読み込まれていたはずの型定義を、明示的に指定して手動で読み込む必要があるので、そこがユーザ的には混乱しそう。
少し話が変わるけど、最近 tsc --init で生成されるデフォルトの tsconfig.json を更新しようという動きがある。
実はこの議論の中で、tsc --init で生成される設定に types: [] を追加しようと提案されてる。そして自動で型定義読み込まないことで混乱が起きるんじゃないか、とちゃんとユーザから突っ込まれてた。それに対しメンテナーの方は、理解を示しつつも自動で型定義読み込むほうが厄介な問題引き起こしてるので、自動を読み込み禁止したい、とりあえず試して様子を見たい、と言っているようだった。
tsconfig.json 周りはまだしばらく大きな変化がありそうだなと思った。
総括
型の話ばっかりという感じではなくて、色々な方面の話が聞けたので面白かった。一方でレベル感的にはちょっと物足りなさも少し感じた。もうちょっと難しい話があっても良かったかも? どうかな? 折角 3 トラックあるので、難しい話が多少あっても、上手い具合に人が分かれてくれる気はする。まあでも人によって聞きたいレベルの感覚違うし、今ぐらいが丁度良いのかなー。
あと TypeScript ではないけど Flow の話とかしたら絶対盛り上がるなと思った。興味ある方よろしくお願いします。
誰か Flow をテーマに話してくれたらいいのにね、と #tskaigi 2次会で話してた。最近面白い新機能実装されてたりするし、絶対盛り上がると思う。
— mizdra (@mizdra) 2025年5月25日
