Xposting from the Gradle Slack because I'm not sur...

# gradle

[eygraber]

Xposting from the Gradle Slack because I'm not sure whether it's a Gradle or Kotlin solution

I'd like add "-Xopt-in=kotlinx.coroutines.ExperimentalCoroutinesApi" to the compiler args for every module I have that uses coroutines in a precompiled script plugin, but I don't want to manually list out all of the modules, nor do I want to do it specifically for each module.

Not all of the modules depend on the coroutines library, so I can't add that opt in to all modules.

My current solution is to call this for each module, and if it depends on coroutines I add the opt in:

fun Project.containsDependency(name: String) =
   configurations
     .named("implementation")
     .get()
     .dependencies
     .any { dependency -> name in dependency.name } ||
     project
       .configurations
       .named("api")
       .get()
       .dependencies
       .any { dependency -> name in dependency.name }

I really don't like this approach. Is there a better one?

[ephemient]

that seems like a strange condition… what about modules that get coroutines transitively?

[ephemient]

also adding the opt-in to modules that don't use coroutines shouldn't cause any issues

[eygraber]

I have a module that I use to wrap coroutines, so I look to see if that module is a dependency.

The error I get is that the opt in can't be resolved. I'll post it here when I get a chance to try again.

[eygraber]

w: Opt-in requirement marker kotlinx.coroutines.ExperimentalCoroutinesApi is unresolved. Please make sure it's present in the module dependencies
w: Opt-in requirement marker kotlinx.coroutines.FlowPreview is unresolved. Please make sure it's present in the module dependencies
e: warnings found and -Werror specified

[ephemient]

oh that's a -Werror issue. dunno, don't use that

[eygraber]

That's not an option for me. I've filed https://youtrack.jetbrains.com/issue/KT-48419, thanks.

[ephemient]

oh I see how you may have read that. "I dunno, i don't use it" is what I meant.
although given the current lack of control around which warnings to promote to errors, I personally don't think -Werror is appropriate in a large codebase. it's something that I think the compiler should have, but until then, you can use Gradle features to watch task output and force failure on certain patterns instead of -Werror

[ephemient]

looking into it, doesn't seem as isolated as one could hope for given the API design: https://github.com/gradle/gradle/issues/6068
but if you're applying the same checks globally to your project that shouldn't matter

[eygraber]

Ah gotcha, yeah that's how I read it.

I've had -Werror enabled for years. I'll occasionally run into an issue like this, but other than that it's been great.