<https://twitter.com/GakisStylianos/status/1657087...

# confetti

[John O'Reilly]

https://twitter.com/GakisStylianos/status/1657087608462123008?s=20

@Stylianos Gakis have you come across any ways to address that.....seems like would be common issue in KMP projects?

[Stylianos Gakis]

Hmm, well one thing I try to do in my work project is that if a class comes from GQL, aka from that module, I make sure to map it to some local type which is part of that feature module, which does have compose compiler applied. Now the thing is, that we don’t have any multiplatform modules in that repo, so it’s easier to not have to deal with this issue.

Now for the Confetti case (or any module really), I do actually wonder if it’s worth it to just apply the compose compiler plugin to that module, without even using it in any other way, just to get some freebies regarding stability in classes there. Would really love to hear from someone else who might have tried that before.

[John O'Reilly]

definitely worth trying

[Stylianos Gakis]

Yeah, it’d have to be the multiplatform version of the compiler from JetBrains, but I assume they’re using the same classification of what’s stable and what’s not, and that should carry over? Maybe? 😅 Please do let me know if you try

[Marcello Galhardo]

Out of curiosity: what happens if you apply the androidx.compose to the android/jvm source set of the multiplatform module? Due to how KMM compilation works, won't that ensure all classes are correctly covered?

[John O'Reilly]

I did quick test to include following in android section in shared build file but still behaving same way

buildFeatures {
        compose = true
        buildConfig = true
    }

    composeOptions {
        kotlinCompilerExtensionVersion = libs.versions.compose.compiler.get()
    }