https://kotlinlang.org logo
Join Slack
Powered by
If I'm using the Kotlin multiplatform plugin to cr...
# multiplatform
d
If I'm using the Kotlin multiplatform plugin to create a JS library, and I'm sure I'll only be releasing that target, is it safe for me to exclude the multiplatform publication when generating artifacts for Maven?
✅ 1
In other words, if I have a library called "mylib", instead of creating "mylib" and "mylib-js" artifacts, I think I can change it so the JS target gets published as "mylib" and the multiplatform version gets ignored.
Then, a user would just add a dependency on the library inside their 
jsMain
dependency block.
Does that make sense? Does the common multiplatform artifact contain any metadata that's important in some subtle way?
b
At this point you might just want to switch to kotlin.js gradle plugin instead of using mpp
d
I need mpp for Compose support
b
I thought CfW already supports js plugin. Have you tried recently?
c
Maybe you can create a new project with 
kotlin("js")
, no code but a dependency on your MPP project, and publish that one?
d
I haven't tried recently, but I don't want to restructure all my existing code if I can just tweak the publication configuration. This question could probably also apply to K/N targets.
c
I've heard in the Gradle slack that touching publishing is generally not recommended as it can break included builds. No idea if that's the case here, though.
b
Well I don't see why your initial idea would not work, but that just smells like a messy gradle setup imho
I personally would invest in restructuring to use js plugin. Much easier to maintain than custom patches
d
I guess my fundamental question is if the publication created by the js plugin is different from the JS part published by the multiplatform plugin
b
Shouldn't be (other than -js suffix)
d
Thanks
And I'll double check if the Kotlin/js plugin approach works instead.
r
I've heard JB is planning to drop kotlin/js plugin and use only kotlin/mpp js target in the future. So migration to kotlin/js plugin when you have mpp already working is probably not the best idea.
c
Any source on that?
Honestly I'd be for it, it's painful to create convention plugins for Kotlin, I often have JVM+JS library modules, a JVM backend and a JS frontend
d
@Big Chungus so I just did an experiment trying to convert one module to the kotlin/js plugin, and this section now causes import problems:
Copy code
val jsMain by getting {
   dependencies {
      implementation(compose.runtime)
      implementation(compose.web.core)
   }
}
since it seems that (as far as I can tell from some quick code searching) the compose plugin does not export convenient version catalogs for platform specific compose targets. (In a multiplatform world, these implementation declarations are resolved correctly) I can of course add them myself, but it feels like I'm going against the grain here. Not to mention that the Kotlin/JS plugin just looks like the Kotlin/Multiplatform plugin if you squint (you still need to create a 
kotlin { js { ... } }
configuration block, same as multiplatform, and the type of the 
kotlin
block is 
KotlinMultiplatformExtension
A picture is worth 1000 lines of code:
@Robert Jaros thanks for the heads up! Confirmation would be great but I'll be careful for now about jumping on a migration.
c
I'm genuinely considering migrating all my projects to the MPP plugin for the sole reason that the tasks would follow the same naming conventions everywhere
r
@CLOVIS JB gave me some early hints about their plans, because KVision is currently based on kotlin/js plugin.
c
Nice!
b
Rename jsMain to main and it should work
e
I think I remember @Sebastian Sellmair [JB] mention in a KMP meetup that there's a chance (if not a plan) that long term everything will be built on KMP's gradle model.
d
@Big Chungus Yeah, I understand that I'd need to migrate "jsMain" to "main". I was hoping to show two things off in the screenshot though: 1) this build script is failing at configuration time, and 2) the type of the 
kotlin
block is 
KotlinMultiplatformExtension
even though it's being exposed by the JS plugin (which makes me suspect it's really the multiplatform plugin but tweaked).
b
Ah, yes, missed that point. Yeah the two are actually bundled in a same jar and reuses a lot of stuff so that's not unexpected.
d
Cool. I'm just figuring things out as I go along -- I appreciate the help!
s
I do not recommend migrating to the -js plugin. I know that our current policy was oscillating with the plugins, but we seem to converge with the mpp plugin as the one that should be used also for js only. Regarding publication of the root vs the -js modules: Yes, feel free to not publish the root when you only target js and never plan to extend it.
6 Views
Open in Slack
PreviousNext
Powered by