🐺

eslint-seatbelt で段階的にESLintルールを厳しくする

に公開

はじめに

ESLintのルールを既存のコードベースに適用する際、一度に厳格なルールを導入すると大量のエラーが発生し、チームの開発効率に影響を与えがちです。

そこでeslint-seatbeltというツールで段階的にルールを厳しくできることを知り、実際に素振りしてみました。

https://www.notion.com/ja/blog/how-we-evolved-our-code-notions-ratcheting-system-using-custom-eslint-rules

eslint-seatbelt とは

eslint-seatbeltは、ESLintルールを段階的に適用できるプログレッシブリンティングツールです。

https://github.com/justjake/eslint-seatbelt

概念

eslint-seatbeltはラチェット(ratchet)という概念を導入しています。
一方方向にしか進まないラチェットのように、コードベースの品質を徐々に向上させるというものです。

導入方法

インストール

まず、npmでeslint-seatbeltをインストールします:

npm install --save-dev eslint-seatbelt

基本的な設定例

ここではTypeScriptプロジェクトを例に、eslint-seatbeltを設定する方法を説明します。

調査した当時のバージョンは0.1.2です。

.eslint.config.mtsescapeanyに関するルールを追加する例

import tseslint from "typescript-eslint";
import { defineConfig } from "eslint/config";
import seatbelt from "eslint-seatbelt";

export default defineConfig([
  // TypeScript ESLintの基本設定
  // seatbeltの設定を追加
  seatbelt.configs.enable,
  {
    rules: {
      // 二つのルールを例示
      "no-useless-escape": "error",
      "@typescript-eslint/no-explicit-any": "error",
    }
  }
]);

実行

eslintを実行して、許容エラーを増やします。

SEATBELT_INCREASE=<rule> eslint .

# 全ての許容エラーを増やす場合
SEATBELT_INCREASE=ALL eslint .
# 特定のルールだけ許容エラーを増やす場合
SEATBELT_INCREASE="no-useless-escape" eslint .

実行後、eslint.seatbelt.tsvというファイルが生成され、各ルールに対する許容エラー数が記録されます。

"src/__tests__/domain/Hoge.test.ts"	"no-useless-escape"	2
"src/__tests__/domain/Fuga.test.ts"	"@typescript-eslint/no-explicit-any"	1

変更をcommitする

ESLintの設定ファイル(eslint.config.mts)とseatbelt設定ファイル(eslint.seatbelt.tsv)の変更をコミットします。

運用

tsvファイルに記録された許容エラー数を超えると、ESLintはエラーを報告します。
例えば、no-useless-escapeルールで2つの許容エラーが設定されている場合、3つ目のエラーが発生するとESLintはエラーを報告します。
エラーを修正した後はeslintコマンドを実行することで、許容エラー数を自動的に更新できます。

CIでの利用

SEATBELT_FROZEN=1 eslint or CI=1 eslint
どちらかの環境変数を設定して実行することで、更新をせずにエラー数のチェックのみを行います。

利用してみた所感

  • 段階的にルールを厳しくできるため、既存コードベースへの導入が現実的
  • ratchetファイルという形で許容エラー数を管理でき、チームで共有しやすい(制約を設けやすい)
  • CI/CDパイプラインに組み込みやすく、継続的な品質向上が可能

終わりに

今回はeslint-seatbeltを使って、段階的にESLintルールを適用する方法についてみていきました。
ratchetファイルという形でgit管理できるので、チームでの運用もしやすい印象でした。
各プロジェクトの状況の見える化もratchetファイルで進めていきたいところです。

Discussion