Just saw <KT-86998> got put into the backlog, so I...

# javascript

[Marc]

Just saw KT-86998 got put into the backlog, so I assume it will not get fixed for a while. Is there a way to work around this issue? As far as I understand this makes it impossible to use suspending code across multiple K/JS modules. The only fix I could figure out is to collapse everything into a single exported module, which means I can no longer depend on parts of the functionality and have to always pull in everything.

[Artem Kobzar]

Oh, sorry. I've revisited the ticket and understand that I moved an incorrect ticket (we have one that made impossible a compilation of two modules separately and their objects (like COROUTINE_SUSPENDED) were not equal). I moved it back and will investigate ASAP 🙏

[Marc]

Thank you! To be honest, it's a very annoying problem. My current solution is to restructure my modules so they only contain the JVM/iOS/etc. target code and then moving all of the JS target code to a single artificial "main" module. It does work, but it's a bit of a mess.

[Artem Kobzar]

Oh, it's sad to hear it. Sorry for the annoyance. We will do our best to improve the situation with this issue in the following release.

[Marc]

Thank you so much for taking a look! 👍

[Edoardo Luppi]

@Marc which output granularity are you using? Wouldn't a whole-program granularity workaround this one?

[Marc]

As far as I understand, whole-program is the only useable setting anyway, right? As described in KT-65695, any finer granularity will result in all standard library and dependency symbols being unavailable at runtime. Effectively my workaround is using whole-program and putting all module code in a single module. If you use multiple modules with whole-program , you will get 2 copies of the standard library and all the strict equality checks on sentinel values for suspending functions will fail (when calling suspending functions across modules). If you use any other granularity, my code doesn't even work because it will be unable to resolve references to KtList or whatever at runtime.

[Edoardo Luppi]

Indeed, at this point, you're already using the correct workarounds. And yes you're right, because of 65695 you're forced to use the whole-program granularity.

[Marc]

I do think the two issues are related and it would be ideal if I could get multiple K/JS modules that don't need to duplicate their dependency code, but for now it would be good enough if suspending functions work across modules. If I understand correctly, using finer granularity would "just" be about decreasing generated code size, right?

[Edoardo Luppi]

I believe the per-module without duplication thing is one of the aspects the K/JS team wanted to explore. I honestly am not up-to-date anymore as I've not really been coding lately.

> using finer granularity would "just" be about decreasing generated code size, right?
Yes and no. It really depends on the bundling phase.
But without a bundler, whole-program will always generate less JS code.

[Edoardo Luppi]

You need to think about granularity more on the debuggability and user code fidelity improvements. per-file reproduces 1:1 how you write your Kotlin code, which is pretty cool. That doesn't mean it yields size improvements. It's 99% project-dependent.

[Edoardo Luppi]

However, a finer granularity can yield better performance, especially with asset caching and lazy loading of modules (in the future).

[Marc]

Hmm, I see. would per-file granularity also make efficient bundling easier? I think it would be ideal if it was possible to hand in all required code (Kotlin stdlib, dependencies, application/library code), and then have everything be deduplicated. Right now I have a library that is meant to expose multiple modules, but internally those modules share a bunch of internal code. If I build them separately, I get multiple >5 MB files that contain tons of duplicate code.

I haven't actually checked how well bundlers deal with generated JS from Kotlin projects and how much of that stays in the end, but I assume most of it does (at least once). And that's of course a huge amount of code compared to native JS libraries...

[turansky]

> lazy loading of modules (in the future)
It's present! 🙂 (if you use per-file)

[Marc]

That would actually be useful to me. Hope to see that granularity gets fixed soon then.