TS7.0移行: リンター移行 — eslint → oxlint 検討

[9c5s]

概要

typescript-eslint の tsgo (Corsa API) 対応が 1-2年先のため、TS7.0 完全移行時のリンター代替を検討する。

影響度: 大

背景

typescript-eslint は TypeScript の Strada API に依存。tsgo の Corsa API 対応は 1-2年先。
TS 7.0 完全移行時にリンターの刷新が必要になる。

選択肢

ツール	速度	tsgo 対応	TS型チェックルール	jsdoc 対応
oxlint + tsgolint	50-100x	tsgo 専用設計	43ルール	要調査
biome 2.0	高速	独自型推論 (85%)	限定的	要調査
eslint + TS6.0 並行維持	1x (基準)	Corsa API 待ち	全ルール	完全対応

現在の eslint ルール棚卸し

eslint recommended プリセット:

• eslint.configs.recommended 適用 (no-undef, no-redeclare 等多数のベースルール含む)
• oxlint/biome 移行時にはこれらベースルールの代替可否も確認が必要

カスタムルール:

• no-console (warn)
• @typescript-eslint/no-unused-vars (warn) — argsIgnorePattern: ^_
• @typescript-eslint/no-empty-function (warn) — arrowFunctions 許可

jsdoc ルール (TypeDoc 最適化):

• jsdoc/require-jsdoc (error) — クラス、関数、メソッド必須
• jsdoc/require-description (error)
• jsdoc/require-param-description (error)
• jsdoc/require-returns-description (error)
• jsdoc/require-returns (error)
• jsdoc/require-hyphen-before-param-description (error)
• jsdoc/no-types (error)
• jsdoc/check-tag-names (error) — remarks, example, category, see

ファイル別ルール緩和:

• tests/: jsdoc 緩和、no-explicit-any off
• examples/: jsdoc 緩和、no-console off

チェックリスト

• oxlint の対応ルールマッピング (eslint recommended + カスタムルール → oxlint 対応状況)
• oxlint での jsdoc 系ルール代替調査
• tsgolint の型チェックルール評価
• biome 2.0 の評価 (Prettier 統合の利点)
• 移行判断基準の策定 (いつ、どの条件で移行するか)
• 段階的移行計画の検討 (oxlint 初期検査 + eslint 特殊ルールのデュアル運用)

[coderabbitai]

Coding Plan

Summary

• 現行 ESLint 設定の全ルールを棚卸しし、oxlint/biome/tsgolint それぞれへのマッピング調査を実施
• 特に JSDoc ルールはカバレッジが不完全なため、oxlint JS plugins による eslint-plugin-jsdoc 併用を代替策として評価
• 移行判断は TS7.0 リリース時期と各ツールの成熟度を条件とし、段階的デュアル運用を前提とした計画を策定
• 調査成果物は docs/migration/ 配下にドキュメント化し、将来の意思決定に活用可能な形式で残す

Implementation Steps

Phase 1: ツール評価とルールマッピング調査

現在の ESLint 設定を基に、各代替ツール（oxlint、tsgolint、biome 2.0）の対応状況を調査し、ルールマッピング表を作成する。

Task 1: oxlint ルールマッピング作成

現在の ESLint ルールと oxlint 対応状況の詳細マッピングを作成する。

• eslint.config.mjs の全ルールをリスト化し、oxlint の対応ルール名と対応状況（完全対応/部分対応/未対応）を調査
• eslint.configs.recommended 内の主要ルール（no-undef、no-redeclare 等）の oxlint 対応確認
• @typescript-eslint/no-unused-vars の argsIgnorePattern オプション互換性を検証
• @typescript-eslint/no-empty-function の allowArrowFunctions オプション互換性を検証
• 調査結果を docs/migration/ ディレクトリに Markdown 形式で文書化

Task 2: oxlint JSDoc ルール調査

JSDoc 系ルールの oxlint 対応状況を詳細調査し、代替手段を検討する。

• oxlint ネイティブ jsdoc プラグインの対応ルール一覧を作成（require-param-description 等の対応確認済みルール）
• 現在使用中の8つの jsdoc ルールそれぞれの対応状況を調査
• 未対応ルール（require-jsdoc、require-description 等）に対する代替手段を調査（JS plugins による eslint-plugin-jsdoc 併用の可否）
• check-tag-names のカスタムタグ（remarks、example、category、see）サポート状況を確認

Task 3: tsgolint 評価

tsgolint の型チェックルール機能を評価し、typescript-eslint との比較を行う。

• tsgolint の43ルールの一覧と各ルールの機能を調査
• 現在使用中の typescript-eslint ルールとの対応関係を確認
• tsgo (Corsa API) との連携方式と利用条件を調査
• 型情報を使用するルール（例: no-floating-promises 相当）の有無を確認

Task 4: biome 2.0 評価

biome 2.0 の Linter/Formatter 統合機能を評価する。

• biome 2.0 の TypeScript ルール対応状況を調査（独自型推論85%の実用性評価）
• eslint.configs.recommended 相当のルールカバレッジを確認
• JSDoc ルール対応状況を調査
• Prettier 統合による利点（設定統合、速度）を評価
• ファイル別オーバーライド（tests/、examples/）の設定方式を確認

🤖 Prompt for AI agents

フェーズ1では、現在の ESLint 設定（eslint.config.mjs）を基に、oxlint・tsgolint・biome 2.0
それぞれの対応状況を調査し、ルールマッピング表を作成することが目的です。

- `eslint.config.mjs` に定義されている全ルールをリスト化する
- 対象ルール: no-console、@typescript-eslint/no-unused-vars（argsIgnorePattern
オプション含む）、@typescript-eslint/no-empty-function（allowArrowFunctions オプション含む）
  - eslint.configs.recommended 内の主要ルール（no-undef、no-redeclare 等）も含める
  - 現在使用中の8つの jsdoc ルールもリスト化する（require-jsdoc、require-description 等）
- oxlint のルールマッピングを調査し、各ルールの対応状況を「完全対応 / 部分対応 / 未対応」で分類する
  - `@typescript-eslint/no-unused-vars` の argsIgnorePattern オプション互換性を検証
  - `@typescript-eslint/no-empty-function` の allowArrowFunctions オプション互換性を検証
  - oxlint ネイティブ jsdoc プラグインの対応ルール一覧を作成
- 未対応 jsdoc ルール（require-jsdoc、require-description 等）に対する JS plugins による
eslint-plugin-jsdoc 併用の可否を調査
  - check-tag-names のカスタムタグ（remarks、example、category、see）サポート状況を確認
- tsgolint の43ルール一覧と各ルールの機能を調査し、現在の typescript-eslint ルールとの対応関係を確認する
  - tsgo (Corsa API) との連携方式と利用条件を調査
  - 型情報を使用するルール（例: no-floating-promises 相当）の有無を確認
- biome 2.0 の TypeScript ルール対応状況を調査する
  - 独自型推論85%の実用性を評価
  - eslint.configs.recommended 相当のルールカバレッジを確認
  - JSDoc ルール対応状況を調査
  - Prettier 統合による利点（設定統合、速度）を評価
  - ファイル別オーバーライド（tests/**、examples/**）の設定方式を確認
- 調査結果を `docs/migration/` ディレクトリに Markdown 形式で文書化する

Phase 2: ギャップ分析と互換性評価

各ツールの調査結果を統合し、現行 ESLint 設定との差分を明確化する。

Task 1: ルールカバレッジギャップ分析

各ツールのルールカバレッジ状況を比較表にまとめる。

• 3つのカテゴリ（eslint core、typescript-eslint、jsdoc）ごとに対応状況を整理
• 完全互換、部分互換、非互換のルールを分類
• 非互換ルールに対する回避策（デュアル運用、別ツール併用等）を検討
• tests/** と examples/** のオーバーライド設定の各ツールでの実現方法を整理

Task 2: 移行リスク評価

各ツールへの移行に伴うリスクと対策を評価する。

• JSDoc 系ルールのギャップによる TypeDoc 品質への影響を評価
• 型チェックルール不足による型安全性への影響を評価
• ツールの成熟度・コミュニティサポート状況を評価
• 将来の typescript-eslint Corsa API 対応後のリバート可能性を検討

🤖 Prompt for AI agents

フェーズ2では、フェーズ1の調査結果を統合し、現行 ESLint 設定との差分（ギャップ）を明確化することが目的です。

- 3つのカテゴリ（eslint core、typescript-eslint、jsdoc）ごとに、各ツールのルール対応状況を整理した比較表を作成する
  - 完全互換 / 部分互換 / 非互換のルールを分類する
  - 非互換ルールに対する回避策（デュアル運用、別ツール併用等）を検討する
  - tests/** と examples/** のオーバーライド設定の各ツールでの実現方法を整理する
- 各ツールへの移行に伴うリスクと対策を評価する
  - JSDoc 系ルールのギャップによる TypeDoc 品質への影響を評価する
  - 型チェックルール不足による型安全性への影響を評価する
  - ツールの成熟度・コミュニティサポート状況を評価する
  - 将来の typescript-eslint Corsa API 対応後のリバート可能性を検討する
- 分析結果は `docs/migration/` ディレクトリ配下に Markdown 形式で文書化する

Phase 3: 移行判断基準と段階的移行計画

調査結果を基に、具体的な移行判断基準と実行計画を策定する。

Task 1: 移行判断基準の策定

いつ、どの条件で移行するかの明確な基準を定義する。

• 移行トリガー条件の定義（TypeScript バージョン、ツール成熟度、チーム状況）
• 各ツールの選定基準（ルールカバレッジ閾値、パフォーマンス要件、メンテナンス性）
• Go/No-Go 判断フロー（どの条件が満たされれば移行を実行するか）
• ロールバック基準の定義（移行後に問題発生時の撤退条件）

Task 2: 段階的移行計画の策定

デュアル運用を含む段階的な移行計画を策定する。

• フェーズ1: oxlint による高速初期検査（CI での並列実行）の導入計画
• フェーズ2: 互換ルールの段階的な oxlint 移管計画
• フェーズ3: JSDoc 系ルールの移行または eslint 併用維持の判断ポイント
• フェーズ4: 完全移行または長期デュアル運用の最終判断
• 各フェーズのサクセスクライテリアと検証方法を定義

Task 3: 調査結果ドキュメント作成

調査結果を包括的なドキュメントとしてまとめる。

• docs/migration/linter-migration-evaluation.md に調査結果の総括を作成
• ツール比較表（速度、ルール対応、tsgo 対応、JSDoc 対応）を作成
• 推奨ツールと推奨移行パスの明記
• チェックリスト全項目の完了状況と結論を記載

🤖 Prompt for AI agents

フェーズ3では、フェーズ1・2の調査・分析結果を基に、具体的な移行判断基準と段階的移行計画を策定し、成果物をドキュメントとして残すことが目的です。

- 移行判断基準を定義する
  - 移行トリガー条件（TypeScript バージョン、ツール成熟度、チーム状況）を明記する
  - 各ツールの選定基準（ルールカバレッジ閾値、パフォーマンス要件、メンテナンス性）を定義する
  - Go/No-Go 判断フロー（どの条件が満たされれば移行を実行するか）を作成する
  - ロールバック基準（移行後に問題発生時の撤退条件）を定義する
- デュアル運用を含む段階的移行計画を策定する
  - フェーズ1: oxlint による高速初期検査（CI での並列実行）の導入計画
  - フェーズ2: 互換ルールの段階的な oxlint 移管計画
  - フェーズ3: JSDoc 系ルールの移行または eslint 併用維持の判断ポイント
  - フェーズ4: 完全移行または長期デュアル運用の最終判断
  - 各フェーズのサクセスクライテリアと検証方法を定義する
- `docs/migration/linter-migration-evaluation.md` に調査結果の総括ドキュメントを作成する
  - ツール比較表（速度、ルール対応、tsgo 対応、JSDoc 対応）を含める
  - 推奨ツールと推奨移行パスを明記する
  - チェックリスト全項目の完了状況と結論を記載する

Research

プロジェクトは ESLint v9 のフラットコンフィグ形式（eslint.config.mjs）を採用。@eslint/js recommended、typescript-eslint recommended、eslint-plugin-jsdoc の3プラグインを使用。カスタムルールとして no-console、@typescript-eslint/no-unused-vars、@typescript-eslint/no-empty-function を設定。JSDoc ルールは TypeDoc 向けに最適化され、require-jsdoc、require-description 等を error レベルで適用。tests/** と examples/** には専用の緩和ルールを設定している。

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

フェーズ1では、現在の ESLint 設定（eslint.config.mjs）を基に、oxlint・tsgolint・biome 2.0
それぞれの対応状況を調査し、ルールマッピング表を作成することが目的です。

- `eslint.config.mjs` に定義されている全ルールをリスト化する
- 対象ルール: no-console、@typescript-eslint/no-unused-vars（argsIgnorePattern
オプション含む）、@typescript-eslint/no-empty-function（allowArrowFunctions オプション含む）
  - eslint.configs.recommended 内の主要ルール（no-undef、no-redeclare 等）も含める
  - 現在使用中の8つの jsdoc ルールもリスト化する（require-jsdoc、require-description 等）
- oxlint のルールマッピングを調査し、各ルールの対応状況を「完全対応 / 部分対応 / 未対応」で分類する
  - `@typescript-eslint/no-unused-vars` の argsIgnorePattern オプション互換性を検証
  - `@typescript-eslint/no-empty-function` の allowArrowFunctions オプション互換性を検証
  - oxlint ネイティブ jsdoc プラグインの対応ルール一覧を作成
- 未対応 jsdoc ルール（require-jsdoc、require-description 等）に対する JS plugins による
eslint-plugin-jsdoc 併用の可否を調査
  - check-tag-names のカスタムタグ（remarks、example、category、see）サポート状況を確認
- tsgolint の43ルール一覧と各ルールの機能を調査し、現在の typescript-eslint ルールとの対応関係を確認する
  - tsgo (Corsa API) との連携方式と利用条件を調査
  - 型情報を使用するルール（例: no-floating-promises 相当）の有無を確認
- biome 2.0 の TypeScript ルール対応状況を調査する
  - 独自型推論85%の実用性を評価
  - eslint.configs.recommended 相当のルールカバレッジを確認
  - JSDoc ルール対応状況を調査
  - Prettier 統合による利点（設定統合、速度）を評価
  - ファイル別オーバーライド（tests/**、examples/**）の設定方式を確認
- 調査結果を `docs/migration/` ディレクトリに Markdown 形式で文書化する
===============================================================================

Task: 2

フェーズ2では、フェーズ1の調査結果を統合し、現行 ESLint 設定との差分（ギャップ）を明確化することが目的です。

- 3つのカテゴリ（eslint core、typescript-eslint、jsdoc）ごとに、各ツールのルール対応状況を整理した比較表を作成する
  - 完全互換 / 部分互換 / 非互換のルールを分類する
  - 非互換ルールに対する回避策（デュアル運用、別ツール併用等）を検討する
  - tests/** と examples/** のオーバーライド設定の各ツールでの実現方法を整理する
- 各ツールへの移行に伴うリスクと対策を評価する
  - JSDoc 系ルールのギャップによる TypeDoc 品質への影響を評価する
  - 型チェックルール不足による型安全性への影響を評価する
  - ツールの成熟度・コミュニティサポート状況を評価する
  - 将来の typescript-eslint Corsa API 対応後のリバート可能性を検討する
- 分析結果は `docs/migration/` ディレクトリ配下に Markdown 形式で文書化する
===============================================================================

Task: 3

フェーズ3では、フェーズ1・2の調査・分析結果を基に、具体的な移行判断基準と段階的移行計画を策定し、成果物をドキュメントとして残すことが目的です。

- 移行判断基準を定義する
  - 移行トリガー条件（TypeScript バージョン、ツール成熟度、チーム状況）を明記する
  - 各ツールの選定基準（ルールカバレッジ閾値、パフォーマンス要件、メンテナンス性）を定義する
  - Go/No-Go 判断フロー（どの条件が満たされれば移行を実行するか）を作成する
  - ロールバック基準（移行後に問題発生時の撤退条件）を定義する
- デュアル運用を含む段階的移行計画を策定する
  - フェーズ1: oxlint による高速初期検査（CI での並列実行）の導入計画
  - フェーズ2: 互換ルールの段階的な oxlint 移管計画
  - フェーズ3: JSDoc 系ルールの移行または eslint 併用維持の判断ポイント
  - フェーズ4: 完全移行または長期デュアル運用の最終判断
  - 各フェーズのサクセスクライテリアと検証方法を定義する
- `docs/migration/linter-migration-evaluation.md` に調査結果の総括ドキュメントを作成する
  - ツール比較表（速度、ルール対応、tsgo 対応、JSDoc 対応）を含める
  - 推奨ツールと推奨移行パスを明記する
  - チェックリスト全項目の完了状況と結論を記載する

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!