I’m very excited for 1.6.20 for the JS improvement...

# javascript

[ansman]

I’m very excited for 1.6.20 for the JS improvements, unfortunately most of my tests broke due to the generated JS code being broken. It seems to be because Collection.size isn’t defined at runtime and calls to it returns undefined which in turn causes most things that uses collections to fail. I’m guessing it will be very hard for me to have a reproducer since this can’t possibly happen in most cases or the tests for the compiler would have caught them. Does this sound familiar to anyone else?

[ansman]

Here is a simple example of what breaks:

assertEquals(list1.size, list2.size)

[Luc Girardin]

Have you tried 1.6.21?

[ansman]

I did yes.

[ansman]

kotlin.js.ir.output.granularity=whole-program seems to help with some of the issues

[ansman]

Actually, strike that

[ansman]

The test failure in the example above says:

Expected <null>, actual <20>.

[ansman]

The generated code looks like this:

var tmp = list1.size;
var tmp_0 = list2._get_size__809037418_ddoh9m_k$();

[Luc Girardin]

On 1.6.21 I still need to rely on the LEGACY compiler for JS production. Certainly not a good solution, but you may want to try whether the output is different.

[ansman]

Hmm, I think this might be happening because list1 is a class that I’ve created called CollectionWrapper which implements Collection but I don’t see it actually extend the prototype anywhere in the generated JS code

[ansman]

In fact all properties defined in an interface just seems to be gone with 1.6.20, I don’t see any defineProperty calls for things declared in an interface

[ansman]

Filed: https://youtrack.jetbrains.com/issue/KT-52144/Kotlin-JS:-Missing-property-definitions-for-interfaced-defined-p

[Karel Petránek]

We hit this issue as well and it helps to put explicit JsName annotations on the overridden methods/properties. Note that Kotlin will complain that JsName cannot be used that way so you also have to Suppress("JS_NAME_PROHIBITED_FOR_OVERRIDE"). It’s silly that this needs to be done but at least helps to work around the issue until a proper fix arrives.

[ansman]

Awesome! Will try

[ansman]

I really really wish that you could export things that are defined in the standard library

[ansman]

Worked like a charm!

[ansman]

I added it as a comment on the issue and credited you @Karel Petránek

[ansman]

At least I hope that’s you

[Karel Petránek]

That’s me, thanks! 🙂

[Michael Friend]

This issue is pretty similar to this one, or at least the linked issue will also happen in your implementation but you wont notice it if you’re not using typescript. The approach in my comment works with typescript if that matters

[Michael Friend]

now that interfaces in general are exportable as of 1.6.20 my hope is that the collection types being exported is mostly unblocked and will come in a (near 🤞)future release.

[ansman]

Yeah, that is one option. But then it won’t be an NSArray or List in iOS or Android

[Michael Friend]

Yea it's a trade off we decided to accept for the usuablilty from js and ts which was a must have for us