<@U02BK8ABTQF> regarding the `export default` of p...

# javascript

[Edoardo Luppi]

@Artem Kobzar regarding the export default of plain objects, I've seen that exporting something like

val obj = js("{}")

Generates something on the line of

var obj = {};
var x = { get: obj };
export default x;

I don't understand the get: part to be honest. I understand getInstance for instances of Kotlin classes/objects, since they can be lazy, but not for JS objects or externals.

[Artem Kobzar]

Yes, this is what we have for ES modules right now (I'm also thinking on changing this export part).
However, the logic here is the following:
1. In Kotlin variables are initialized lazily as soon as any declaration from a file was used:

// until either getter of foo or test function are called, the complex computation will not be executed

val foo = someComplexComputation()
fun test() {}

2. For a custom getter/setter we can monkey-patch the top-level export (like we did in other module systems), so we should by somehow to provide such getter/setter.
3. Imagine that for simple properties we just export it in a form of a variable, but for custom getter/setter in the form we have now. In this case, as soon as people add for a val a custom getter, the usage should be changed, which is not the best DX.

We're still thinking on what we can do here (to be honest, right now we don't have much ideas how to do better in this place)

[Edoardo Luppi]

In my opinion there are two elements that could differentiate how you export a variable:
1. is it marked with @EagerInitialization? It can be exported as is, without any wrapping getter
2. is it of an external type (or dynamic)? It should be treated as part of the JS realm, without following strict Kotlin rules