We have two classes of the same name but in different packages annotated with @JsExport. Upon build ...

# javascript

[István Mészáros]

We have two classes of the same name but in different packages annotated with @JsExport. Upon build the compiler warns: There are clashes of declaration names that annotated with @JsExport in module 'my.project:module'. Arent package names supposed to be included in the exported code? The docs says "Kotlin exposes its package structure to JavaScript, so unless you define your declarations in the root package, you have to use fully qualified names in JavaScript". We're on 1.9.21 and compiling to a library target with ES modules. What am I missing?

[turansky]

Export will be flat. It's classic for ES modules and for JS in 2023.

[turansky]

You can resolve clash with @JsName :

// pkg 1
@JsExport
@JsName("FirstData")
class Data

// pkg 2
@JsExport
@JsName("SecondData")
class Data

[István Mészáros]

Thanks, it was indeed the useEsModules() setting that caused the namespace declarations to be omitted. @JsName looks like a fine solution though.

[andylamax]

While its true that it's classic for ES modules to be exported in a flat structure, it is not true in the case of an umbrella module
• ES modules are their own "modules", which makes them kind of isolated and reasonable to a flat export structure
• The current state of exporting kotlin libraries as umbrella modules violates that "module isolation" mentioned above which introduces inevitable clashes on declarations
• When creating a kotlin library, you create what is commonly referred to as an "umbrella module". An umbrella module appears to be one module but under the hood its just a collection of many modules. Now, being that "umbrella modules" are not "classic" in the JS ecosystem, so is exporting their declarations in a flat structure. There almost always going to be a clash in declarations.
That being said, the kotlin/js team should find a way to make the exports flat in an individual module, but not flat in the umbrella module. Or a much better solution than that

[turansky]

For now you have all required options to build fine umbrella modules.
Unique JS name between all subjects - practice which I see in big TS/JS libraries.

[andylamax]

What options do I have for my ts consumers to get upload.status.Success user.info.Success, init.stage.Success and many other Result like states without renaming them to something else???

[turansky]

1. Custom TS namespaces
2. Multiple exports in package.json

[turansky]

From flat structure you can build any which you need

[turansky]

But non-flat structure will block bundle optimization

[turansky]

https://www.typescriptlang.org/docs/handbook/modules/reference.html#packagejson-exports

[andylamax]

Actually, looks like package.json exports might help.

Do I have to maintain these exports manually, or is there a flag I can set??

[turansky]

It looks like result of custom Gradle task

[ankur2037]

is there any sample for this package,json ?
I am facing a similar issue where TS file, exported from an umbrella module, when used in JavaScript as an NPM, is unable to resolve the dependent module exports.