I'm playing with a project with two targets: JS an...

# webassembly

[Robert Jaros]

I'm playing with a project with two targets: JS and WasmJS. I want to use org.w3c.dom.Node in a common source set. It does compile in gradle, so I think it is correct, but the IntelliJ marks this as an error (Unresolved reference: org). Is it a known issue? Can I somehow workaround this issue?

[Robert Jaros]

Many different things from stdlib are also marked as errors in common source set (even some simple things like mutableListOf() or repeat())

[Robert Jaros]

At the same time the IDE doesn't have any problem with import androidx.compose.runtime.Composable. How it is detected?

[Justin Salér]

Sometimes my IntelliJ fails to recognize imports. I then need to invalidate cache and restart the IDE for it to work.

[Robert Jaros]

I've tried all options I know about, without success.

[Ilya Goncharov [JB]]

So the problem is that common source set is indeed common. It is common among all of possible targets, not targets inside this project.
So if you need source set for JS and wasm, now you can create separate directory and include it to JS source set and wasm source set.

[Robert Jaros]

But shouldn't IDE and gradle work the same way?

[Ilya Goncharov [JB]]

So, Gradle should work. With IDE can be a problem as I can imagine, because there are several targets think that they can use their specific settings onto one source set (wasm and js have different frontend checkers).
To get rid of it you can declare source set only for JS target and use task which just copy this source set into another folder and use this folder as source set for wasm target. But it likely provokes problem with resolving declarations from wasm-specific sources to “common” declarations until you copy them

[Robert Jaros]

Still I can't understand why I can use import androidx.compose.runtime.* in my common source set without IDE errors, but kotlinx.coroutines.* doesn't work.

[Robert Jaros]

There must be something about compose that make it work.

[Robert Jaros]

screen1.png

[Robert Jaros]

The compose runtime commonMain is displayed in my dependencies. But there is no commonMain for coroutines nor stdlib.

[Ilya Goncharov [JB]]

As for stdlib, it can be ok, stdlib always is special case. As for coroutines it is interesting.
But initial problem I think is about Node declaration is not presented in common, isn't it?

[Robert Jaros]

Node was only the first thing I noticed.

[Robert Jaros]

even simple emptyList() don't work

[Robert Jaros]

or listOf(), mutableListOf()

[Robert Jaros]

I can't use repeat()

[Robert Jaros]

or list.forEach {}

[Robert Jaros]

I have list: MutableList<String> and I can use list.removeAt() but I can't use list.forEach {}

[Robert Jaros]

That makes no sense to me

[Robert Jaros]

Extension functions seem to be problematic.

[Robert Jaros]

Or inline functions

[Robert Jaros]

For now I comment one of the targets, work a bit with the code, then replace targets, fix bugs and do more coding and replace again ;]

[Robert Jaros]

That's definitely not optimal way to work ;)

[Robert Jaros]

One more thing I've found. When importing the project in IDEA some *.klib files are created automatically for compose in .gradle/kotlin/kotlinTransformedMetadataLibraries directory. And this klib files are automatically added as dependencies to the commonMain module in the IDE (I can see this in Project Structure dialog).

[Robert Jaros]

It's definitely something about artifacts metadata of the published libraries. I've made some experiments and when I've changed the configuration of the maven repository using:

metadataSources {
         artifact()
}

or just forced kotlin version using:

implementation(kotlin("stdlib")) {
                    version {
                        strictly("1.9.20-Beta2")
                    }
}

somehow magically IDE creates a .gradle/kotlin/kotlinTransformedMetadataLibraries/org.jetbrains.kotlin-kotlin-stdlib-1.9.20-Beta2-commonMain-SsyL5g.klib file as a commonMain dependency and stdlib functions can be used without problems.

[Robert Jaros]

Unfortunately I haven't been able to force it for kotlin-dom-api-compat (which is always automatically selected as 1.9.30-dev-460) or kotlinx-coroutines-core.

[Robert Jaros]

I haven't found any information about this magical kotlinTransformedMetadataLibraries directory. Should it be always created for all libraries?

[Ilya Goncharov [JB]]

Do you have repository where I can reproduce the problem? I’d like to take a look, possibly it is indeed some problem on IDEA side

[Robert Jaros]

https://github.com/rjaros/kt-js-wasm/blob/main/build.gradle.kts#L57-L62

[Robert Jaros]

And one more thing - it seems Gradle works the same way as IDEA. I can't run ./gradlew build because there will be errors. But I can do ./gradlew jsRun or ./gradlew wasmJsRun without problem.
And just like with the IDE, when you uncomment the section highlighted above, both IDEA and Gradle will start accepting stdlib extension functions.

[Ilya Goncharov [JB]]

For transparency, I reproduced the problem, and I can see that the problem is here. If one of libraries either coroutines or compose is commented, project works well.
Moreover dev build works well, failed task is compileCommonMainKotlinMetadata.
Maybe problem is that coroutines library was built against not 1.9.20-Beta2, but 1.9.30-dev-…

[Ilya Goncharov [JB]]

I submitted an issue about the case
https://youtrack.jetbrains.com/issue/KT-62398