In a compose multiplatform project, how safe is it...

# compose

[Zoltan Demant]

In a compose multiplatform project, how safe is it to override the M3 version for Android to be the latest instead of what jetbrains compose brings in? Im trying to work around the issue with loaders just crashing in the latest bom release, and this seems to work?

[Zoltan Demant]

kotlin {
    sourceSets.commonMain.dependencies {
        // Brings in M3 from BOM, where loaders crash :(
        implementation(compose.material3) 
    }

    sourceSets.androidMain.dependencies {
        // This.. works?
        implementation("androidx.compose.material3:material3:1.2.0-rc01")
    }
}

I guess Id run into binary compatibility issues (if any...) by doing this?

[Joel Denke]

Depending which targets you use, I think could for safety split each targets deps block explicit instead of commonMain. Or override by version in Gradle.
Not 100% sure how Compose plugin transforms these deps from compose.material.
At least in Android should be fine, did similar earlier. Just be sure that also compliant with other compose versions, like animation, foundation etc that M3 using.

[Zoltan Demant]

Do they transform them at all, or do they just bring them in as dependencies? I thought that the compose.material3 syntax was their way of uniting the dependencies between platforms .. similar to what a BOM acheives.
Am I right thinking that this will break (on Android) if theres a breaking change between releases? E.g. commonMain Text composable expects TextAlign.Unspecified, whereas that doesnt exist in M3 yet (I know this isnt the case.. just cant think of a better example 😅).

[Joel Denke]

I think they using similar approach as Toml files, in compose plugin to generate deps and versions. Just not sure when in time they do it to resolve them.
They do share same package names. Easiest is check their source of material 3 in commonMain in jetbrains core repository.

Text composable is M3 component. I guess like Basic text in foundation? But yeah thats what I meant maybe need align transitive deps in M3 not compliant with remaining. Could also mean getting different transitive deps entirely in commonMain vs androudMain.

[Joel Denke]

https://github.com/JetBrains/compose-multiplatform-core/tree/jb-main/compose%2Fmaterial3

[Joel Denke]

One example is that foundation using modified version of androidx for insets api in all targets.

[Zoltan Demant]

That makes sense, thank you 😃 If I ever need to workaround an issue like this in the future Ill make sure that it goes through the pre-release cycles so that I can catch if anything is terribly wrong!

[Enol Simón]

This last release solved the problem to me https://github.com/JetBrains/compose-multiplatform/releases/tag/v1.6.0-dev1405

[eygraber]

I had some issues in the past but I was always able to workaround them with expect/actual