🤖
Vibe codingをするなら、ルールを追加する前に自作eslintルールを作れないか考えよう
はじめに
実はeslintルールは自作することができる。
eslintはとても自由度が高く、Vibe Codingならばeslintルールを簡単に自作することができる。
自作eslintルールならエージェントのコンテキストを汚染することもなく、設定を消さない限り永続する。
そのため、TypeScriptプロジェクトのVibe Codingととても相性がいい。
具体例
例えばテストを書いている時、エージェントはよくprismaのmockを作成する。
テスト用DBを用意できるのであればmockではなくprismaインスタンスを使った方がはるかに有用なのだからmockは使ってほしくない。
そういう時は、たった一言指示すればいい。
prismaのmockの作成を禁止するeslintルールを作って
これであなたのエージェントは有効なeslintルールをあなたの代わりに自作して、それ以後eslintがエージェントにルールを強制してくれる。
自力でeslintルールを自作しようとすると泥臭い作業が必要だったが、それはまさにVibe Codingの得意分野なので任せてしまえる。
これまでに作ったルール
- prismaのmockの作成を禁止する
- Service層でフレームワーク固有の関数をインポートすることを禁止する
- Next.js 15のPage Componentでparams/searchParamsをPromiseとして扱うことを強制する
- Next.jsのAPI Route/Server Actionsでビジネスロジックをtry-catchで囲うことを強制する
- Next.jsのServer ActionsでFormDataを受け取った場合はzodによるバリデーションを強制する
- Serviceクラスファイルに対応するテストファイルの存在を強制する
どこまでできるか？
eslintはTypeScriptのソースコードをパースして抽象構文木（AST）として扱っている。
そのため、コードに関するルールはほぼ実現可能。
実際にコードを貼り付けて確かめてみると、イメージがしやすい。
実現できなかったルール
今のところ、これまでに実装できなかったルールは「ハンドラ内でリクエストのバリデーション、ビジネスロジック、レスポンス構築・バリデーションをブロック分けして、それぞれの先頭にブロックコメントで追加するルール」だけ。
このルールは、CLAUDE.mdに追加することで問題なく実現できている。
Discussion