After update to 1.6.0-rc02 `compileCommonMainKotlinMetadata` fails with "Unresolved reference: launch" on `CoroutineScope#launch`
Describe the bug
I'm not sure if this is actually a bug or not. My module with Compose code doesn't have direct dependency on kotlinx-coroutines, as the dependency has been used to be exposed as api from Compose. As I have been able to use coroutines without adding the dependency explicitly. But after updating Compose from 1.6.0-alpha01 to 1.6.0-rc02, kotlinx.coroutines imports are unresolved and compileCommonMainKotlinMetadata task fails. Though, tasks like jvmJar, assembleDebug, jsJar, etc. - all work fine.
Affected platforms
Select one of the platforms below:
- Common
Versions
- Kotlin version*: 1.9.21, 1.9.22
- Compose Multiplatform version*: 1.6.0-rc02
- OS version(s)* (required for Desktop and iOS issues): macOS 13.5.2 (22G91)
- OS architecture (x86 or arm64): arm64
- JDK (for desktop issues): jbr-17
To Reproduce
Don't add kotlinx-coroutines dependency to a module with Compose.
Code:
import kotlinx.coroutines.launch
Run: ./gradlew compileCommonMainKotlinMetadata
Error:
> Task :extensions-compose:compileCommonMainKotlinMetadata FAILED
e: file:///....... Unresolved reference: coroutines
I'm also not able to use rememberCoroutineScope, the error is:
> Task :extensions-compose:compileCommonMainKotlinMetadata FAILED
e: file:///........ Cannot access class 'kotlinx.coroutines.CoroutineScope'. Check your module classpath for missing or conflicting dependencies
Expected behavior
I think it should work work fine without adding kotlinx-coroutines explicitly, but I might be wrong.
Do you have wasmJs target? What if you try to disable it? Do you have a link to such project?
Same happened after upgrading coroutines to 1.8.0 in other modules. Coroutines symbols such as TimeoutCancellationException became unresolved in modules with compose and without coroutines declared explicitly. wasmJs enabled. With coroutines 1.8.0-RC2 + compose 1.6.0-rc02 everything worked well.
@alexzhirkevich is your project available on GitHub? Could you please share the link and the branch?
It's not, but i'll try to create a smal reproducer. I guess if you'll update coroutines to 1.8.0, everything should be fine
Yes I have wasmJs target. You can try this branch in Decompose: https://github.com/arkivanov/Decompose/tree/v3.0
If you remove coroutines deps here and here, then it should start failing again.
Thanks! Reproduced it in Decompose. But having troubles to reproduce it is a separate simple project.
I thought it's somehow caused by web targets. But if I remove only an android target and keep the rest enabled, then it works. Or if I keep only android and jvm targets then it works too, but breaks if I add any web or native target. So android + native/web doesnt' work.
removing implementation(deps.jetbrains.kotlinx.kotlinxCoroutinesSwing) helps too.
It's surprising to me, since it's added only in the test source set, which shouldn't be involved in commonMainMedatada compilation (afaiu).
Continue investigation...
@alexzhirkevich Does adding implementation(deps.jetbrains.kotlinx.kotlinxCoroutinesCore) explicitly (either to commonMain or androidMain) help in your case too?
Yep
@eymar One more reproducer if needed
git clone https://github.com/alexzhirkevich/compose-4326 & cd compose-4326 & ./gradlew core:compileCommonMainKotlinMetadata
There are 2 dependencies in commonTest including coroutines.test. If you remove them or change coroutines from 1.8.0 to 1.8.0-RC2 in toml everything works fine wtf :D.
Thanks everyone for reproducers! The issue is reported to kotlin - https://youtrack.jetbrains.com/issue/KT-65954
In compose multiplatform 1.6.0 we won't update coroutines versions. Because it's already rc2 and updating a dependency is not desirable. We'll do that in 1.6.1.
For 1.6.0 and if such an issue arises, we'll advise to use the workaround with adding an explicit dependency to coroutines-core in commoMain.
Thank you very much for reporting this. It discovers an awful flaw in our dependency resolution mechanism. We are targeting a fix for this in 1.9.23
Seems working with Kotlin 2.0.10. Thanks!