Gradle KTS — qu'est-ce que c'est, Kotlin DSL pour Gradle et syntaxe

Qu'est-ce que Gradle KTS ?

Gradle KTS est un DSL Kotlin (Domain Specific Language) qui offre une alternative à Groovy pour écrire des fichiers de configuration Gradle. Au lieu de la syntaxe Groovy, les développeurs utilisent Kotlin — un langage strictement typé qui vérifie la correction de la configuration au moment de la compilation. KTS a été introduit pour la première fois dans Gradle 5.0 en 2018 en tant que fonctionnalité expérimentale et a atteint la stabilité dans Gradle 6.0.

L'objectif principal de KTS est d'éliminer les lacunes de Groovy dans les scripts de build. Groovy est un langage au typage dynamique où les erreurs de configuration n'apparaissent qu'à l'exécution lors de l'exécution d'une tâche. KTS permet de détecter les mêmes erreurs dès l'étape d'édition du code grâce au typage statique de Kotlin. De plus, KTS fournit un accès à l'API Gradle avec une documentation complète des types, ce qui simplifie considérablement l'apprentissage et l'utilisation de blocs de configuration complexes.

L'écosystème KTS est pris en charge par tous les outils principaux : Android Studio, IntelliJ IDEA, VS Code avec le plugin Kotlin et Gradle Build Tool. Tous les plugins modernes (Android Gradle Plugin, Kotlin Multiplatform, Protobuf, Compose) fournissent une API compatible Kotlin avec des types explicites, faisant de KTS le choix préféré pour les nouveaux projets.

Comment fonctionne Gradle KTS

Gradle KTS utilise le compilateur Kotlin pour traiter les fichiers .gradle.kts. Gradle reconnaît l'extension et transmet les scripts au moteur de script Kotlin, qui les compile en classes. Ces classes sont ensuite exécutées par Gradle pour construire le modèle du projet. La principale différence avec Groovy : les scripts KTS sont compilés à l'avance, pas interprétés dynamiquement, ce qui permet de détecter les erreurs avant le début de l'exécution des tâches.

L'architecture KTS est basée sur kotlin-scripting. Chaque fichier .gradle.kts est un script Kotlin avec des importations implicites de l'API Gradle. Le développeur peut utiliser n'importe quelle construction Kotlin : fonctions d'extension, lambdas, classes de données et même déclarer des fonctions auxiliaires à l'intérieur du script de build. Gradle fournit un ensemble de fonctions d'extension pour la configuration typée des blocs : dependencies, android, kotlin et autres.

plugins {
    id("com.android.application") version "8.4.0"
    kotlin("android") version "2.0.21"
}

android {
    namespace = "com.itsectr.app"
    compileSdk = 34

    defaultConfig {
        applicationId = "com.itsectr.app"
        minSdk = 26
        targetSdk = 34
        versionCode = 1
        versionName = "1.0.0"
    }
}

dependencies {
    implementation(platform("androidx.compose:compose-bom:2024.06.00"))
    implementation("androidx.compose.ui:ui")
    implementation("androidx.core:core-ktx:1.13.1")
}

Conversion de types dans KTS

L'une des principales différences entre KTS et Groovy est la gestion des types. Dans Groovy, toutes les configurations acceptent Object, tandis que dans KTS, elles acceptent des types Kotlin spécifiques. Par exemple, compileSdk accepte Int, pas une chaîne. Cela élimine les erreurs liées à des types incorrects : dans Groovy, compileSdk 34 et compileSdk "34" fonctionnent de manière identique, tandis que dans KTS, seule la première variante est valide. Cette rigueur rend la configuration plus prévisible et documentée.

Gradle KTS vs Groovy : comparaison

Groovy était le DSL d'origine pour Gradle et reste pleinement pris en charge. Cependant, KTS offre plusieurs avantages qui en font le choix recommandé pour les nouveaux projets. Le typage statique, de meilleures performances d'édition dans l'IDE et une syntaxe plus stricte sont les principales raisons de passer à KTS. Dans le même temps, Groovy conserve son avantage de concision pour les configurations simples.

Les performances de construction sur KTS et Groovy sont presque identiques après la compilation des scripts. Les scripts KTS mettent plus de temps à compiler lors du premier lancement ou après avoir vidé le cache, mais les constructions suivantes s'exécutent à la même vitesse que les scripts Groovy. Gradle met en cache les scripts KTS compilés dans le répertoire de build, donc la recompilation n'a lieu que lorsque le script change.

Le choix entre KTS et Groovy en 2026 est clair : pour les nouveaux projets — KTS. Google, JetBrains et Gradle recommandent KTS pour tous les nouveaux projets. Groovy reste pertinent pour la maintenance de projets legacy où la migration est peu pratique en raison du volume de configuration ou de plugins spécifiques incompatibles avec KTS.

Exemples de code : scripts de build en KTS

Examinons les blocs de configuration typiques en KTS pour Android, Kotlin Multiplatform et Compose Multiplatform. Un projet Android avec KTS nécessite une spécification explicite des types dans la configuration de buildTypes et productFlavors. L'exemple ci-dessous montre la configuration d'une application avec deux variantes.

android {
    buildTypes {
        val release = getByName("release") {
            isMinifyEnabled = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
        getByName("debug") {
            applicationIdSuffix = ".debug"
        }
    }

    flavorDimensions += "version"
    productFlavors {
        register("demo") {
            dimension = "version"
            versionNameSuffix = "-demo"
        }
        register("full") {
            dimension = "version"
        }
    }
}

Pour Kotlin Multiplatform, KTS est obligatoire — Groovy ne prend pas correctement en charge la configuration des modules multiplateformes. La configuration du module KMM comprend la configuration des plateformes cibles et des source sets. L'exemple ci-dessous montre la configuration du module partagé avec iOS et Android.

kotlin {
    androidTarget {
        compilations.all {
            kotlinOptions {
                jvmTarget = "17"
            }
        }
    }

    listOf(
        iosX64(),
        iosArm64(),
        iosSimulatorArm64()
    ).forEach { iosTarget ->
        iosTarget.binaries.framework {
            baseName = "Shared"
            isStatic = true
        }
    }

    sourceSets {
        commonMain.dependencies {
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.9.0")
        }
        androidMain.dependencies {
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-android:1.9.0")
        }
    }
}

Fonctions auxiliaires et tâches personnalisées

KTS permet de déclarer des fonctions Kotlin auxiliaires à l'intérieur du script de build. C'est particulièrement pratique pour les configurations répétitives telles que les configurations de signature ou la gestion des versions. Grâce au typage statique, ces fonctions peuvent être appelées avec validation des paramètres au moment de la compilation, éliminant ainsi les erreurs dans les configurations de signature avant la publication sur Google Play.

fun Project.configureSigning() {
    android {
        signingConfigs {
            register("release") {
                storeFile = file("release.keystore")
                storePassword = System.getenv("KEYSTORE_PASSWORD")
                keyAlias = System.getenv("KEY_ALIAS")
                keyPassword = System.getenv("KEY_PASSWORD")
            }
        }
    }
}

// Utilisation dans build.gradle.kts
configureSigning()

Migration de Groovy vers KTS

La migration de Groovy vers KTS est un processus qui peut être effectué progressivement. Gradle prend en charge les projets mixtes où certains modules utilisent Groovy (build.gradle) et d'autres KTS (build.gradle.kts). Le settings.gradle et le build.gradle racine peuvent être migrés en premier car ils ne dépendent pas des plugins des modules. Google recommande de commencer la migration par settings.gradle.kts, puis le build.gradle.kts racine, et ensuite seulement les modules.

Les principales étapes de migration comprennent : remplacer la syntaxe des closures par des lambdas, ajouter des signes = pour l'affectation, remplacer les clés chaîne par des constantes typées et le typage explicite des variables. Android Studio fournit une conversion automatique Groovy → KTS pour les blocs simples, mais les configurations complexes avec des closures imbriquées nécessitent une réécriture manuelle.

Les problèmes typiques de migration incluent les appels implicites de méthodes Groovy qui n'ont pas d'équivalent Kotlin, et les plugins qui ne fournissent pas d'API compatible Kotlin. Pour le premier problème, Gradle offre une compatibilité via withGroovyBuilder — un mécanisme qui permet d'appeler des méthodes Groovy depuis KTS. Pour le second — il faut attendre une mise à jour du plugin ou l'utiliser dans un module Groovy jusqu'à la migration complète.

Gradle KTS pour Kotlin Multiplatform

Kotlin Multiplatform est le projet principal où KTS est une exigence obligatoire. Le plugin kotlin multiplatform fournit des extensions pour configurer les plateformes cibles, les source sets et les binaires de framework qui ne sont disponibles que via Kotlin DSL. Groovy ne prend pas correctement en charge la configuration multiplateforme, donc les projets KMM utilisent exclusivement KTS.

La configuration KMM dans KTS comprend des blocs non standard : kotlin.target pour spécifier les plateformes, kotlin.sourceSets pour organiser le code commun et spécifique à la plateforme, kotlin.cocoapods pour l'intégration avec CocoaPods et kotlin.jvmToolchain pour la sélection du JDK. Chaque bloc dispose d'une API strictement typée avec autocomplétion dans Android Studio, ce qui est particulièrement précieux pour la configuration complexe de projets KMM avec plusieurs plateformes.

kotlin {
    iosArm64()
    iosSimulatorArm64()
    iosX64()

    cocoapods {
        summary = "Shared Kotlin module"
        homepage = "https://itsectr.com"
        framework {
            baseName = "Shared"
            isStatic = false
        }
        pod("Alamofire") {
            version = "5.9"
        }
    }
}

Grâce au typage statique de KTS, les développeurs KMM bénéficient de l'autocomplétion pour les source sets et les dépendances, de la vérification de type de la configuration du framework et de la possibilité de refactoriser les noms de plateformes. KTS simplifie également le débogage : les erreurs dans la configuration KMM apparaissent comme des erreurs de compilation Kotlin avec des messages clairs, contrairement à Groovy où les erreurs pouvaient rester cachées jusqu'à l'exécution d'une tâche Gradle.