Is there any chance we could avoid to have `kotlin...

# webassembly

[sdeleuze]

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.

[hfhbd]

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

[hfhbd]

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.

[Svyatoslav Kuzmich [JB]]

cc: @Ilya Goncharov [JB]

[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

[James Ward]

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.

[sdeleuze]

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

[Svyatoslav Kuzmich [JB]]

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