https://kotlinlang.org logo
Channels
Powered by
#webassembly
Title
# webassembly
r

Robert Jaros

10/03/2023, 11:32 AM
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?
Many different things from stdlib are also marked as errors in common source set (even some simple things like 
mutableListOf()
or 
repeat()
)
At the same time the IDE doesn't have any problem with 
import androidx.compose.runtime.Composable
. How it is detected?
j

Justin Salér

10/03/2023, 12:39 PM
Sometimes my IntelliJ fails to recognize imports. I then need to invalidate cache and restart the IDE for it to work.
r

Robert Jaros

10/03/2023, 1:14 PM
I've tried all options I know about, without success.
i

Ilya Goncharov [JB]

10/03/2023, 2:16 PM
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.
r

Robert Jaros

10/03/2023, 6:00 PM
But shouldn't IDE and gradle work the same way?
i

Ilya Goncharov [JB]

10/03/2023, 6:04 PM
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
r

Robert Jaros

10/03/2023, 6:27 PM
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.
There must be something about compose that make it work.
screen1.png
The compose runtime 
commonMain
is displayed in my dependencies. But there is no 
commonMain
for coroutines nor stdlib.
i

Ilya Goncharov [JB]

10/03/2023, 6:32 PM
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?
r

Robert Jaros

10/03/2023, 6:33 PM
Node was only the first thing I noticed.
even simple 
emptyList()
don't work
or 
listOf()
, 
mutableListOf()
I can't use 
repeat()
or 
list.forEach {}
I have 
list: MutableList<String>
and I can use 
list.removeAt()
but I can't use 
list.forEach {}
That makes no sense to me
Extension functions seem to be problematic.
Or inline functions
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 ;]
That's definitely not optimal way to work ;)
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).
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:
Copy code
metadataSources {
         artifact()
}
or just forced kotlin version using:
Copy code
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.
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
.
I haven't found any information about this magical 
kotlinTransformedMetadataLibraries
directory. Should it be always created for all libraries?
i

Ilya Goncharov [JB]

10/04/2023, 10:18 AM
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
r

Robert Jaros

10/04/2023, 3:02 PM
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.
i

Ilya Goncharov [JB]

10/05/2023, 10:50 AM
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-…
I submitted an issue about the case https://youtrack.jetbrains.com/issue/KT-62398
👍 1
6 Views
Powered by