Vampire
08/06/2020, 1:53 PMEPIPE
problem from above solved, I'm a step further, but highly confused.
Maybe someone can shed some light here.
• 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
• 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.fwilhe
08/07/2020, 5:49 PMVampire
08/07/2020, 5:57 PMfwilhe
08/07/2020, 5:58 PMfwilhe
08/07/2020, 5:58 PMfwilhe
08/07/2020, 5:58 PMfwilhe
08/07/2020, 5:59 PMfwilhe
08/07/2020, 5:59 PMVampire
08/07/2020, 6:01 PMVampire
08/07/2020, 6:02 PMVampire
08/07/2020, 6:02 PMfwilhe
08/07/2020, 6:02 PMfwilhe
08/07/2020, 6:02 PMfwilhe
08/07/2020, 6:02 PMVampire
08/07/2020, 6:03 PMVampire
08/07/2020, 6:03 PMgradlew run
does not work as expectedVampire
08/07/2020, 6:03 PMVampire
08/07/2020, 6:04 PMVampire
08/07/2020, 6:04 PMfwilhe
08/07/2020, 6:06 PMVampire
08/07/2020, 6:08 PMVampire
08/07/2020, 6:08 PM@actions/core
it works fine it seems, for some others not so finefwilhe
08/07/2020, 6:09 PMturansky
08/09/2020, 10:36 AMOh, or is this made with Kotlin/JS?Yes, and it was in first comment, which was reported as “spam” by @Vampire
Vampire
08/09/2020, 11:20 AMturansky
08/09/2020, 12:22 PM@JsModule
annotation if package name is started from @
(dukat bug - issue exists)turansky
08/09/2020, 12:24 PM@JsModule("@actions/core")
turansky
08/09/2020, 12:27 PMdukat
2. Add @JsModule
annotation manually to @actions
declarationsturansky
08/09/2020, 12:33 PMVampire
08/09/2020, 1:17 PMVampire
08/10/2020, 1:06 AMVampire
08/10/2020, 1:10 AM@file:JsModule("@actions/core")
injected the simple example works now from gradlew run
, the packaging would have been the next issue
Besides that adding the other dependencies will probably still break compilation.turansky
08/10/2020, 8:59 AMnodejs
= browser
- bundler :(
If you need single js file in dist you need:
1. Use browser
target and configure
2. Configure right this
Vampire
08/10/2020, 5:32 PMnodejs
target by having a subproject that calls @zeit/ncc
from the node.js code and thus does the packaging, like it does in the TypeScript template by GitHub.
I think this might be the cleaner solution. 🙂Vampire
08/10/2020, 5:32 PM@zeit/ncc
uses webpack internally too)Vampire
08/10/2020, 5:35 PM@JsModule
, so thanks again @turansky.
My simple import setFailed; fun main() = setFailed("boo hoo")
action is now working as intended, including ncc
packaging. 🙂
I just fear that when I add more of the libraries I needed before, I will hit the compile errors again. 😞turansky
08/10/2020, 5:44 PMlegacy
are known and registered. Workarounds are known too.
This chat can help in most cases :)Vampire
08/10/2020, 5:45 PMturansky
08/10/2020, 7:32 PM