If I'm using the Kotlin multiplatform plugin to create a JS library, and I'm sure I'll only be relea...

# multiplatform

[David Herman]

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?

[David Herman]

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.

[David Herman]

Then, a user would just add a dependency on the library inside their jsMain dependency block.

[David Herman]

Does that make sense? Does the common multiplatform artifact contain any metadata that's important in some subtle way?

[Big Chungus]

At this point you might just want to switch to kotlin.js gradle plugin instead of using mpp

[David Herman]

I need mpp for Compose support

[Big Chungus]

I thought CfW already supports js plugin. Have you tried recently?

[CLOVIS]

Maybe you can create a new project with kotlin("js") , no code but a dependency on your MPP project, and publish that one?

[David Herman]

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.

[CLOVIS]

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.

[Big Chungus]

Well I don't see why your initial idea would not work, but that just smells like a messy gradle setup imho

[Big Chungus]

I personally would invest in restructuring to use js plugin. Much easier to maintain than custom patches

[David Herman]

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

[Big Chungus]

Shouldn't be (other than -js suffix)

[David Herman]

Thanks

[David Herman]

And I'll double check if the Kotlin/js plugin approach works instead.

[Robert Jaros]

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.

[CLOVIS]

Any source on that?

[CLOVIS]

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

[David Herman]

@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:

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

[David Herman]

A picture is worth 1000 lines of code:

[David Herman]

@Robert Jaros thanks for the heads up! Confirmation would be great but I'll be careful for now about jumping on a migration.

[CLOVIS]

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

[Robert Jaros]

@CLOVIS JB gave me some early hints about their plans, because KVision is currently based on kotlin/js plugin.

[CLOVIS]

Nice!

[Big Chungus]

Rename jsMain to main and it should work

[eygraber]

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.

[David Herman]

@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).

[Big Chungus]

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.

[David Herman]

Cool. I'm just figuring things out as I go along -- I appreciate the help!

[Sebastian Sellmair [JB]]

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.