Support Kotlin 2.0

[SalomonBrys]

This issue is here to discuss the path to supporting K2. It outlines the issues I've encountered as well as their possible workarounds. Feel free to enter the discussion, especially if you have any insight or wild idea ;)

MocKMP generates source code for the Test source-sets, which is not properly supported by KSP. KSP does support generating code for the commonMain sourceset, but not for the commonTest sourceset.

Up until now, we've used the following trick: register the MocKMP processor only in the kspJvmTest configuration and have the commonTest sourceset use the build/generated/ksp/jvm/jvmTest/kotlin directory. This requires some more Gradle configuration (namely having all targets compilation task to depend on kspTestKotlinJvm) but it worked allright (even though it made my heart ache).

Kotlin 2.0 brings a new issue:

e: Files '/[PROJECT]/build/generated/ksp/jvm/jvmTest/kotlin/tests/InjectionTests_injectMocks.kt', ... can be a part of only one module, but is listed as a source for both `jvmTest` and `commonTest`, please check you -Xfragment-sources options.

It looks like K2 is more restrictive than K1, and does not allow the same file to be in multiple sourcesets at once. I also haven't found a way to emulate running KSP to commonTest only, or to remove the generated/ksp/jvm/jvmTest/kotlin directory from the JVM test compilation.

I've tried another approach that consists of applying the processor to all test targets:

dependencies {
    configurations.names
        .filter { it.startsWith("ksp") && it.endsWith("Test") }
        .forEach {
            it(projects.mockmpProcessor)
        }
}

...but that brings a new issue: because K2 is also more restrictive as to which sources are accessed when compiling common code, this approach does not compile at all (yielding unresolved symbol all around errors when compiling common code).

So far, the only approach I've thought of that would (I think) resolve the issue is to follow the KotlinX.RPC & KotlinX.Serialization paths and have a Compiler plugin that adds an AssociatedObjectKey annotation to each class annotated with @Mock or @Fake. This cannot be done with KSP as it notoriously cannot modify the sources of the code it is processing. Such annotations allow a Native & Js code to access an object associated to a class at compile-time (it does not exist in JVM, but the JVM provides reflection so there's no need for it). This in turn allows to have a common code that does not directly reference generated code.
This is a path I'd rather not take, because:

• It requires maintaining a compiler plugin for each Kotlin compiler version (KotlinX.RPC maintains so far 17 artifacts for each version, corresponding to 17 different Kotlin compiler version).
• It requires maintaining code that uses undocumented and unsupported Kotlin compiler API, which can break at anytime.
• It bundles MocKMP to each specific supported version of the Kotlin compiler and requires a level of reactivity and investment at each minor Kotlin update that I cannot provide as an Open-Source library author (without patron or revenue source related to my Open-Source work).

MocKMP is now at a crossroad as I have found, at the moment, no satisfactory path to have it compatible with K2.
Let's keep looking!
Make sure to share any idea or knowledge I've missed ;)

[GoodSir42]

Thanks for the detailed explanation of the problem. Even if I am pretty sure that I am only beginning to understand the basic setup maybe we can exchange a few thoughts here. If I understand the KSP docs here correctly there seems to be a kspTest task for multiplatform. Could we maybe hook into that? Also: Did you already investigate whether KSP 2.0 might or might not have an impact or helpful changes for the issue? I am struggling with finding specific information about it.

[SalomonBrys]

There's no kspTest in a Kotlin/Multiplatform project.
Here are the available configurations on my mac:

kspCommonMainMetadata
kspIosSimulatorArm64
kspIosSimulatorArm64Test
kspIosX64
kspIosX64Test
kspJs
kspJsTest
kspJvm
kspJvmTest
kspLinuxX64
kspLinuxX64Test
kspMacosArm64
kspMacosArm64Test
kspMacosX64
kspMacosX64Test
kspMingwX64
kspMingwX64Test
kspTvosSimulatorArm64
kspTvosSimulatorArm64Test
kspTvosX64
kspTvosX64Test
kspWatchosSimulatorArm64
kspWatchosSimulatorArm64Test
kspWatchosX64
kspWatchosX64Test

As I've explained applying KSP to each test sourceset does not work because of K2 Common / Target sourceset separation.

[GoodSir42]

Thanks for the explanation! So it looks like the issue here is really just that KSP runs for anything except commonTest if I see it well. Does this mean we could generate files for jvm test for example and run the tests there? I know it is not the goal of a multiplatform library to limit tests to the different sub packages, I am just trying to understand the underlying issue. In the meantime I will add my vote to the KSP issue and ask the ksp team to shed a light on why they seem to exclude commonTest explicitly.

Edit: would it be possible to move the generated code from one folder to the other in the generation step? I know this is hacky but it might keep the project running until the underlying issues in KSP are resolved/KSP is extended

[GrayaMax]

Hello, i get the same issue, i choose to stay on ksp 1.9.24-1.0.20 for now instead removing MocKMP usage.
But has a workaround been found ? Or should i remove MockMP usage ?

[vijimani17]

Any solutions please , we are blocked due to this issue since we would like to migrate to kotlin 2.0

[SalomonBrys]

Hi guys.
I'm still working on this.
To be honest, this feels very problematic. I do understand the frustration, but this is a very hard issue.
I'll keep working on this for a bit, but eventually, I'll either need to find a solution or to deprecate the lib.

[SalomonBrys]

Good news : I found a way to make MocKMP work with Kotlin 2 !
It will be however through a breaking change, but the migration is quite simple.
I still need to soften some rough edges, but you can expect MocKMP 2.0 in a week or two max.

I should add that this new mechanism does NOT use weird sourceset tricks, so it should be much more future-proof than the current version 😄

[SalomonBrys]

Here we are: MocKMP 2.0 has been released to Maven Central and to the Gradle plugin portal.

Migration guide

I truly apologize for the time it took me to port MocKMP to Kotlin 2.0. All I can say for my defense is that:

• MocKMP 2.0 represents a considerable change in how it is applied to a project. It took me a lot of time to find a satisfactory way, and it meant a full re-write of the Gradle plugin, as well as an extension of the Kotlin Symbol Processor.
• MocKMP, just like every other KOSI libraries, is freely maintained outside of any paid mission, and I've been quite busy lately. Having a kid changes your priorities...

The way MocKMP 2.0 is implemented is now much more robust and future-ready than version 1.x (at least, I think so, but I do not live in the future). I am quite satisfied at where the project is and I hope it will be less of a hassle to maintain for the coming Kotlin releases.