TSKaigi 2026
「関数型プログラミング」を分解する.ts
あとでちゃんと見る
制約を設けること
同一性、普遍性、純粋性
純粋関数
継続
PromiseのthenやreadFileのコールバックAPI
結果を関数として渡す→継続渡しスタイル（CPS）
RustのOptionも似てる
失敗しうるとか非同期処理とかを逐次で繋げるのをモナドという
厳密にはPromiseとかは違う
TypeScriptのclassはなぜこうなったのか — 歴史・落とし穴・そして使いどころを探る
後で見る
Stage 3 Decorators でできること / できないこと
デコレータとは
classの機能を拡張・メタデータを付与する機能
実態は関数
関数に対する高階関数的な
ユースケース
ログ・トレース
対象のメソッドに対してつけて、呼び出されたときにログ出力など
DI
Angularなど
ORM・(de)serialization
ルーティング定義
Observable
MobXはStage 3 Decoratorsに移行を完了した
Stage 3 Decorators
tsの--experimentailDecoratorsのECMA Scriptでの標準サポート
Decorators
--experimentailDecoratorsに対応
auto-accessors
getter, setterを定義するんじゃなくて楽にフィールドを設定できるやつ
Decorator Metadata
reflect-metadataパッケージに対応
自由度は下がった
引数デコレータの未サポート
Stage1で、進むか微妙
--emitDecoratorMetadata非対応
型の話なので非対応
現時点ではまだ厳しい。Test262が未完成
OxcがTest262待ちで、他のトランスパイラは実装済み。エンジンは未実装
Oxlint は ESLint / typescript-eslint を置き換えられるか？
tsgolintに未実装ルールが2つ残っている
Oxlintはいかにしてtsgolintのlint ruleを呼び出しているのか
tsgolintにルール追加するだけでなくて、Oxlint側も修正する必要があるらしい
AIのために、AIを使った、Effect-TSからの脱却 〜テストを活用した安全なリファクタリングの進め方〜
Effect-TS
遅延評価
依存を明示
.pipe: パイプラインオペレーター的な
Functional Core, Imperasive Shell
懸念・課題
依存が大きくなってしまう
→Effect-TSを使っていいディレクトリを制限
学習コスト
同じ目的に対して複数のやり方があって、統一できない
脱却
『レガシーコード改善ガイド』
テストを先に書く
Effect依存なのでやりづらい
→中身はEffect、I/FはResultの型を作る
ResultのI/Fでテストを書く
Real World Effect-TS: 堅牢なプロダクトを型で組み上げる
『関数型ドメインモデリング』
Effect-TS
generator関数を使う
Railway Oriented Programming
成功と失敗の分岐のRailway
成功したら続けるけど、失敗したら失敗のレールのまま最後まで行く
yeildしたエラーを、Effect.genが合成してくれる
Effect.die
DI
依存のバケツリレーが発生しうる
→DIコンテナ
Node.js+TypeScriptにおけるCJS/ESM相互運用の最新ポイント
ライブラリがESM-onlyだと、dynamic importがしんどい
require(esm)
top level awaitがなければrequireでもいける的な発想
dual-package hazard
パッケージ作るときに注意
module-syncで解決
enum よ、さようなら
JSになったときにでかくなる
IIFEなのでtree shakingも効かない
TypeScript Design Goals
3と9に違反
また、11によって後方互換性を保証するため、消すわけにもいかない
標準化の壁
Type Annotations (Stage 1)
ECMAScript enums (Stage 1)
Node.jsのType Stripping
相性が悪い
いつテストを書くか？―ソフトウェア開発における安心と不安について考える
ガードレール
保守性の本質は変更容易性である
「ソフトウェア」: 簡単に変更できる
変更できないと、「死んだ」プログラム by Naur
変更容易性は人間とソフトウェアの関係である
「人間が」変更が簡単かどうか
変更容易性
予期的変更容易性
変更を行う前に抱く「変更のしやすさ」の感覚
開発者のスキルなどによって変わる
変更の機会を増やす
経験的変更容易性
変更を行う中で経験する「変更のしやすさ」の感覚
変更の合理性を高める
コスパを高くする
この2つを両立したい
開放閉鎖原則
修正に対して閉じている
利用されているモジュールの振る舞いを変えてはいけない
拡張に対して開いている
モジュールには新しい振る舞いを追加できなければならない
この2つを両立したい
ソフトウェアアーキテクチャとは、開放閉鎖原則の達成を目指すもの
テストは開発者の不安を取り除く
どれだけ閉じているかどうかを示すもの
→予期的変更容易性へのフィードバック
ラチェットの歯車
テストは開発者に構造上の問題を教える
テストの追加は開放と閉鎖の試金石
→経験的変更容易性へのフィードバック
炭鉱のカナリア
テスト駆動開発→開放閉鎖原則を徐々に満たす
実装・学習・設計のループ
テストを通すための実装を通じて構造上の問題を学習し、徐々に開放閉鎖原則を満たしながら実装が進んでいく
TDDの狙いは仕様を満たすだけでなく、次の変更に備えるためのリファクタなどを行うこと
よって、先に全部テストケースを書くのではなく、1つ実装するごとに書くループを回す
「変更は暗黙の複雑性を明示的にする」
テストをいつ書くか
変更が怖いなら書く
予期的変更容易性を高める
書いても不安が減らないなら書く意味がない
構造上の問題を学習するために書く
経験的変更容易性を試す
テストの目的とテストピラミッド
e2e/UIテスト（高結合）: 不安の解消
ユニットテスト（低結合）: 構造フィードバック
次世代リンターで探る、tsgo 時代における型認識カスタムルールの現実解
OxlintとRslint
ルール数はOxlintは59件、Rslintは129件
元ルールが61件だったような？
Rslintはカスタムルール未対応で、検討中
→型認識カスタムルールを作ってみたらしい
ASTに落とし込んで型認識をしなくてもlint or typecheckできるようなAPI設計にする案もある
ファイル名で表現して、import文を確認するとか
programmatic API
Oxlint: wasmプラグイン
うぶげさんのcorsa-bind