Kotlin wrappers works so well in an environment wh...

# javascript

[andylamax]

Kotlin wrappers works so well in an environment where you are working with kotlin/js to publish kotlin Apps. However last time I checked (arround June this year), for any one who was writting a library in kotlin to be consumed from typescript had to jump hoops to get it to work, main reason is because all the types in kotlin wrappers are not marked by @JsExport rendering the whole stack's types as any when exposed to typescript. I deeply request @turansky if it is not too much effort, can we mark all external kotlin/js declarations with @JsExport so that us library authors who write kotlin libs to be used in typescript also benefit from the stack??? If there is a downside to this request, can you please enlighten me???

[ian.shaun.thomas]

Please! I feel the same way about needing to mark data classes immutable for compose all over the place. Can I instead just opt out the few in the module that I don't want to be immutable vs the majority which are all val property data classes. I'd love a flag to just set em all for me and not have to think about it anymore.

[turansky]

> mark all external kotlin/js declarations with @JsExport
It looks like duplication of existed TS declaration

[turansky]

If there is a downside to this request, can you please enlighten me???

There is no direct mapping between TS and Kotlin/JS declarations.

[andylamax]

It looks like duplication of existed TS declaration

Yes and no, because, if I export a ReadonlyArray<String> they type is defined as any (coz ReadonlyArrray) is not marked with @JsExport. While the types are almost Identical, we miss the definitions in the final .d.ts file. hence this request to you

[andylamax]

> There is no direct mapping between TS and Kotlin/JS declaration
I feel like you logically can't say "it looks like a duplication of existed TS" and then follow up with the statement "There is no direct mapping..."


But clearly not every definition is Mapped one to one. But those that can (especially the external declarations) would go along way (if marked with @JsExport) in helping us library devs whom our targeted consumers are TS developers

[turansky]

Yes and no, because, if I export a ReadonlyArray<String> they type is defined as any (coz ReadonlyArrray) is not marked with @JsExport.

Will it work with @JsExport ? 😉

[turansky]

I feel like you logically can't say "it looks like a duplication of existed TS" and then follow up with the statement "There is no direct mapping..."

I expect invalid and non-compatible copies of TS types

[turansky]

And what we should do with external interfaces with same name (but from different packages)?

[andylamax]

Will it work with @JsExport?

Yes, for two reasons.
1. The fact that typescript type system is structural and instance based assures that it will work
2. I have done some attempts and duplicated some of the definitions from kotlin-wrappers with success. Catch is, I didn't duplicate everything just the stuff I needed and it seem to work

[andylamax]

I expect invalid and non-compatible copies of TS and Types

Thats the beauty of typescript interfaces, they merge on collisions and again the types are validated through a structural approach

[andylamax]

And what we should do with external interfaces with the same name??

This is an actual roadblock if one is using useEsModule() , coz the complier exports things in a flat structure

But using other types, i.e. umd, the typescript definitions are being spitted out in their respective namespace which does match with the package itself

But since this is a already a problem to whoever uses esModules, the impact of exporting external declarations will be non existent.

Also, users who aren't interested in exported declaration have been already opted by default with the kotlin compiler plugin. So, yes to @JsExport

[andylamax]

I urge you to think about kotlin-wrappers as an npm (javascript) library, everything that is intended to be used on a public api, trully has to be exported to be usable

[turansky]

If I need to mark all external types with annotation - why it's not default behavior of compiler?

[turansky]

In any case, solution which you describe - doesn't work in common case.
We have multiple external types, which has no sense in TS.

Example project with your use cases and YouTrack issue - fine start point

[andylamax]

Sure then, do I create kotlin-wrappers issue in youtrack or github?

[turansky]

YouTrack