Since Kotlin 1.6.20 `fun main()` in modules compil...

# javascript

[Marc Knaup]

Since Kotlin 1.6.20 fun main() in modules compiled with -Xir-per-module are no longer executed automatically when the module is loaded.
How can I make that work again?

[turansky]

Do we need issue? 🙂

[Marc Knaup]

I’m done with issues here. With every Kotlin release we have to invest hours and days to fix new issues in our K/JS project and report issues. Compiler, tooling, and other issues are open for a really long time. Performance still isn’t good. K/JS is still too far from ready for production and it doesn’t seem to make much progress.

We’ve got no time for that. We’re relaunching our website in React+Typescript. All I’m doing for now is maintain status quo until we’ve relaunched.

I’ve found a workaround. But still have to work around another issue where there is a double-initialization.

@EagerInitialization
private val init = main()

[Big Chungus]

Well, KMP as a whole is still in alpha. Main focus and use-case for now is KMM and until that's stable I wouldn't expect other parts of KMP to improve significantly. IMHO K/JS should only be used as a way to expose your shared kotlin code to your JS/TS app as a library.

Trying to write pure K/JS production apps at the moment is just shooting yourself in the foot, unfortunately. I can't wait for that to be a viable option myself, but it's simply not the case for now.

[turansky]

For effective pure application development (step 0) we need core features:
1. File to file compilation
2. ES6 modules & classes support
cc @Sergei Grishchenko @anton.bannykh

[Marc Knaup]

K/JS existed even before Kotlin Multiplatform 😉
https://kotlinlang.org/docs/js-overview.html
It’s beta at best (new IR compiler)

[Marc Knaup]

We esp. need dynamic module loading.
Nobody wants a 5 MB landing page.

[Marc Knaup]

And some stability would be nice. Not break everything with every patch release.

[Marc Knaup]

Now that was broken too: https://github.com/Kotlin/kotlinx-datetime/issues/178

[turansky]

No respect to sideeffects anymore 🙂

[Marc Knaup]

Yup. In a patch update. Break a lot of stuff.

[turansky]

We esp. need dynamic module loading.

Nobody wants a 5 MB landing page.

File to file compilation will solve this problem

[turansky]

Yup. In a patch update. Break a lot of stuff.

Regular breaking changes will be required for Kotlin/JS evolution 😞

For me it’s more important, that annotation doesn’t look like final solution, because it doesn’t cover existed use cases

[Marc Knaup]

Documentation of such changes would be nice 😅

[Robert Jaros]

Trying to write pure K/JS production apps at the moment is just shooting yourself in the foot

My foot feels a bit hurt with each new application I deploy 😉

[Ayfri]

anyone has an idea of why it is taking such a long time ? what the kotlin team is doing right now on the IR compiler ?

[hfhbd]

Yeah, broken IR-ABI in a patch release is annoying.

[Sebastian Aigner]

Hi @Marc Knaup,

I understand your frustration fully – everyone wants to be productive, and nobody wants to spend time working around obscure bugs that are introduced seemingly at random.

When the team initially developed the -Xir-per-module option, it was something that was only intended for experimentation in the team building JetBrains Space. We had plans to bring per module splitting to the JS IR backend for a while, but always considered the flag internal and experimental. (That’s also why you won’t find references to this flag in our documentation.)

To be honest, we didn’t exactly expect that people would already be using this internal flag for their production applications – we probably should’ve seen it coming, given with how much excitement the community jumps on new features in the K/JS space. We’re going to expand the “What’s New in 1.6.20” with a paragraph on the change in behavior so that any other developers on the cutting edge don’t experience the same issues.

We’ve tried our best to communicate the change to lazy initialization by default in the changenotes – but maybe there are better places to communicate this. If you feel this information is missing somewhere else in our documentation, just let me know, and we’ll get it sorted.

As for breaking things in a patch update, I can only speak on the specifics or the Xir-per-module situation (Other regressions happen, and trust me, nobody is more frustrated when a regression slips through the release process than our team and QAs). We had to make a trade-off: We decided to change the behavior of the main functions with Xir-per-module enabled, because otherwise, we would have impacted all users who don’t use the Xir-per-module flag. I’m sure you can see how from our perspective – break an internal, experimental flag, or break all Kotlin/JS IR users – this was an easy decision.

The IR compiler is still in Beta precisely because we still need to make changes like that. As Victor has said; to continue the evolution of Kotlin/JS, we need to unfortunately break things sometimes, but we never intend for it to be a frustrating experience. We really want to move towards a stable IR backend as fast as possible – and to do so, we need to use the “wiggle room” that pre-stable parts of Kotlin get per the Kotlin Evolution. That includes making changes to features in incremental releases (though these are obviously trade-offs and decisions we make with the Kotlin/JS user base in mind).

The whole team really appreciates the dozens of issues that you’ve reported around Kotlin/JS, and the hours you’ve invested in triaging problems – you’ve certainly done more than anyone could ask to help make the Kotlin/JS ecosystem better.

Thanks for being a trailblazer for the Kotlin/JS ecosystem over the last few years. I’m sure you’ll have great success with TypeScript and React!