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.

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")
}

cc: @Ilya Goncharov [JB]

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

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.

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 (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.

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