Version Catalogs

Un version catalog centraliza versiones y aliases de dependencias en un archivo libs.versions.toml. El beneficio no es solo estético: reduce errores de duplicación y vuelve más predecible el mantenimiento del proyecto.

[versions]
kotlin = "2.1.0"
coroutines = "1.10.1"

[libraries]
coroutines-core = { module = "org.jetbrains.kotlinx:kotlinx-coroutines-core", version.ref = "coroutines" }
dependencies {
    implementation(libs.coroutines.core)
}

Convention plugins

Cuando varios módulos comparten configuración parecida, copiar y pegar bloques Gradle es mala idea. Un convention plugin encapsula esa configuración y la vuelve reutilizable.

plugins {
    id("pensa.android.library")
    id("pensa.android.hilt")
}

Eso evita repetir compileSdk, opciones Kotlin, lint, test options o dependencias comunes en cada módulo.

Punto claveVersion Catalogs resuelven nombres y versiones. Convention plugins resuelven comportamiento y configuración compartida. Son complementarios, no rivales.

Cuándo convienen

  • Catalogs: casi siempre, incluso en proyectos medianos.
  • Convention plugins: cuando ya hay varios módulos o mucha duplicación.

Errores comunes

  • Convertir todo en alias sin criterio semántico.
  • Crear convention plugins demasiado granulares o demasiado mágicos.
  • Ocultar tanta configuración que el equipo deje de entender qué hace cada módulo.

AtenciónEl objetivo no es “usar la feature moderna de Gradle porque sí”. El objetivo es reducir ruido y dejar reglas más claras para el equipo.

Cierre

Centralizar dependencias y configuración mejora consistencia y mantenimiento. En la última lección nos concentramos en dolor real: builds lentas, cachés, flags útiles y troubleshooting de proyectos que empezaron a escalar.