I am coming back to Kotlin-MPP after a few years. I've got a Java backend and a TypeScript/React fro...

# multiplatform

[audax]

I am coming back to Kotlin-MPP after a few years. I've got a Java backend and a TypeScript/React frontend. I want to share some code between the applications (mostly validation-logic). Exporting typescript definitions is still experimental and quirky, but I don't need that. My plan is to build the shared module, use it directly in the backend and export the interfaces via OpenAPI. So in my frontend code I use the interfaces created by the OpenAPI-stuff und then I pass the objects to the kotlin shared module, where some glue code converts the TypeScript objects to Kotlin objects, runs the validation logic and returns the results in native JS types.

Only problem with that: Apparently I can only export a JS library if I use "@JsExport", otherwise the module is just empty. "@JsExport" is still experimental, so I don't want to use it in a production environment.

Is there a solution for my problem or at least a timeline for the status of "@JsExport"?

[turansky]

I usually use convention plugin, which also enable experimental features.
And check if they are still required when update Kotlin 😉

[audax]

I would have to hide this pretty well from my colleagues 😉
The alternative to Kotlin-MPP is a TypeScript library where we expose objects from the JVM to GraalVM to run the code server side. That's ugly as well.

I would love to finally use Kotlin-MPP in production 😞

[ephemient]

I think JsExport is more like alpha than experimental, it's not going away but they're leaving open the possibility of breaking changes in future releases

[ephemient]

you can sort of "hide" it in the gradle build,

sourceSets {
    all {
        languageSettings.optIn("kotlin.js.ExperimentalJsExport")
    }
}

[audax]

I would be even fine with switching to web assembly or other kinds of migrations, as long as the core functions are fine, I don't even need "fancy" enums 😉

I really hope that it at least gets alpha status in the near future. It's hard to argue for an experimental labeled technology. Maybe I'll pull the "just trust me"-card.

[Michael Krussel]

Like @ephemient said, I don't think that the name of the OptIn having Experimental means that it is actually experimental and not alpha or something. It just mean that they are not 100% sure the API will stay the same. They might rename it or switch to everything defaulting to export and you have an annotation to not export.

Kotlin JS is marked as stable, but I don't see anything drilling down to the actual export functionality.
https://kotlinlang.org/docs/components-stability.html#stability-of-subcomponents

[Michael Krussel]

All library features from Kotlin tend to be marked with experimental annotations until it goes to stable. There's no alpha or beta versions of the annotations

[audax]

That's a good argument, at this point it's just about API stability. I don't know if I should trust the typescript types however. What's the status on that? My fallback would be Open API to expose the types to Typescript instead of @JSExport.