Gradle KTS — vad är det, Kotlin DSL för Gradle och syntax

Vad är Gradle KTS?

Gradle KTS — är Kotlin DSL (Domain Specific Language), som utgör ett alternativ till Groovy för att skriva Gradle-konfigurationsfiler. Istället för Groovy-syntax använder utvecklare Kotlin — ett starkt typat språk som kontrollerar konfigurationens korrekthet vid kompilering. KTS introducerades första gången i Gradle 5.0 2018 som en experimentell funktion och nådde stabilitet i Gradle 6.0.

Huvudmålet med KTS är att eliminera bristerna hos Groovy i byggskript. Groovy — ett dynamiskt typat språk där konfigurationsfel bara uppträder vid körning när en uppgift utförs. KTS gör det möjligt att upptäcka samma fel vid kodredigering tack vare Kotlins statiska typning. Dessutom ger KTS tillgång till Gradles API med fullständig typdokumentation, vilket avsevärt förenklar inlärning och användning av komplexa konfigurationsblock.

KTS-ekosystemet stöds av alla viktiga verktyg: Android Studio, IntelliJ IDEA, VS Code med Kotlin-plugin och Gradle Build Tool. Alla moderna plugins (Android Gradle Plugin, Kotlin Multiplatform, Protobuf, Compose) tillhandahåller ett Kotlin-vänligt API med explicita typer, vilket gör KTS till det självklara valet för nya projekt.

Hur Gradle KTS fungerar

Gradle KTS använder Kotlin-kompilatorn för att bearbeta .gradle.kts-filer. Gradle känner igen tillägget och skickar skripten till Kotlin-skriptmotorn, som kompilerar dem till klasser. Dessa klasser exekveras sedan av Gradle för att bygga projektmodellen. Den viktigaste skillnaden från Groovy: KTS-skript kompileras i förväg, inte dynamiskt tolkade, vilket gör det möjligt att upptäcka fel innan uppgifterna börjar utföras.

KTS-arkitekturen är baserad på kotlin-scripting. Varje .gradle.kts-fil är ett Kotlin-skript med implicita importer av Gradles API. Utvecklaren kan använda alla Kotlin-konstruktioner: tilläggsfunktioner, lambdas, dataklasser och till och med deklarera hjälpfunktioner i byggskriptet. Gradle tillhandahåller en uppsättning tilläggsfunktioner för typad konfiguration av block: dependencies, android, kotlin och andra.

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")
}

Typkonvertering i KTS

En av de viktigaste skillnaderna mellan KTS och Groovy är arbetet med typer. I Groovy accepterar alla konfigurationer Object, i KTS — specifika Kotlin-typer. Till exempel accepterar compileSdk Int, inte en sträng. Detta eliminerar fel relaterade till felaktig typ: i Groovy fungerar compileSdk 34 och compileSdk “34” på samma sätt, i KTS bara den första varianten. Sådan noggrannhet gör konfigurationen mer förutsägbar och väldokumenterad.

Gradle KTS vs Groovy: jämförelse

Groovy var den ursprungliga DSL för Gradle och förblir fullt stödd. KTS erbjuder dock en rad fördelar som gör den rekommenderad för nya projekt. Statisk typning, bättre redigeringsprestanda i IDE och striktare syntax — de främsta skälen att byta till KTS. Samtidigt behåller Groovy fördelen av koncishet för enkla konfigurationer.

Byggprestanda på KTS och Groovy är praktiskt taget identisk efter kompilering av skripten. KTS-skript kompileras längre vid första start eller efter rensning av cache, men efterföljande byggen fungerar med samma hastighet som Groovy-skript. Gradle cachar kompilerade KTS-skript i build-katalogen, så omkompilering sker bara när skriptet ändras.

Valet mellan KTS och Groovy 2026 är uppenbart: för nya projekt — KTS. Google, JetBrains och Gradle rekommenderar KTS för alla nya projekt. Groovy förblir relevant för stöd av äldre projekt där migrering inte är ändamålsenlig på grund av konfigurationsmängden eller specifika plugins som inte är kompatibla med KTS.

Kodexempel: byggskript i KTS

Låt oss titta på typiska konfigurationsblock i KTS för Android, Kotlin Multiplatform och Compose Multiplatform. Android-projekt med KTS kräver explicit angivelse av typer i konfigurationen av buildTypes och productFlavors. Exemplet nedan visar konfigurationen av en app med två flavours.

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"
        }
    }
}

För Kotlin Multiplatform är KTS obligatoriskt — Groovy stöder inte korrekt konfiguration av flerplattformsmoduler. Konfigurationen av en KMM-modul innefattar inställning av målplattformar och source sets. Exemplet nedan visar konfigurationen av en shared-modul med iOS och 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")
        }
    }
}

Hjälpfunktioner och anpassade uppgifter

KTS tillåter deklaration av hjälpfunktioner i Kotlin i byggskriptet. Detta är särskilt praktiskt för återkommande konfigurationer som signing configs eller versionshantering. Tack vare statisk typning kan sådana funktioner anropas med parameterkontroll vid kompilering, vilket eliminerar fel i signing-konfigurationer före publicering till 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")
            }
        }
    }
}

// Användning i build.gradle.kts
configureSigning()

Migrering från Groovy till KTS

Migrering från Groovy till KTS — en process som kan utföras stegvis. Gradle stöder blandade projekt där en del av modulerna använder Groovy (build.gradle) och en del använder KTS (build.gradle.kts). settings.gradle och root build.gradle kan konverteras först eftersom de inte är beroende av modulernas plugins. Google rekommenderar att börja migreringen med settings.gradle.kts, därefter root build.gradle.kts, och först därefter modulerna.

De viktigaste migreringsstegen innefattar: ersättning av closure-syntax med lambdas, tillägg av = för tilldelning, ersättning av strängnycklar med typade konstanter och explicit typning av variabler. Android Studio tillhandahåller automatisk konvertering från Groovy till KTS för enkla block, men komplexa konfigurationer med nästlade closures kräver manuell omskrivning.

Typiska problem vid migrering inkluderar implicita anrop av Groovy-metoder som saknar Kotlin-motsvarighet och plugins som inte tillhandahåller ett Kotlin-vänligt API. För att lösa det första problemet tillhandahåller Gradle kompatibilitet via withGroovyBuilder — en mekanism som gör det möjligt att anropa Groovy-metoder från KTS. För det andra — vänta på en plugin-uppdatering eller använd den i Groovy-modulen tills full migrering.

Gradle KTS för Kotlin Multiplatform

Kotlin Multiplatform — det huvudsakliga projektet där KTS är ett obligatoriskt krav. Pluginen kotlin multiplatform tillhandahåller tillägg för konfiguration av målplattformar, source sets och framework-binärer som endast är tillgängliga via Kotlin DSL. Groovy stöder inte korrekt flerplattformskonfiguration, därför använder KMM-projekt uteslutande KTS.

KMM-konfiguration i KTS inkluderar icke-standardiserade block: kotlin.target för att ange plattformar, kotlin.sourceSets för att organisera gemensam och plattformsspecifik kod, kotlin.cocoapods för integration med CocoaPods och kotlin.jvmToolchain för val av JDK. Varje block har ett strikt typat API med autokomplettering i Android Studio, vilket är särskilt värdefullt för komplex konfiguration av KMM-projekt med flera plattformar.

kotlin {
    iosArm64()
    iosSimulatorArm64()
    iosX64()

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

Tack vare KTS statiska typning får KMM-utvecklare autokomplettering för source sets och beroenden, typkontroll av framework-konfiguration och möjlighet till refaktorering av plattformsnamn. KTS förenklar också felsökning: fel i KMM-konfiguration visas som Kotlin-kompileringsfel med begripliga meddelanden, till skillnad från Groovy där fel kunde vara dolda tills en Gradle-uppgift kördes.