Hey there; I may have found a regression in the ne...

# compose-desktop

[s3rius]

Hey there; I may have found a regression in the newest Compose but wanted to confirm that I'm onto something first. This concerns compose going from 1.4.0-alpha977 to 1.4.0-alpha1000. I noticed the following issue:

I have a desktop+android app, in commonMain I use implementation(compose.uiTooling).

In 1.4.0-alpha1000, I see the following dependency tree for my desktop variant:

+--- org.jetbrains.compose.ui:ui-tooling:1.4.0-alpha01-dev1000
| \--- org.jetbrains.compose.ui:ui-tooling-desktop:1.4.0-alpha01-dev1000
| +--- org.jetbrains.compose.ui:ui-tooling-data:1.4.0-alpha01-dev1000
| | \--- org.jetbrains.compose.ui:ui-tooling-data-desktop:1.4.0-alpha01-dev1000
| | +--- androidx.compose.runtime:runtime:1.2.1
| | | \--- org.jetbrains.kotlinx:kotlinx-coroutines-android:1.6.1 -> 1.6.4

Note the coroutines-android at the end. It seems this causes Android's MainDispatcherFactory to be present in the source, which takes precendence over Swings MainDispatcherFactory. As a result, my desktop app tries to load Androids Main Dispatcher and crashes.

In 1.4.0-alpha977 this dependency doesn't exist:

+--- org.jetbrains.compose.ui:ui-tooling:1.4.0-alpha01-dev977
| \--- org.jetbrains.compose.ui:ui-tooling-desktop:1.4.0-alpha01-dev977
| +--- org.jetbrains.compose.ui:ui-tooling-data:1.4.0-alpha01-dev977
| | \--- org.jetbrains.compose.ui:ui-tooling-data-desktop:1.4.0-alpha01-dev977
| | +--- org.jetbrains.compose.runtime:runtime:1.4.0-alpha01-dev977 (*)


Now, given that uiTooling has an explicit desktop variant it should probably be fine to use it in non-Android environments. So I'm guessing this has been a bug introduced by the recent merge of Google's Compose 1.4.0 where uiTooling doesn't depend on the correct runtime anymore?

[Igor Demin]

Thanks for letting us now. Indeed, ui-tooling shouldn't depend on Android libraries, we will fix that.

[s3rius]

Great 👍 Then I'll refrain from opening an issue.