Hi, I thought I've seen some documentations in the past where Kotlin DSL is not recommended to be used to define Binary Plugins, but I can't seem to find it anymore 🤔 Are there any concerns in using Kotlin DSL methods within Binary Plugins today?

// Without Kotlin DSL
project.tasks.named("helloWorld", HelloWorldTask::class.java)

// With Kotlin DSL
import org.gradle.kotlin.dsl.named
project.tasks.named<HelloWorldTask>("helloWorld")

I am not aware of a good technical argument for not using the Kotlin DSL extensions. IIRC one argument not to use it is that, if used outside of

gradle.kts

files, it is harder to read for non-Gradle experts. Which is maybe not a good argument for the example you shared, but some other more "magic" Gradle things.

The problem is that you compile against a version of Kotlin DSL that's provided by the version of Gradle you're using at build time, and that can be different from the version that'll be used at runtime, so you can have binary compatibility issues. But if you have functional tests against all the versions of Gradle that your plugin supports you can detect them upfront and change your code to avoid triggering them.

🤳 Shamelessly saying that if you use GradleTest you can easily test your Kotlin-based plugin against a large range of versions.