Open Vampire opened 4 years ago
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)
Just in case, here's a workable action written in Kotlin JS 1.4.0-rc: https://github.com/burrunan/gradle-cache-action
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 :-/
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) :(
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.
implementation(npm("@actions/core", "1.2.4"))
as npm dependency, automatic Dukat runs fine now, producing acore.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.@actions/core
as dependency, it then compiled fine, but doing./gradlew run
complains withReferenceError: setFailed is not defined
with a JS file containingimport setFailed; fun main() = setFailed("boo hoo")
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. :-(