As I understand from this bug - https://youtrack.jetbrains.com/issue/KT-43500 - it seems like IR Javascript compilation fails when dealing with any compileOnly dependency. Now that the Legacy compiler is deprecated, this would mean that compileOnly dependencies cannot be used for Javascript at all. That seems very unfortunate.

What's your use-case for such dependencies in js?

My use case is as follows: I have created a symbol processor that makes Android's Room work with Kotlin multiplatform (by generating JVM/JS code). Now I need to be able to use Androidx.room annotations on code that I want to compile on JVM/JS. So I created a module with copies of those annotations, and included it as a compileOnly dependency. If I use an implementation dependency, then I would get a duplicate class error. I think my use case is the standard use case for compileOnly: I want to compile against one implementation, but then be able to use a different implementation at runtime.

I see, I think rather than plain copying jvm room annotations, you should create a kmp module that declares expect/actual for those annotations and just typealias them to room annotations on jvm actuals. This is a solution to your immediate problem and NOT an argument against your use-case for compileOnly dependency support

Thanks, I did try going down the expect/actual path - but I hit two big problems: 1. You can't include default values in the expect declaration if you use a typealias. So that means any multiplatform code would have to explicitly specify every argument and defaults wouldn't work

Although now that I think about it, it might not be an issue with compileOnly, but rather incorrect kmp dependency module that doesn't support all required targets

2. The symbol processor (since 1.7) won't resolve expect/actual annotations by default. The annotation processor author has to do that themselves. So when Room's own annotation processor runs, it won't recognize expect/actual as the same thing

Legacy js compiler was known to be very lax when it came to enforcing kmp requirements

It definitely isn't an issue with supporting all kmp targets: I used the same code on JVM and JS

Got it, I might be wrong then

Sorry I don't understand what you mean "without declaring all target on shared that the consumer module uses?"

In order to use a kmp library, it must declare and be compiled for all the targets that your consumer uses

That is the case... they are both my projects...

For example if you have a module that declares js and jvm targets, you can only use libs in commonMain that also declare js and jvm

The module itself compiled for JS(BOTH), JVM, and Android

Regardless if the lib is remote (mavenCentral) or local (module)

But if I set the consumer to Js(IR) - then I get the same as error as mentioned on the bug report

Gotcha, ignore all I said then. Looks like your kmp setup is correct at the very least 😀

For now, I could try using exclude on gradle to try and block an implementation dependency from coming into Android

For example https://kotlinlang.slack.com/archives/C01F2HV7868/p1673905057816579?thread_ts=1673905057.816579&cid=C01F2HV7868

I really hope not - I have spent most of the days working on / trying/ thinking about ways around it.

You're not alone, lots of people have wasted days on that error

The bug report does have an attached basic reproduction case... that was done back in Kotlin 1.4 days...

Agreed, especially since IR is in beta already

Legacy is deprecated as I understand... all Kotlin/JS has to move over to IR