Flutterでコード生成ライブラリを使う時のコード管理について
はじめに
Flutterでアプリを開発していると、freezedやriverpod_generatorなどのコード生成ライブラリを使うことが多くなります。
筆者はいくつかのプロジェクトに参加してきたのですが、チームごとに、これら自動生成されるファイルの管理が異なっていました。
そこで、これらのライブラリが生成するコード管理について、私見をまとめます。
mainブランチのあるべき姿
前提として、mainブランチは「市場にリリースされているコード」がそのまま管理されているべきだと考えています。
特に重要だと考えているのは、git cloneしたら最新のリリースに対応するコードが手に入り、git checkoutでタグがついたcommitに移動すれば、そのリリース時のコードが手に入る環境です。Flutterにおいては、pubspec.lockファイルが利用ライブラリのバージョンを固定しているため、比較的簡単にこのような状態を実現できます。(ビルドしているFlutterのバージョンについては、flutter downgradeコマンドの対応や、fvmなどを利用することになります)
この観点からすると、gitignoreに.g.dartや.freezed.dartを追加するのは避けるべき、です。
たしかに、build_runnerなどのバージョンも記載されているので、都度コード生成を実行すれば同じ結果が得られます。しかし、この手間を「特定のgit tagのバージョンを確認しなければならない」時に必須とするのは、大きな負担になると思います。
自動生成のファイルをcommitしておくと、GitHub上でcommitを指定するだけで、例えば自動生成ファイルの中に原因があることが確認できるかもしれません。こういったメリットは、特に緊急時の調査を助けるため、重視するべきだと思います。
生成コードの管理
生成される.g.dartや.freezed.dartの管理方法について。
私見としては、これらのファイルの生成については、広く使われている設定に従う方が新規に参加するメンバーがびっくりしないという点で優れています。デフォルトの設定を使っておけば、新規参加メンバーが「なぜこうなっているのか」という疑問を持つ必要がなく、また周囲もそれを説明する必要がない、という点が魅力的です。
IDEのサポートを活用する
Flutterのソースコードをファイラーで検索することは稀なはずです。大抵の場合、プロジェクトをIDEに読み込ませて、プロジェクトの内容を確認するでしょう。
そこで、個人的におすすめしたいのはIDEのサポートを活用することです。
VSCode
VSCodeには、Explorer File Nesting機能が存在します。この機能は、一定の拡張子を持つファイルを、IDE上で階層表示する機能です。
ファイルのパターンとして、.mock.dartなどを追加することで、まとめるファイルの種類を追加することもできます。
上記のように.vscode/settings.jsonに設定を追加することで、プロジェクトに参加する全ての人に対して、同じ設定を適用できます。
Android Studio/IntelliJ IDEA
Android Studio/IntelliJ IDEAにはFile nesting rules機能が存在します。この機能は、一定の拡張子を持つファイルを、IDE上で階層表示する機能です。
こちらはAndroid StudioやIntelliJ IDEA上で設定を行う必要があります。自分の手元の環境を見たところ、この設定はプロジェクトごとではなく、IDEの設定として保存されているようです。このため、プロジェクトに参加するメンバー全員に適用するには、環境構築の手順書などに追加する必要がありそうです。
VSCodeよりは、手間がかかると言えます。とは言え、そこまで躊躇するようなものではないのではないかなと。
gitattributesを活用する
「Pull Requestのレビュー時に、レビュー内容と関係のない自動生成ファイルの差分が混じって困る」という声もあるかと思います。
自動生成ファイルの差分が本当にコードの編集内容と関係ないかどうかについては意見があるのですが、確かにriverpod_generaterがハッシュ値が(一見コードに変更がないのに)更新することがあります。このため、レビュー時に自動生成ファイルが表示されることが、開発の体験を悪くしているケースもあるはずです。
GitHubには、.gitattributesに設定したファイルが差分に含まれている時に、デフォルトで閉じた状態にする機能が存在します。これを利用することで、レビュー時に自動生成ファイルの差分が表示されなくなります。(もちろん、差分を開いて確認することは可能です)
一例ですが、FlutterKaigi 2023公式アプリでは、次のようなattributesを設定しています。
どのように表示されるかは、こちらのPRを開くと確認できます。
まとめ
build.yamlに設定を追加せず、快適に開発することもできるぞ…！ という気持ちが伝われば幸いです。
結局のところ、何をどれだけ重視するかなので、管理方法はチームごとに異なるかなと思います。記事が、議論のきっかけになれば幸いです。
Discussion