Content Mapper APIの応用例～CSS Modules、言語ファイル～

2026-11-01 TSKaigi Sendai 2026

Transcript

1. Content Mapper APIの応用例 ～CSS Modules、言語ファイル～ 2026-11-01 TSKaigi Sendai 2026
2. 発表者紹介 uhyo 株式会社カオナビ フロントエンドエキスパート TypeScriptとReactにとても詳しい。 宣伝 → 2
3. TypeScript 7.1 今月リリース予定！ （順調にいけば11月24日） APIやアンビエントモジュール宣言における Import Attributesのサポートなども気になるが、 7.1 Betaのリリース以降、Content Mapper API に注目が集まっている。 3
4. Content Mapper API 任意の拡張子のファイルを、TypeScriptファイル のように扱うことができる夢のような機能。 4
5. Content Mapperでできること 5
6. 従来方式との比較 6
7. Content Mapperの通信内容 7
8. マッピングの例 8
9. マッピングの活用 型エラーの表示や各種エディタ機能に。 9
10. Content Mapperまとめ 任意のファイルに変換をかませてTypeScript プロジェクトに組み込むことができる。 マッピングを通じて各種エディタ機能も使用可。 （Go to Definitionなど） 10
11. 応用例① CSS Modules 11
12. CSS Modulesとは フロントエンドアプリ向けにCSSを書く方法の ひとつ。 ViteやNext.jsなどに初期設定で組み込まれており、 デファクトスタンダードな方法。 生のCSS構文を使える点がメリット。 12
13. CSS Modulesとは 13
14. CSS Modulesの型サポート: 従来手法 事前に型定義を生成する。 14
15. CSS Modulesの型サポート: 従来手法 型定義だけだと足りない開発体験を Language Service Pluginで補う。 例: css-modules-kit https://github.com/mizdra/css-modules-kit 15
16. 従来方式との比較（再掲） 16
17. Content MapperによるCSS Modulesサポート 事前のファイル生成が不要に。 TypeScript組み込みのエディタ機能も利用可能。 17
18. Content MapperによるCSS Modulesサポート 先ほど紹介したcss-modules-kitが Content Mapperサポートを追加するようなので 応援しよう！ （みんなContent Mapperの応用でCSS Modulesを思いつく から多分既に10個くらい類似OSSが公開されている） 18
19. 応用例② 言語ファイル 19
20. 言語ファイル カオナビでは、最近言語ファイルの新しい仕組み を導入した。 言語ファイル: 多言語をサポートするアプリで、言語ごとに 異なる文言を定義するファイル。 20
21. 言語ファイルの使いかた Viteプラグインで*.lang.jsoncファイルがフックを エクスポートするように変換。 21
22. 言語ファイルシステムの特徴 コロケーション: 細かな粒度の言語ファイルを 使うコードの近くに配置する。既存の設計技術を 文言管理にも持ち込む。 翻訳に有利: 文脈を参照でき、適切な翻訳をしや すい。全言語が同じファイルにあり、翻訳し忘れ が起きない。 22
23. 言語ファイルシステムの裏側 言語ファイルごとに別の名前空間として i18nextに文言を登録している。 1つのJSONが各言語ごとに別々のバーチャル モジュールに分割され、ランタイムでは必要な 言語のみ読み込まれる。 23
24. 言語ファイルにContent Mapperを適用 ※ 単純化した生成例です。 24
25. Content Mapperの恩恵 keyを間違っ たら型エラー になる。 従来手法より 圧倒的に簡単。 25
26. 応用例: 言語ファイル自体のチェック 26
27. 注意 場合によっては、TypeScriptにチェックさせる より別のlinterでチェックしたほうが効率がいい。 型情報が必要なチェックや、.vueなどTypeScript コードを含む特殊ファイルのチェックに適してい る。 （一応任意のdiagnosticsをTSに送れる機能もある） 27
28. おまけ: nitrogql v2.1 28
29. おまけ: nitrogql v2.1 ずっと「.nitrogqlファイルを直接インポートする」 設計を提唱してきたが、Contenet Mapperにより ついに主流の方法に返り咲く！（かも） 29
30. Content Mapper時代の フレームワーク論 30
31. Content Mapperがもたらす変化 独自のファイル形式をプロジェクトに組み込みや すくなった。 31
32. オレオレファイル形式の時代へ ViteプラグインとContent Mapperの両輪で、 独自形式の実装がこれまで以上に簡単になり、 優れた開発者体験を実現しやすくなった。 • 事前の型定義生成など面倒なステップが無い • エディタ機能や型システムの統合までTSが 担ってくれる 32
33. 言語ファイルシステムの狙い AIが開発する時代に適合する独自方式。 • 細かく分割してコンテキスト管理 • コロケーションで発見性向上 • 全言語をコンテキストに投入することで、 文言修正時の翻訳更新漏れを防ぐ 33
34. 独自方式のすすめ 独自方式の実装は簡単になり、メンテナンスも AIで容易にできるようになった。 少し独自実装するくらいは、今の時代、 もはやオーバーエンジニアリングではない。 プロジェクトに合わせてカスタマイズすることの 合理性がとても増した。 34
35. まとめ Content Mapper APIにより、型や開発者体験を 良好に保ったままTS以外のファイル形式を プロジェクトに組み込めるようになった。 自分たちに合った仕組みを作り込もう。 35
36. おまけ: Content Mapper以外のAPI 7.1で一部のAPIが安定化予定。 型情報やASTを取得できるJS版に近いAPIが 利用可能になる。 36