chore: Svelte静的解析ルールとCI警告ゲートの強化を検討する

[sh4869221b]

概要

現在の yosan-flow には、svelte-check、ESLint、eslint-plugin-svelte、TypeScript strict mode、Prettier、および GitHub Actions 上の品質チェックが導入済みです。

現状の標準構成を維持しつつ、Svelte 固有の不具合や保守性低下をより早い段階で検出できるよう、静的解析ルールと CI の警告ゲートを段階的に強化することを検討します。

現在の状態

• pnpm check
  • svelte-kit sync
  • svelte-check --tsconfig ./tsconfig.json
• pnpm lint
  • eslint .
• typescript-eslint の recommended 設定を使用
• eslint-plugin-svelte の flat/recommended を使用
• eslint-plugin-svelte の flat/prettier を使用
• TypeScript の strict: true と checkJs: true を有効化
• GitHub Actions で format、lint、check、test、build、E2E を実行

一方、以下は現在明示的に強制していません。

• svelte-check --fail-on-warnings
• eslint --max-warnings=0
• プロジェクト方針としての追加 Svelte ルール
• svelte/prefer-svelte-reactivity を無効化している理由の文書化

導入候補

1. CI 用の厳格なスクリプトを追加する

通常開発用コマンドは維持し、CI でのみ警告を失敗として扱う案を検討します。

{
  "scripts": {
    "check:ci": "svelte-kit sync && svelte-check --tsconfig ./tsconfig.json --fail-on-warnings",
    "lint:ci": "eslint . --max-warnings=0"
  }
}

GitHub Actions では pnpm check / pnpm lint の代わりに、pnpm check:ci / pnpm lint:ci を実行します。

2. Svelte 固有ルールを明示する

以下のルールについて、既存コードへの影響と誤検知を確認した上で段階導入を検討します。

{
  rules: {
    "svelte/require-each-key": "error",
    "svelte/button-has-type": "error",
    "svelte/no-unused-props": "warn",
    "svelte/prefer-const": "error"
  }
}

no-unused-props は誤検知やコンポーネント API への影響を確認し、最初は warn とする案です。

prefer-const は ESLint 本体のルールとの競合を避けるため、必要に応じて以下を併用します。

{
  rules: {
    "prefer-const": "off",
    "svelte/prefer-const": "error"
  }
}

3. svelte/prefer-svelte-reactivity の方針を明確化する

現在は次の設定で無効化されています。

"svelte/prefer-svelte-reactivity": "off"

次のいずれかを選択します。

• 有効化し、既存コードを Svelte のリアクティブ対応 API に合わせる
• 無効化を維持し、理由を設定ファイルまたは CONTRIBUTING に記載する
• 対象ディレクトリを限定して段階導入する

導入手順案

1. 現在の svelte-check と ESLint の警告件数を確認する
2. 既存警告の原因を分類する
3. 誤検知や設計上許容する警告を整理する
4. CI 用の check:ci と lint:ci を追加する
5. 追加ルールを一つずつ有効化する
6. 既存コードの修正とルール追加を可能な限り別コミットに分ける
7. README または CONTRIBUTING に静的解析方針を記載する

検討事項

• 警告を一括で CI エラー化すると Renovate PR や既存開発フローを止める可能性がある
• svelte/no-unused-props は公開コンポーネント API や間接参照で誤検知しないか確認が必要
• svelte/prefer-svelte-reactivity はサーバー側コードや不変データまで過剰に制約しないか確認が必要
• ルール追加による可読性向上と、設定・抑制コメントの増加とのバランスを取る
• Prettier、TypeScript ESLint、Svelte parser の既存設定と競合しないことを確認する

対象外

• アプリケーション機能の変更
• UI デザインの変更
• 大規模なコンポーネント再設計
• TypeScript 設定全体の再構築
• formatter による無関係な全面差分

受け入れ条件

• 導入対象ルールと導入しないルールの理由が明確になっている
• pnpm check:ci が成功する
• pnpm lint:ci が成功する
• CI で Svelte／ESLint の警告を意図した方針どおり扱える
• pnpm test:unit が成功する
• pnpm test:integration が成功する
• pnpm build が成功する
• 必要に応じて pnpm test:e2e が成功する
• ESLint 設定内の無効化ルールに理由が記載されている
• README または CONTRIBUTING に静的解析コマンドが記載されている