Version Catalogを使ってみましょう

💡はじめに

こんにちは。ニフティ株式会社のLinです。
台湾出身のモバイルアプリエンジニアとして、社内で「マイ ニフティ」のAndroidおよびiOS版の開発を担当しております。
今回は、マイニフティ Android 2.0.4 で導入した、Gradle の Groovy DSL → Kotlin DSL → Version Catalog への移行をご紹介します。

🐘 Gradleの進化

Gradleは、Androidアプリの構築とビルドを管理するビルドシステムで、下記の機能があります：

• プロジェクトの構成管理
• ライブラリの依存関係管理
• リソースファイルの管理
• プロダクションビルド、デバッグビルドの切り替え
• APKファイルのビルド

マスコットはGradle君という名前の可愛い象です。

Android 開発における Gradle Script の記述方法には、Groovy DSL と Kotlin DSL の2つのパターンがあります。
Groovy DSL は従来からよく使われている記法で、シングルクォーテーションと括弧なしのダブルクォーテーションが特徴的です。

そして、2020年4月の Android Gradle Plugin 4.0.0 から、Kotlin DSL が導入されました。
括弧付きのダブルクォーテーションが特徴で、静的型付けによる型安全などのメリットがあります。

しかし、Android の発展に伴い、Gradle の既存機能にはいくつかの課題がありました：

• 異なる記法がbuild.gradleファイルに混在しており、保守運用がやや複雑になってしまっている
• マルチモジュールの場合、複数のbuild.gradleに重複するコードを記述しなければならない
• バージョンアップする際に、変更箇所が散在してしまう

どうしよう…

Gradle君の悩みはどんどん大きくなった。

🧩 課題解決

課題解決のため、Gradle君はライブラリバージョン管理の改善を試し、二つ改善方法を見つけました：

• BuildSrc
  
  • buildSrc/build.gradleに共通の部分を集約することができ、その中身は以前の build.gradle と同様の書き方です
  • どのGradleバージョンにも使えます
  • ただし、下記理由のため、一時対策として使われています
    • 機能ごとの複数の依存関係をまとめるのは手間がかかります
    • pluginsの集約はできません
    • モジュール間のコンフリクトを完全に避けるのは難しい
    • 拡張性に制限があります

• Version Catalog
  
  • libs.versions.tomlに共通のバージョン、依存関係、プラグインを集約することができ、その中身は以前の build.gradle とは異なります
  • Gradle 7.4以上で導入された機能のため、バージョン制限があります
    • Gradle 7.0 – 7.4 では Feature Preview、Gradle 7.0 以下では使えません
  • 下記理由のため、恒久対策として使われています
    • 機能ごとの複数の依存関係をまとめることができます
      • [bundles]
    • pluginsの集約もできます
      • [plugins]
    • Kotlin DSLのみで記述できるため、型安全などの利点があります
    • Android Studioの新規プロジェクトでもVersion Catalogがデフォルトになったため、これからも業界の標準となっていくでしょう

では、Gradle君と一緒にVersion Catalogを使ってみよう！

💻 Groovy DSL → Kotlin DSL → Version Catalog

移行作業には以下の2つのステップがあります：

• Kotlin DSLへの移行
  • 下記ファイルの書き換え
    • settings.gradle → settings.gradle.kts
      • Groovy DSL → Kotlin DSL
        include ':app'
        ↓
        include(":app")
      • pluginManagementの追加
        
      • @Incubatingの警告が出る場合は、@file:Suppress("UnstableApiUsage")も追加してください
    • build.gradle(Project層) → build.gradle.kts(Project層)
      • Groovy DSL → Kotlin DSL
        kotlin_version = '1.9.23'
        ↓
        val kotlinVersion: String by extra("1.9.23")
    • build.gradle(Module層) → build.gradle.kts(Module層)
      • Groovy DSL → Kotlin DSL
      • buildConfigの移行（AGP 9.0で廃止予定）
        
• Version Catalogへの移行
  
  • [versions]：すべてのライブラリのバージョンを集約します
    • 定義した変数はversion.refで使用されます
  • [libraries]：すべてのライブラリのパスを集約します
    • module (group:name) より group + name の方がおすすめです
      library = { module = "... : ...", version.ref = "..." }
      ↓
      library = { group = "...", name = "...", version.ref = "..." }
    • BOMの集約もできます
  • [bundles]：機能ごとの複数のライブラリをまとめます
    • [libraries] で定義したライブラリの変数名を、[bundles] ごとにまとめます
  • [plugins]：pluginsのclasspathとidを集約します
    • [plugins] で定義したものは、build.gradleのpluginsブロックでalias(...)で呼び出せます
    • 例：Compose Compilerの移行
      – libs.versions.toml
      
      – build.gradle.kts（Project層）
      
      – build.gradle.kts（Module層）
      

[bundles]を活用すれば、必要な依存関係を1回のimplementationで一括して指定できます。

そして、移行作業が完了したら、Gradle Syncを忘れずに行いましょう。

💫 成果

これまでは各 Gradle ファイルに散在していたライブラリバージョン情報は、下記のようにVersion Catalogに集約しました：

今後は Version Catalog の [versions] セクションにバージョン情報を集約しているため、ライブラリのアップデートと管理がより簡単になりました。

ぜひ Version Catalog の便利さを体験してみましょう！