Do you feel that task configuration avoidance is intuitive?

Help/Discuss
1

Hi all,

I was bitten by some code here:

tasks.withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompile>() {
        kotlinOptions {
            freeCompilerArgs += "-Xjvm-default=all"
        }
    }

This code created all tasks in configuration time but this code was fine

tasks.withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompile>().configureEach {
        kotlinOptions {
            freeCompilerArgs += "-Xjvm-default=all"
        }
    }

I know how to find such stuff. I remove all custom code from a build.gradle.kts file and after i add a certain feature i run scan and find what i screw up.

But now my question is: Could the api maybe more intuitive? Could somehow a warning be issued of some type. May it be a deprecation warning or a lint warning. Or is the API like this for a reason and it is part of a learning curve which every intermediate gradle user has to go through ?

What are your thoughts ?

Thanks

2 Likes
2

I think configureEach is introduced for backward compatibility.

It is our burden (of ordinary devs) to convert legacy code to a new world.

May it be a deprecation warning or a lint warning.

Iā€™d like to hear any options to find problems proactively.

1 Like