Runtime errors and compile time errors using Dukat

[Vampire]

As the #javascript channel on the Kotlin Slack is not very active, I'm asking here in hope it is ok.

After I got my EPIPE problem (#103 / #351) solved, I'm a step further, but highly confused. Maybe you can shed some light.

Given the example project I showed in #103.

• If I only have implementation(npm("@actions/core", "1.2.4")) as npm dependency, automatic Dukat runs fine now, producing a core.module_@actions_core.kt file with the external definitions, but all exported methods are in the default package, not in an npm-package specific package, is that expected or can this be changed? I imagine this could easily cause conflicts if you add more dependencies.
• Also, with only @actions/core as dependency, it then compiled fine, but doing ./gradlew run complains with ReferenceError: setFailed is not defined with a JS file containing import setFailed; fun main() = setFailed("boo hoo")
• Now it gets even uglier, I added the other dependencies I have (or at least had in the TS variant, some are probably superfluous now):

  implementation(npm("@actions/cache", "1.0.1"))
  implementation(npm("@actions/core", "1.2.4"))
  implementation(npm("@actions/exec", "1.0.4"))
  implementation(npm("@actions/http-client", "1.0.8"))
  implementation(npm("@actions/io", "1.0.2"))
  implementation(npm("@actions/tool-cache", "1.6.0"))
  implementation(npm("semver", "7.3.2"))
  implementation(npm("null-writable", "1.0.5"))
  implementation(npm("node-filter-async", "2.0.0"))

  and now while Dukat still duly does its work (and produces 316! Kotlin files o_O), the compiler is super unhappy, throwing 802 errors at me. :-(

[Vampire]

I found that you can do

configure<NodeJsRootExtension> {
    versions.dukat.version = "0.5.7"
}

to use a newer Dukat version than the default 0.0.12, but with that, I now get

Exception in thread "main" java.lang.Exception: unknown TopLevelEntity:
        at org.jetbrains.dukat.tsmodel.factory.ConvertProtobufKt.convert(convertProtobuf.kt:463)
        at org.jetbrains.dukat.tsmodel.factory.ConvertProtobufKt.convert(convertProtobuf.kt:330)
        at org.jetbrains.dukat.tsmodel.factory.ConvertProtobufKt.convert(convertProtobuf.kt:819)
        at org.jetbrains.dukat.tsmodel.factory.ConvertProtobufKt.convert(convertProtobuf.kt:824)
        at org.jetbrains.dukat.ts.translator.JsRuntimeByteArrayTranslator.parse(JsRuntimeByteArrayTranslator.kt:17)
        at org.jetbrains.dukat.ts.translator.JsRuntimeByteArrayTranslator.translate(JsRuntimeByteArrayTranslator.kt:21)
        at org.jetbrains.dukat.ts.translator.JsRuntimeByteArrayTranslator.translate(JsRuntimeByteArrayTranslator.kt:9)
        at org.jetbrains.dukat.translatorString.TranslateModuleKt.translateModule(translateModule.kt:142)
        at org.jetbrains.dukat.cli.CliKt.translateBinaryBundle(cli.kt:56)
        at org.jetbrains.dukat.cli.CliKt.main(cli.kt:313)

[vlsi]

Just in case, here's a workable action written in Kotlin JS 1.4.0-rc: https://github.com/burrunan/gradle-cache-action

[ivakub]

https://youtrack.jetbrains.com/issue/KT-40927

[Vampire]

Thanks @vlsi, someone else also pointed your action to me. Actually in the meantime I was able to at least get my basic import setFailed; fun main() = setFailed("boo hoo") action to work properly with 1.3.72, Dukat 0.5.7 and a @zeit/ncc based packaging. There it was mainly the missing @JsModule annotation. But I fear I need 802 more workarounds to get all back up and working :-/

[vlsi]

But I fear I need 802 more workarounds to get all back up and working :-/

Great you got it working :)

The number of workarounds depends on the packages you use, and @JsModule is often misplaced (it is often missing or wrong) :(