https://ozaki25.hatenadiary.jp/entry/2025/11/24/000011

2025/11/24
https://hokuriku.tskaigi.org/

TypeScript 6.0で非推奨化されるオプションたち

うひょさん
https://speakerdeck.com/uhyo/typescript-6-dot-0defei-tui-jiang-hua-sareruopusiyontati

TS7.0からネイティブ版のtsgoになる
- 今は5.9で次は6.0
  - 6.0はネイティブ版に向けた準備のような位置づけ
- 6.0は2026/1,2くらいで7.0はその1ヶ月後くらい
- 6.0での非推奨項目
  - 7.0では使えなくなるもの
TSのバージョン
- セマンティックバージョニングにのっとってない
  - 4.9の次が5.0だっただけ
- 初期は大きめな特別なリリース扱いしていた
  - 1.8から1.9を飛ばして2.0になってたり
  - 3.0以降は順番に上がってるだけ
- 5.0のdeprecationサイクル
  - 5.0で警告
  - 5.5でエラーにならないが動かなくなる
  - 6.0でエラーになる
- 6.0はdeprecationサイクルが完遂するタイミング
6.0で非推奨化されるもの
- target: es5
  - ES5へのトランスパイル廃止
  - 最小ターゲットはes2015に
  - デフォルト値はリリース時点の最新版
    - tsc --initするとesnextになる
  - es2015すらサポートしてない環境はもうないと言っていい
  - トランスパイルは他のツールを使ってるケースも多い
- outFile
  - outDirではなくoutFileを指定すると1つに統合したjsを出力していた
  - CommonJSやESMに対応してなかった
  - 原始的なバンドルのような動き
- moduleResokution: classic
  - モジュールの解決方式
  - CommonJSよりも古いやつでNodeですらない？やつが使えなくなる
- alwaysStrict: false
  - use strict と書かなくても常にstrict modeで扱うオプション
  - 実質strict modeで今は書かれてるから
- module構文
  - namespaceより昔のmodile構文が廃止
  - 一部使えるパターンも残る
  - JS側でmoduleが入る動きがあるのでts側にあると邪魔という背景も
- import ... asserts
  - assertsじゃなくてwithが今の書き方
    - 当初assertsでwithに仕様変更された名残
  - chromeやNodeはもうasserts消してwithに移ってる
6.0で挙動が変わるもの
- typesのデフォルト
  - どの @types パッケージを読み込むかのオプション
    - グローバル変数に対応する型の話
  - デフォルトでは何も読み込まなくなる
- rootDirのデフォルト値
  - outDirがどこからの相対パスになるか
  - thconfig.jsonがあるディレクトリになる
- tscにファイル名を渡した時の挙動
  - 従来はtsconfig.jsonを無視する
  - 今後はtsconfig.jsonがあったらエラーが発生
    - 使わないときはignoreのオプションをつける
    - 使うときは指定する
- enum merging
  - 同じファイルで同じ名前のenumを宣言するとマージされてた
  - あまり使われないので廃止される
- 複数namespace間での変数参照
  - 変数参照する時の挙動が変わる
まとめ
- 以下のような理由で古いものが整理されることになる
  - 不要な実装の削減
  - パフォーマンスの最適化
- 2026/1か2に6.0が来るので準備は必要
  - その後の7.0を使いたいならなおさら
- ただし普段の開発にインパクトが大きいものはそんなにない

Fullstack TSでマルチプロダクトの基盤開発

鈴木翔大さん(MOSH)
https://speakerdeck.com/soarteclab/tskaigi-hokuriku-2025

フルサイクル開発
- ドメイン理解への集中
- 開発運用を降るサイクルで
- やるべきことが増えてスピードに影響が
マルチプロダクト
- 複数チームで機能の重複
- 振る舞いの違い
TSで共通基盤の開発
- 決済/通知/メッセージ管理/アカウント管理など
- 一貫したユーザ体験
- 技術的複雑性のカプセル化
スキーマ駆動開発
- 各基盤でOpenAPIの定義
- clientとserverのソースコードを自動生成
  - 呼ぶ側と呼ばれる側を同時に変更させることで整合性を保つ

denoとtypescriptの関係について改めて考えてみる

比嘉一晃さん

Deno
- JavaScript Runtime
- Nodeの作者が反省点を踏まえて作ったもの
  - JS Conf EU 2018で発表
- TSをゼロコンフィグでサポート
- npmとnodeもサポート
- Web標準APIもサポート
  - fetchなど
- deno lint
- deno fmt
- deno test
- ファイル実行時にセキュリティチェックが走る
  - 実行していいかプロンプトで問い合わせが来る
  - ネットワークアクセス
  - ファイルへのアクセス
  - など
動かしてみる例
- deno init
  - templateを指定することができる
  - react-tsとかある
- CLIアプリ
  - CLIから実行できるスクリプトを作るのにも便利

TypeScript×CASLでつくるSaaSの認可

坂津潤平さん
芹澤和也さん
https://speakerdeck.com/saka2jp/authz-with-casl

各レイヤーでの認可ロジック
- UI: 権限のないボタンを表示しない
- API: 不正な操作をガードする
- DB: 他社のデータを取得しない
認可モデル
- RBAC
  - ロールベースアクセスコントロール
  - 役割に権限が紐づく
  - 複雑になるとこれでは足りなくなり
- ABAC
  - 属性ベースアクセスコントロール
  - ユーザ属性とアクセス対象のレベルを比較して判断
- PBAC
  - ポリシーベースアクセスコントロール
  - 細かいロジックを含めた判定ができる
- ReBAC
  - 関係性ベースアクセスコントロール
  - GoogleDriveのような権限管理
AI面接サービス
- テナント管理者はテナントの設定変更ができる
  - RBAC
- 評価担当者は自部署の応募者のみ閲覧化
  - ABAC
認可サービス
- Auth0 FGA
  - Oktaの一部
  - Google Zanzibarに基づく
- Oso Cloud
  - 独自ポリシー言語Polarを使う
  - BtoBでよく使われる
- Permit.io
  - ローコードでの権限管理
  - UIベース
SaaSの懸念
- 従量課金
- レイテンシ
  - セルフホストの選択もあるが
CASL
- OSSの認可サービス
- Isomorphic
  - 定義したポリシーをフロントエンド/バックエンドで再利用化
- Ability
  - 誰が何をどうするという認可のルールを詰め込むオブジェクト
  - Prismaの型をすのままSubjectとして使える
- NestJSだとデコレーターで実装できる
  - コントローラーに到達する前にはじく
  - フィールドレベルの認可もできる
- Canコンポーネントを作って出し分けたい要素を囲う
  - 権限がある場合だけ表示されたり制御してくれる

同期APIの壁を越える：TypeScriptで設計する、堅牢さとUXを両立した非同期ワークフローの実現

moekaさん(アセンド)
https://speakerdeck.com/moeka__c/typescriptdeshe-ji-suru-jian-lao-satouxwoliang-li-sitafei-tong-qi-wakuhuronoshi-xian

オールインワンSaaS
- テナントやドメインをまたいだ処理
- 即時性が求められるとバッチ処理などでまとめて処理できない
  - 同期的に即時に連携して処理しないといけない
  - 整合性担保のために1トランザクションで処理したり
  - モジュラーモノリス
同期APIの壁
- 整合性要件の高さ
- ピーク時の大量処理
- 整合性/堅牢性と拡張性を両立したアーキテクチャへ
非同期データ連携
- イベントソーシング + イベントドリブン
- ワークフロー
  - Sagaパターン
    - ローカルトランザクションの連続として扱う
    - 途中で失敗したら打ち消す処理を逆方向に投げていく
  - コレオグラフィ方式
    - 各サービスがlistenして取得していく
    - シンプルな連携
    - 補償が大変
  - オーケストレーション方式
    - 中央で管理
    - 状態管理が複雑
- イベントの発行
  - DBトランザクションとイベント送信
    - どちらか一方が失敗した時どうするか
  - Outboxパターン
    - 少なくとも1回送ることを保証する方式
- イベントの受け取り
  - 重複配信された場合の考慮
  - アプリ側で冪等性を担保
TypeScriptでの実装
- 技術的な複雑性がとても多い
  - どこまで整合性を担保するかは事業要件とあわせて判断していくことになる
- フローの全体像を型で表現
  - 型付きステートマシンとイベントでモデル化
  - 実装を見なくても型を見るとフローが分かる
  - 早期に考慮漏れを検知できることにもなる
- EventSourcingとOutboxを型で強制
  - eventのapplyやsaveを実装で縛る
    - 不整合な呼び出しがコンパイルエラーになるように
- サービス重複呼び出し防止
  - フローの状態管理テーブル
  - idとstatusでロックして重複を防ぐ
  - ロック済みであることを保証する型

レガシーシステム刷新におけるTypeSpecスキーマ駆動開発のすゝめ

karacoroさん(LIXIL)
https://speakerdeck.com/tsukuha/regasisisutemushua-xin-niokeru-typespec-sukimaqu-dong-kai-fa-nosu-me

レガシーシステムの技術的な観点
- 技術の老朽化
- システムの肥大化複雑化
- システムのブラックボックス化
システム刷新時の考慮ポイント
- デグレがないか
  - 刷新前後で動作が変わらないように
- マイグレーション後の動作保証
  - 各種テストを行って動作の担保が必要
- 技術のモダナイズ
  - 技術刷新を合わせて行うことも
スキーマ駆動開発
- フロントエンドとバックエンドを分離し段階的にやることが多い
- バックエンドのデータ構造は変更しづらいのでフロントエンドが先行しがち
- API仕様書がない場合に適用しやすい
OpenAPIとTypeSpec
- OpenAPI
  - API仕様のフォーマット
- TypeSpec
  - API定義用のプログラミング言語
    - .tsp
  - OpenAPIのフォーマットにコンパイルできる
  - OpenAPIの内容を構造的に管理できる
- TypeSpec -> OpenAPI -> 仕様書やコードなど
開発の進め方
- モノレポで
- typespec配下で定義を管理
  - 新旧並行稼働があるならnewとlegacyを分けておくといい
  - 移行中に旧に手が入っても対応しやすい
- frontend配下でフロントエンドの実装を管理
- 出力した型定義をfrontend配下に配置する
  - 問題があればエラーになるので変更の影響分かりやすい
- Orvalを使ってzodのスキーマも自動生成できる
- Contruct Testing

型情報を手繰り寄せる技術〜TypeScript Compiler APIによる型解析実践〜

jiko21さん

型からHTMLを作りたい
- タグの親子関係のルールなどを型で縛る
TypeScript Compiler API
- AST化して解析ができる
- TS AST Viewerが便利
  - https://ts-ast-viewer.com/

Building AI Agents with TypeScript

izumin5210さん(LayerX)
https://speakerdeck.com/izumin5210/building-ai-agents-with-typescript

AI機能の開発の変化
- APIベースになった
- モデルを自前で構築しなくて良くなった
- SDKが充実してきた
TypeScriptのAIエージェント
- vercel/aiを使ったサンプル
  - どのモデルでも同じAPIで使えるようにしたライブラリ
  - 薄いのがいい
- toolを渡すといい感じに使ってくれる
  - aiSDKを使うと簡単に作れる
- useChatでメッセージを管理できる
  - AIからのレスポンスの内容を型安全に扱うことができる
  - jsonなので永続化すると履歴を残せる
- ワークフロー
  - 決まった流れがある時に定義しておける
  - Deep Researchもワークフロー
  - 小さく分けることでコンテキストを小さくできる
  - LLMにやらせる必要がない決定論的なものは別で処理できる
- Durable
  - 途中で中断しても最後まで実行できるように
  - Resumableであるように
  - vercel/workflow

`tsc --init` の設計思想の変化とその背景を追う - “教育的”アプローチから実用性重視への転換

大塚竜太郎さん(チームラボ)

ts5.9から tsc --init の内容が変わった
- 全てのオプションとコメントが出力されていた
- かなりミニマルになった
変えた理由
- ESMを推進しているのでcommonjsベースをやめた
- コメントが大量なのが威圧的とフィードバックが
- ほとんどすぐに削除されていると分かった
変更点
- typesでグローバル型を明示的に管理
  - 意図しないグローバル型の混入を防ぐ
- noUncheckedIndexedAccessとexactOptionalProperty...
  - 後から有効化するのは大変なので最初は有効化がいい
- verbatimModuleSyntaxとisolatedModules
  - ベストプラクティスに寄るように
- moduleDetection: forceを明示
  - import/exportがないファイルも常にモジュールとして扱うように
  - グローバルを汚染させない

TypeScript ASTを活用した意味差分抽出の紹介

武井勇也さん
https://speakerdeck.com/takewell/introduction-to-design-difference-extraction-using-typescript-asta

AIコーディングでレビューが大変
- AIでレビューさせてもいいけど自分で理解したい
- 構造が複雑だとレビューが大変
- レイヤーが多い
- 多くの依存が絡む
- 全体の構造と変更の有無が図示されると嬉しい
依存関係の図示
- ts-morphでASTを解析
- diffと解析結果を合わせてmermaid化