Good morning everyone :sunny: I need your input s...
# javascript
a
Good morning everyone β˜€οΈ I need your input so much in the following question. In the thread, please share how you publish Kotlin/JS artifacts (not KLIB, but the executable) to a registry (e.g., NPM, JSR, Maven) and any pain points you've encountered with the approach. Thank you for the help πŸ™ Artem, Kotlin/JS Lead
πŸ‘€ 2
a
I use the #C01LQTET9P1 plugin to publish to an internal Vedaccio instance
thank you color 1
e
npm-publish
is the way for us. We publish to internal npm repositories under Nexus. We're using the active fork at https://github.com/DanySK/npm-publish.
And no issues I'd say. The only small problem I had was the missing package type. You can see what I mean here. Edit: forgot https://github.com/DanySK/npm-publish/issues/23, but it's workaroundable.
l
we use
npm-publish
and publish to github npm registry
r
I've been using command line commands in simple gradle tasks, - "npm publish", basically. Most of the pain points I recall being very simple - ensuring all the right package.json things are in place, or getting the intended name. If i was publishing libraries to be consumed that way, I'd probably have some complaints about how modularization works, but since i'm publishing CLI tools that hasn't mattered at all.
a
@Rob Murdock, and why did you decide to use custom tasks and not #C01LQTET9P1?
r
truly I don't know that it was a deeply considered decision, so much as it worked quickly and hasn't needed to change since!
thank you color 1
k
Planning to share artifacts on AWS CodeArtifact but haven't gotten to that point in our SDK development yet.
kodee loving 1
e
@Artem Kobzar I've seen the npm-publish plugin has been moved under the Kotlin org. Is there a plan to transition maintenance under the JetBrains/Kotlin umbrella?
a
Exactly, this is our plan! Currently, I'm setting up all the required work and agreements, but yes, we've contacted @Big Chungus and agreed on our maintenance of his fantastical plugin. As soon as I finish all the work and publish the plugin, I will make an official announcement in #C0BJ0GTE2 and #C01LQTET9P1
πŸ‘ 3
πŸ†’ 1
K 3
k
What an amazing user handle and news!
πŸ˜€ 1
a
This is every open source contributor news. Big up to @Big Chungus I am proud to be one of the contributors (however minor my contribution was) of this amazing plugin
kodee loving 1
a
And yes, the plugin remains open source, so contributions are welcome! I also want to cherry-pick all the changes @Danilo Pianini made to his fork.
e
Yeah was just going to mention that there are some commits related to Gradle compatibility in his fork
a
Actually, I really would appreciate it if someone could help me with the picking up the changes (because after a vacation, I'm a bit overloaded with tasks πŸ˜…)
b
Should be able to just create a pr from fork into base. I don't expect there to be any commits in base that are not in the fork
πŸ”₯ 2
e
If no one offers for that, I can diff the fork by end of week and open a PR with cherry picked commits. But yeah as @Big Chungus said it should be fairly straightforward, apart from the different artifact coordinates.
πŸ‘€ 1
I took a look at how easy it is to cherry pick stuff. It's not as straightforward as I would have expected, in the sense that there were quite a lot of infra changes, especially to get rid of Git submodules.
h
Any updates on this? I'm pretty much unable to use kotlin/js in my current project because I can't publish a working npm library
e
You should use https://github.com/DanySK/npm-publish in the meantime.
h
Was having issues with that one as well
e
What issues specifically? Asking as I've been using Dany's fork for quite a while to publish to npm and private Sonatype repositories.
e
Have you inspected the
build/packages
(IIRC) folder to check if all the required files are there before publishing?
h
looking like maybe the second folder is what's getting published?
e
Interesting difference of layout there. Is
api.mjs
under
productionLibrary/@common
?
h
yes
e
Probably. I don't know the plugin's implementation details, but maybe it's splitting up that path and looking at the last path segment only.
h
okay yeah removing that line fixed it
thanks so much for your help
e
Or, it's a KGP issue, for the fact files are outputted to the wrong location. I'll give it a go on my own repos just to see what happens.
πŸ‘ 1
h
tbh im kinda reconsidering using kotlin/js for this given it requires so many dependencies and therefore has a fairly large package size but i guess since im using nextjs and this will probably only be used on the server it's probably fine
e
Serialization and Ktor are generally quite heavy even if you don't use much of them.
πŸ‘ 1
I've explicitly avoided Ktor for K/JS and instead went for an expect-actual approach, using platform sockets or websockets.
πŸ‘ 1
h
Nice, can you point me to any examples of this?
e
I don't have a public example unfortunately. But what I've done is simply abstract the concept of a socket, and then wrapped Ktor's implementation under JVM, and Node.js'/browser's implementation under JS.
πŸ‘ 1
@Artem Kobzar @Ilya Goncharov [JB] I figure this should NOT happen, correct? All files should still live under the root
productionLibrary
directory in a
per-module
granularity setting. And `main`/`typings` should not use the module name as a path.
You may want to use
whole-program
granularity in the meantime.
Well nope it happens also for whole program.
a
@Edoardo Luppi it seems like a bug. Could you please create a ticket for it? CC: @Adam Semenenko