https://ozaki25.hatenadiary.jp/entry/2025/05/23/183328

The New Powerful ESLint Config with Type Safety

Kaoruさん(AVITA)

クリーンアーキテクチャ
- 方針と詳細を分けて安定度の高い方に依存するルール
- 方針はビジネスルールとビジネスロジック
- 詳細はプラグインのように差し替えられるもの
  - 決定を遅延できる
同心円の図だけを見ている人が多い
- クリーンアーキテクチャの本をちゃんと読むといい
プログラムの構成
- 順次/選択/反復/間接参照
- 手続き型/オブジェクト指向型/関数型
実現方法
- SOLID原則
- DIP
  - 依存関係逆転の原則
  - 呼び出しの流れと依存の流れが一緒じゃなくなる
  - DB周りとかUI周りを差し替えられるようになる
例
- ドメイン層
  - ビジネスルール
- ユースケース層
  - アプリケーション固有の機能
- ゲートウェイ層
  - 外部システムとやり取りする
- 入出力層
  - UI

デザインシステム
- ルールセット + ドキュメント + 実装
- 制約を整えて再現可能にする
- デザイン原則 - ボイス/トーン - スタイルガイド - コンポーネント/デザイントークン
ルールは守られない
- 善意に頼らない
- 逸脱を検知できるように
- ドキュメントを更新し続ける
TypsScriptの型定義で強固にする
- コンポーネントの自由度コントロール
- 補完
- コンパイルエラー
- LLMサポート
型付け
- StyleDictionaryでトークンを出力
- BrandedTypesで同じnumberでも用途ごとに型付けしたり
styleの上書き
- 基本的に許容したくない
- classNameは受け取らない
- 必要ならmarginとかwidthとか個別に受け取る
- jsxでCSS変数に代入しCSSファイルでは変数を使うようにしておく
JSDocに説明を書く
- JSDocのドキュメントをしっかり書くことでエディタ上で情報を知らせることができる
- deprecatedが分かったり
ドキュメント
- コンポーネントとJSDocを生成AIに渡して書いてもらうとか

AIコーディング
- できるだけ自走してほしい
- 人が介入するサイクルを長くしたい
デフォルトだと解空間が広すぎる
- 可能な限り制約を与えて答えの範囲を狭める
- コンテキストの注入
- 機械的な検査によるフィードバック
型チェック
- 型をつけてるからといって精度が上がるわけではないという研究結果
- anyをつけてるとノイズになって下がる
- 型を書かせようとするとanyとか適当に逃げるコードを出される
- そこをうまくやる仕組みも研究されている
Linter
- 従来通りの静的チェックは今も有効
  - コードを生成しながらのチェックは遅くなってしまう
  - 生成AIのチェック判断は本当に正しいかはわからない
- Lintのルールも指摘して書かせる
  - 次ミスらないようにルールを書きなさいと
デザインシステム
- デザインシステムのMCP化
- htmltとCSSの制約
- TSのコードも使用例のドキュメントとして役立つ
複雑な型エラーからは次のアクションが分かりづらい
- コード生成に最初から頼ってうまくいかなかったら再生成

Sosuke Suzukiさん

TypeScript
- altJSはいろいろある
- その中でJSのスーパーセット的な位置づけ
tsc
- 公式のコンパイラーが遅い
- rustとかgo製のものがいろいろ出てる
型チェック
- checker.jsがマイクロソフト依存
TypeScriptファーストな流れ
- フレームワークはTSファースト
- DenoやBunなどTSがそのまま動く
- NodeもTypeAnnotationsという議論で型をコメントとして扱う案
ツールの高速化
- swc/Turbopack
  - vercel
- oxc/vite
  - void0
- rspack
  - bytedance
- esbuild
- ビルドツールなので型チェックははやくならない
tsgo
- 公式がgoで書き直して型チェックを早くする
今後
- TSを意識することがなくなっていく
  - 意識してビルドするということがなくなっていく
  - バックエンドでは特に
- フロントエンドは環境が利用者依存なので事情が違う
  - バンドルしたりミニファイしたりビルドのステップは残る
  - 小さくするなら型情報も消したい

ESLint Plugin
- Parserがプラガブル
- tsやbabelの構文にも対応できる
Rust製Linter
- Biome/deno_lint/OxLint
- プラグインはこれまで提供されてなかった
  - JS/TSでプラグインを書くとパフォーマンスが落ちる
  - ルールをコアに集約するという思想を持っていたものが多い
Rust製Linterのプラグインを何で書くか
- Rust
  - 書ける人が少ないのでは
- js/ts
  - deno_lintが対応
- DSL
  - BiomeがGritQL
- wasm
GridQL
- コードベースに対して構造的な検索修正ができるクエリ言語
- Rust製なのでRustで完結できる
JSでのプラグイン
- JSエンジンを保つ必要がある
  - denoはdeno runtimeで
- JSとRustの境界
  - denoではASTをフラット化して小さくして対処している