prek を使ってみる ADR - alternative pre-commit -

tl;dr

• pre-commit の代替ツールを検討中
• 前提条件は少し特殊かも
• prek にたどり着いたので移行中
• というか移行していくので ADR を AI に書いてもらった

まとめ

充分いけそう

先達がいた

• だいたい同じ感想だし、必要十分な内容なので ↑ の記事を読んでください
• 気が向いた人だけ ↓ を読んでください

個人的に大事にしているツール選定の前提条件

クロスプラットフォームでシングルバイナリであること

• 開発言語に依存するツールは言語変更の妨げになりがち
• 言語依存のツールを否定はしないが、そもそも全員が納得するツールなど存在しない
• フロントが JavaScript/TypeScript でバックエンドが php で Iac は Terraform(or pulumi) で、ってところで、言語依存のツール選定は戦争じゃろがい（エンジニアチームが別ならそれぞれのツールを使ってもいいと思うけど、自分たちの使いたいツールだけを使って他のチームのことは知らんって態度のエンジニアは好きになれないんだよねｗ）
• LL 系の言語依存ツールはライブラリのバージョンアップ追従などがバラバラになってしまい、余計な運用負荷がかかる（と思っている。そして実際にバージョンアップなんかしてないというゴミみたいなリポジトリをよく見るｗ）
• というわけで Go または Rust などのクロスプラットフォームでシングルバイナリのツールを推している
• もちろん各言語のお作法でインストールできるのは構わない（brew でいれようが uv や pip や npm で入れても構わない）
• これはどのツール選定でもだいたい同じ

多機能過ぎないこと（ひとつのことをうまくやってくれること）

• いろいろやりたいことがあるのはわかる
• 全部入りで完成しているなら否定はしない
• UNIX 哲学 - Wikipedia を大事にしたい
• タスクランナーと git hook manager は仕事が被る部分があるが、ちゃんと弁えたい
• これもどのツール選定でもだいたい同じ
• ちなみに asdf や mise を選定しないのはこれが一番大きい

OSS であること

• お金をかけるところとかけたくないところの区別はしっかりつける
• 作者やコントリビューターにコーヒーを奢るくらいのことはしよう
• それはそれとして、問題発生時にコードを確認してデバッグできるのは重要なので GitHub で公開されているツールであるのがうれしい（GitLab でもアトラシアンでも他のでもいいけど）

互換性があること

• 移行前後で設定変更が必要になると面倒だし、重要度が高くないと移行しないできないになりがち
• できるだけ標準的な命名がなされた設定を再利用可能であることは移行の敷居を下げることができる
• 設定変更が必要になっても移行が楽、または設定自体がわかりやすくなっているとうれしい
• この点で今回の prek は pre-commit 互換（設定ファイルがそのまま使える）のは大変うれしい

ADR

AI に ADR 書かせたものを手直しした。が、かてぇなぁ。。。ｗ

ADR

# アーキテクチャ意思決定記録（ADR）

## 決定内容

Git フック管理ツール選定について、`pre-commit` から Rust 製の `prek` へ移行する方針を採用する。Lefthook や Githooks など他の選択肢と比較検討した結果、現時点では prek が要件適合度・将来性・体験性で最有力と判断した。

## 背景・目的・選定の前提条件

- クロスプラットフォーム対応
- 開発言語依存の排除、シングルバイナリ志向
- pre-commit-config.yml の互換性（既存設定・運用資産の活用）
- チームやオープンソース貢献の高速化・省リソース化
- pre-commit のコミュニティ、課題対応、将来的な安定運用への不安などへの対応として移行を検討する

## 選定理由とメリット

### prek の主なメリット

- 高速化

インストールやフック実行が約 7-10 倍高速。開発者のイテレーションロスを大きく削減し、CI/CD 時実行も短縮できる。

- 単一バイナリ・依存ゼロ設計

Rust 製で Python など別ランタイム不要。ダウンロード一本で導入できる。モノレポ運用やマルチワークスペースもネイティブ対応。

- pre-commit-config.yaml 互換

既存の pre-commit の設定やフックスクリプトを原則そのまま活用可能。

- 高速なツールチェーン管理

Python, Node.js, Go, Rust, Ruby などの言語ツールチェーン管理を改善、各プロジェクト間で共有・並列処理されるため初回セットアップ/切り替えが爆速。

- UX の改善

複数フックの一括実行、変更ディレクトリ／コミット差分だけ実施等インターフェースが拡張。

- OSS・活発な開発サイクル

2025 年秋時点で実運用事例あり（Airflow 他）、活発なメンテナンス・改善が進行中。

### 他ツール（Lefthook, Githooks）との比較

<!-- prettier-ignore-start -->
| 項目 | prek | Lefthook | Githooks |
| :-- | :--: | :--: | :--: |
| 言語/ランタイム | Rust/依存なし | Go/依存なし | Go/依存なし |
| pre-commit互換 | 完全 | 独自構造 | 独自構造 |
| スピード | 最速 | 速い | 標準 |
| 導入難易度 | 最も簡単 | 簡単 | やや習得必要 |
| 設定資産流用 | 既存流用可 | 要変換 | 要変換 |
| 機能拡張性 | 高い | 高い | 高い |
| 活発度 | 急伸 | 安定 | 安定 |
<!-- prettier-ignore-end -->

- Lefthook, Githooks もクロスプラットフォームで高速だが、pre-commit-config.yaml の設定資産を直接流用できるのは prek のみ
- 移行コスト・高速性・開発サイクルの短縮で prek が有利

## デメリット・懸念事項（prek）

- 成熟度・導入事例不足

数ヶ月前に登場した新鋭のため、pre-commit よりもドキュメント・ユーザー事例・エコシステムがまだ限られる。

- 一部機能未実装

公式で「production-ready ではない」「未実装サブコマンド・未サポート言語あり」「互換ギャップあり」と告知。

- 安定性/将来性リスク

急伸プロジェクトにつき将来の破壊的変更、公式 Wiki 等の追体験が必要となる可能性あり。

- pre-commit 独自エコシステムへの未対応シーン

社内独自フックやサードパーティ製 pre-commit プラグイン活用時には、個別検証が必要。

## 採用方針

- まずは単体リポジトリで prek 導入を試行し、pre-commit→prek 間の設定・フック流用・実運用テストで安定性やギャップを確認
- 生産ラインや CI 全面導入の前に、Airflow など OSS 成功事例・新規バージョンリリース予定の追従を適宜チェック
- 必要に応じ、Lefthook や Githooks もバックアップ案としてリストアップし、YAML 変換や運用移行可能性を検証

## まとめ

現状、pre-commit からの移行に最も有効な選択肢は「prek」であり、導入コストと開発効率・未来志向に優れる。しかし安定運用・継続メンテを担保するため、将来的なコミュニティ成熟度や未実装機能のキャッチアップも継続チェックする。

note

• 動作確認はできた（インストールして prek run -a だけで OK）
• ちなみにインストールは aqua を使って いれた
• pre-commit uninstall して prek install で置き換え完了（すばらしい）
• prek を使うリポジトリは GitHub Actions も修正しないといけないけど

- uses: pre-commit/action@v3.0.1
# をこうするだけでOK
- uses: j178/prek-action@v1

• 個人的には autoupdate も Actions でやってるからもう少しいるけど
• ローカルでは direnv で function かいて pre-commit を prek に置換すればついうっかり pre-commit しても大丈夫（そもそもどっちも使えるように選んだんだから別にどっちが動いても構わないけど）

# .envrc
pre-commit (){
  prek "$@"
}
export_function pre-commit