:wave: Hi Everyone! For a project with multiple Gradle modules, what would be the risks of using mos...

# compiler

[David Coronel]

👋 Hi Everyone!
For a project with multiple Gradle modules, what would be the risks of using most of the Gradle modules built using

languageVersion.set(KotlinVersion.KOTLIN_1_9)
    apiVersion.set(KotlinVersion.KOTLIN_1_9)
(This is because of some of them use Anvil, and it does not support K2)

and a single one built using

languageVersion.set(KotlinVersion.KOTLIN_2_1)
    apiVersion.set(KotlinVersion.KOTLIN_2_1)

Would it generate runtime errors? - because we are not seeing compilation errors

[trevjones]

as long as it is the 2.1 consuming 1.9 I'd expect it to work. but the otherway around it should spit out compile errors

[David Coronel]

We thought that would be the scenario, but we are building modules with Kotlin 1.9 that depend on the module built with Kotlin 2.1, and they compile for Debug and Release successfully.
Would it be related that the module built using Kotlin 2.1 is pure vanilla Kotlin (no coroutines, no Opt-In usages)? - Mostly containing data classes and higher-order functions

[trevjones]

metadata is usually the thing that blows it up. this smells like you are probably building with 2.1 but it just targets 1.9

possibly means it can work?

[David Coronel]

oh, that might be it

[David Coronel]

How can I double-check that?

[trevjones]

are you using two versions of the gradle plugin? I would expect that to explode the build too

[David Coronel]

nope, only one for all the modules of the project

[trevjones]

inspect the compiled output of the 1.9 module to see what is in the metadata annotations it attaches to the classes

[trevjones]

pretty sure that is how they check for versions in downstream builds

[trevjones]

but if you only have 2.1 plugin I am betting it is still spitting out 2.1 outputs but just limiting compiler behavior to 1.9 features

[David Coronel]

Ok, I'll check it, thanks Trevor!