https://kotlinlang.org logo
Title
s

sdeleuze

02/10/2023, 5:24 AM
Is there any chance we could avoid to have
kotlin-js-store/yarn.lock
generated when not using JS dependencies in our Kotlin/Wasm projects? I guess I am not the only one using Kotlin/Wasm to avoid dealing with the crazy JS ecosystem so getting that thing generated (and expected ti be committed for apps I think) by default is a bit irritating.
h

hfhbd

02/10/2023, 11:17 AM
I think, this should work at the root project:
plugins.withType<org.jetbrains.kotlin.gradle.targets.js.yarn.YarnPlugin>().configureEach {
    extensions.configure<org.jetbrains.kotlin.gradle.targets.js.yarn.YarnRootExtension> {
        yarnLockMismatchReport = org.jetbrains.kotlin.gradle.targets.js.yarn.YarnLockMismatchReport.NONE
    }
}
And you could also add this:
plugins.withType<org.jetbrains.kotlin.gradle.targets.js.nodejs.NodeJsRootPlugin>().configureEach {
    extensions.configure<org.jetbrains.kotlin.gradle.targets.js.nodejs.NodeJsRootExtension> {
        nodeDownloadBaseUrl = "<https://nodejs.org/download/v8-canary>"
        nodeVersion = "20.0.0-v8-canary202212266b2b946a63"
    }
}

tasks.withType<org.jetbrains.kotlin.gradle.targets.js.npm.tasks.KotlinNpmInstallTask>().configureEach {
    args.add("--ignore-engines")
}
The first disables the yarn lock error report, if you want. The second configures the node version using the kotlin plugin, so this will result into generating an expected yarn.lock file. If you really don't want to generate the lock file, you could simple disable the task.
s

Svyatoslav Kuzmich [JB]

02/10/2023, 11:53 AM
cc: @Ilya Goncharov [JB]
i

Ilya Goncharov [JB]

02/10/2023, 11:55 AM
We still uses NPM infrastructure for testing. So
karma
or
mocha
still can be used by build. But it is common approach, that we will try to reduce affect of NPM dependencies on user’s builds
j

James Ward

02/10/2023, 4:15 PM
I wonder if there is some way with Kotlin/Wasm to avoid Node all together. It'd be really nice to avoid that whole binary dependency / execution thing.
s

sdeleuze

02/12/2023, 9:32 AM
Making JavaScript touchpoints/interrop entierly optional is my hope as well middle term. One of the main interest of Wasm support for Kotlin is that it allows to avoid the "stay in the shadow of the platform language" unsolvable issue we see on JVM serverside with Java and on the Web with JavaScript/TypeScript. Also avoiding to be exposed to JS ecosystem complexity by default could be a strong booster for Kotlin/Wasm adoption. This is one of the reasons why I push for getting WASI support in Kotlin/Wasm at some point. But to realize that vision, and if we take the assumption the Kotlin team will be up for this, I think we miss a few building blocks, so leveraging Node/JS ecosystem partially seems needed for now. In order to make that possible, I think we would need in Kotlin/Wasm: • WASI Preview2+ support via KT-36172, see WASI roadmap • WASI Component Model support (I created KT-56605 related issue) • Gradle support for fetching dependencies from a

warg repository

(I created KT-56607 related issue) And we need WasmGC support in at least one of the major pure WASM runtime, IMO to be significant enough that should be available on Wasmtime (see wasmtime#5032). Could also happen via WasmGC to Wasm translation in Binaryen, see binaryen#4590 related issue. Those topics will move fast in 2023 so we are at a point where this is the perfect timing to begin to consider them and maybe have an influence on their design to make sure they are a good fit for Kotlin and that Kotlin/Wasm becomes a major player in that game.
@Ilya Goncharov [JB] Maybe
yarn.lock
could be moved to
build
when only used for tests to avoid people to have to commit it and that would make it less visible to Kotlin/Wasm users? I am not sure it makes sense to commit it for that use case.
s

Svyatoslav Kuzmich [JB]

02/14/2023, 11:53 AM
I agree. Hopefully we could make a our gradle plugin less opinionated by default. I’m thinking about something like tiers where you can opt-in to: Tier 0: produce
.klib
(Already possible) Tier 1: produce
.wasm
+
.mjs
(And without
.mjs
in the future when we support it). Tier 2: Run or test plain executable in a VM, like browser, node, wasmtime, etc. This is where you would need to either specify installed VM or download specified version automatically. Tier 3: NPM, Yarn, warg? integration - should be hopefully orthogonal to compiler tasks