Hi guys, I have this feature request based on my f...

# javascript

[andylamax]

Hi guys,
I have this feature request based on my feedback from trying out 1.6.20-M1 for the kotlin team. Please upvote and lets see if we can get it on 1.6.20 it looks like they are currently focusing on @JsExport at the moment

This is a feature request on how companion objects of classes and interfaces should behave in kotlin/js stricly when marked with @JsExport

Current Status
1. Marking an interface that has a companion object with @JsExport fails the build. You can get it to work with Suppress("WRONG_EXPORTED_DECLARATION") but this leads to incorrect typescript definition generations (static getter on the interface)
2. Marking an external class that has a companion with @JsExport fails the build even with Suppress("WRONG_EXPORTED_DECLARATION") . I am assuming this is even why currently kotlin.js.Promise is not marked as @JsExport
Breakdown
1. External interfaces with companion objects do not make any sense, from Kotlin and even Typescript. So @JsExport on external interfaces should definitely not compile
2. non external interfaces that have a companion object and are marked with @JsExport should definitely compile. Because they have meaning at least in Kotlin. Especially when used in multiplatform context. As in I can create an interface in common code, have some members in its companion object then decide to export it. Many KMP devs use this pattern
3. external classes (abstract, open, final) with companion objects should definitely be compillable because they have a solid one to one correlation between Kotlin and Typescript
Proposal
1. interfaces marked with @JsExport should work as they are now. Only difference is when it comes to type definitions, everything found inside and including the companion object itself should just be skipped during generation of types.
2. external classes (abstract, open, final) with companion objects should definitely be exportable. I am surprised as to why the compiler currently fails to compile them
Metadata
Kotlin: 1.6.20-M1
Ticket: https://youtrack.jetbrains.com/issue/KT-51292

[turansky]

namespace required for fine solutions or @JsStatic

[turansky]

At the same moment companion can be single solution in case of externals

[andylamax]

waiting till namespaces are implemented in kotlin will require too much patience. I suggest the single solution for now while waiting for namespaces

[Achifal]

Hey @andylamax!
Is there a workaround to handle wrong generations of typescript definitions (I mean static getter on interface). I met the same problem and don't know how to solve it. Thanks in advance for your help!

[andylamax]

I think Victor has somewhat a gradle plugin for that. I have one as well, but it is not published. If he does ping you good for you. If he doesn't i might create a public gist for you to include in your buildSrc

[turansky]

@andylamax Do you have replacement examples?

[andylamax]

I have an ugly version of it

[andylamax]

let me crate a gist then

[andylamax]

https://gist.github.com/andylamax/2bfc5635f791c571c3aa6ff426d6e6b6

[Achifal]

Thanks! It's really helpful