Has anyone run across this in the wasmJs target co...

# multiplatform

[Ryan Scott]

Has anyone run across this in the wasmJs target configuration after upgrade from kotlin 2.1.10 to 2.1.21?

Could not create an instance of type org.jetbrains.kotlin.gradle.targets.js.ir.KotlinBrowserJsIr.
> Cannot invoke "org.gradle.api.tasks.TaskProvider.flatMap(org.gradle.api.Transformer)" because the return value of "org.jetbrains.kotlin.gradle.targets.js.ir.ExecutableWasm.getOptimizeTask()" is null

My wasmJs target configuration is as below:

wasmJs {
        outputModuleName.set("foundation-util-log")
        browser {
            testTask {
                useKarma {
                    useFirefoxHeadless()
                }
            }
        }
        binaries.library()
    }

[Ryan Scott]

The exact same configuration works for the js target:

js {
        outputModuleName.set("foundation-util-log")
        browser {
            testTask {
                useKarma {
                    useFirefoxHeadless()
                }
            }
        }
        binaries.library()
    }

[tapchicoma]

please create a new Kotlin issue with repro project

[Ryan Scott]

Will do. I'll have to take out all the proprietary stuff from this project so that I can share it. I'll try to get a sample project together tomorrow.

[Ryan Scott]

I've also discovered that upgrading to Kotlin 2.2.0-RC has a fix already for this.

[Ryan Scott]

But . . . I cannot use an RC in production.

[tapchicoma]

release should be out relatively soon (~ next week)

[tapchicoma]

if it is fixed in RC - we will not do a separate 2.1.22 release

[Ryan Scott]

Ah--okay. That makes sense. Would you like me to file the kotlin issue anyway?

[tapchicoma]

if you need some workaround and want to use 2.1.21 release instead of 2.2.0 - please do

[Ryan Scott]

Just a follow-up on this. I found that the root cause of the issue was related to my signing configuration. I applied a workaround to an issue that appears to still be in the 2.2.0-RC version. This makes me think that I did something wrong in my gradle configuration, and the bug, if there is one, relates to not receiving a friendlier exception message.

[Ryan Scott]

The reason I did not think the bug was still present in 2.2.0-RC was that at the same time I upgraded, I turned off signing temporarily.

[tapchicoma]

hmm, still open an issue with your signing config - maybe we could improve here error situation

[Ryan Scott]

Yah. I have a pretty bad workaround that causes the configuration phase in my project to take a long time.

[Ryan Scott]

But I got it working.

[Ryan Scott]

For local development, we don't need signing anyway, so it's not as big a deal as it sounds.

[Ryan Scott]

If you're curious, this is the error that I was facing (and this only happened when the wasmJs target was enabled):

> Task :foundation-testtools:publishJsPublicationToMavenLocal FAILED

[Incubating] Problems report is available at: file:///Users/ryan/repos/maven_machines/mobile/foundation/build/reports/problems/problems-report.html

FAILURE: Build failed with an exception.

* What went wrong:
A problem was found with the configuration of task ':foundation-testtools:publishJsPublicationToMavenLocal' (type 'PublishToMavenLocal').
  - Gradle detected a problem with the following location: '/Users/ryan/repos/maven_machines/mobile/foundation/foundation-testtools/build/libs/foundation-testtools-0.2.0-javadoc.jar.asc'.
    
    Reason: Task ':foundation-testtools:publishJsPublicationToMavenLocal' uses this output of task ':foundation-testtools:signWasmJsPublication' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.
    
    Possible solutions:
      1. Declare task ':foundation-testtools:signWasmJsPublication' as an input of ':foundation-testtools:publishJsPublicationToMavenLocal'.
      2. Declare an explicit dependency on ':foundation-testtools:signWasmJsPublication' from ':foundation-testtools:publishJsPublicationToMavenLocal' using Task#dependsOn.
      3. Declare an explicit dependency on ':foundation-testtools:signWasmJsPublication' from ':foundation-testtools:publishJsPublicationToMavenLocal' using Task#mustRunAfter.

[Ryan Scott]

The workaround I used was just to make every publish task dependent upon every signing task.

[Ryan Scott]

But since I've got 18 gradle modules and each of them have 5 targets (not including kotlin metadata), this radically slows down publishing all publications.

[tapchicoma]

I suppose you are hitting this Gradle issue: https://github.com/gradle/gradle/issues/26091

[Ryan Scott]

That's exactly it.

[Ryan Scott]

So this isn't a kotlin multiplatform plugin issue?

[tapchicoma]

Not exactly

[tapchicoma]

check this workaround

[Ryan Scott]

That's essentially the same thing that I did, except I set a dependsOn relationship. Will mustRunAfter work better?

[tapchicoma]

fyi @Wojtek Kalicinski - maybe we could guide users here as well

[tapchicoma]

Will mustRunAfter work better?

dependsOn is a hard dependency. Meaning task which you declare dependsOn dependency should always run.
mustRunAfter is a soft dependency. Meaning task which you declare mustRunAfter should run first if it is in task graph, but will not run if it is not in the task graph.

[Ryan Scott]

In this case, I think it will not actually speed anything up (because I'm running publishAllPublicationsToXRepository), but thanks for that clarification. I'll give it a try anyways.