What is `warning "workspace-aggregator-6f2c6a0d-77...
# javascript
v
What is
warning "workspace-aggregator-6f2c6a0d-778d-49e5-9792-0c1b7ca65d3f > setup-wsl > kotlinx-coroutines-core@1.3.8" has incorrect peer dependency "kotlin@1.3.71".
telling me? Did I do something wrong? Is there a Koltin/JS error? ...? This is displyed when I have
implementation(npm("kotlinx-coroutines-core", "1.3.8"))
and refresh in IntelliJ. Actually mainly wondering, because I'll replace that with
implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core-js:1.3.8")
as the
npm
variant does not provide navigation to definition.
a
If you add kotlinx-coroutines-core as a dependency through npm, it will assume that the kotlin module is already available rather than bringing it along as a transitive dependency- which is probably correct. But npm issues that warning as it’s not made available through npm. Depending on it directly as a Kotlin dependency rather than an npm one sounds more correct (and aiui is required when using the new IR-based kjs compiler)
v
Well, I followed the readme and it said you can either depend on it through normal dependency or through npm dependency, so I thought it is cleaner to use it through npm dependency. afaiu the
kotlin
dependency also should be added automatically. But anyway I used the normal dependency now for better code navigation, thanks for the explanation. 🙂 What is IR and when is it used?
a
IR = Intermediate representation. The Kotlin/Native compiler already works by translating Kotlin into this IR and then “lowering” it to ASM. So the “new IR backend” of the Kotlin/JS compiler is a rewrite that shares code with the Kotlin/Native compiler and “lowers” it to JS instead. This is all my layman’s understanding, i.e. might be totally wrong 😄 It would mean that you can write a compiler plugin to just work on IR and it would work for both Native and JS output (at the moment you have to write three separate plugins, effectively, since JVM is its own thing). I think the WebAssembly backend is also going to work from the same IR, even if they’re moving away from the LLVM-based backend.
v
That means this enables things like AST transformations in Groovy? That would be amazing, it could mean a chance for getting a Kotlin version of Spock. :-D