:rocket: We’ve been focused on enhancing Kotlin Mu...

# announcements

[hhariri]

🚀 We’ve been focused on enhancing Kotlin Multiplatform for web, and a lot has been going on behind the scenes. 🛠️ Now, we’re ready to share it – check out our latest update on the present and future of Kotlin for web.

➡️ Read the blog post

To share feedback or ask questions, explore topic-specific channels like #CDFP59223, #C01F2HV7868, #C0B8L3U69, and #C3PQML5NU.

[Arjan van Wieringen]

Awesome! I am happy Kotlin/JS is getting more love again

[altavir]

Indeed. We use it in production and I am happy to see some of major problems addressed.

[Piotr Krzemiński]

what's the fate of https://github.com/JetBrains/kotlin-wrappers? these are bindings to JS libraries so in general a good thing that should stay, but will it get some semver-like versioning and compatibility guarantees?

[Artem Kobzar]

@turansky ^^

[turansky]

but will it get some semver-like versioning

@Piotr Krzemiński we already have semver versioning.
Current version - 2025.5.4 (release)

[Piotr Krzemiński]

what's the meaning of the components in the version? isn't it year, month, day?

[turansky]

It's already described in changelog (year.month.patch)

[Piotr Krzemiński]

so if there's a breaking change, will you wait for the next year? (of course, joking, but my intent is to provoke a constructive discussion 😄 )

[turansky]

We describe breaking changes in our changelog (we don't wait for the next year).
Also we generate declarations for the latest versions of NPM libraries and they usually break compatibility too and they also expect latest browser/web declarations.

[Piotr Krzemiński]

So technically it's not semver

[turansky]

It's what we have in TypeScript for example.
Does it mean, that TypeScript doesn't use semver versioning? 😉

[Piotr Krzemiński]

as I can see here, TS follows "loose" semver, not date-based versioning. Ok, so the bottom line is that:
• versioning schema in kotlin-wrappers doesn't communicate breaking changes
• breaking changes appear fairly often because the NPM libraries being wrapped contain braking changes

[Arjan van Wieringen]

You know you dont need to include the full kotlin-wrappers. You can just add the dependencies for the wrapper you need. That alleviates some of the breaking changes.

[Piotr Krzemiński]

ah right, fair point!

[Piotr Krzemiński]

so probably this usage is suboptimal (belongs to a project I own)

[turansky]

@Piotr Krzemiński
Yes, we describe current state of very dynamic world.
Single option to "save compatibility" - fix all NPM versions (including transitive) and stop development.

But in that case in year our repository will be marked by GitHub as "very unsecure".

[Arjan van Wieringen]

The Web Standard world is luckily pretty stable. Sadly the JS NPM ecosystem decides to reinvent the wheel every Tuesday.

[turansky]

so probably this usage is suboptimal (belongs to a project I own)

@Piotr Krzemiński
Catalog is highly recommended - it's just aliases of dependencies.

[Piotr Krzemiński]

got it, thanks for the discussion! I think it would be nice to describe the versioning scheme and any other conclusions in README of kotlin-wrappers - the changelog is a living thing and it's hard to discover for people starting using this set of libs

[turansky]

Register dependency aliases != add dependencies

[turansky]

The Web Standard world is luckily pretty stable

From time to time we receive breaking changes even in ECMA part like:
• Class Iterator with ~10 "arraish" methods
◦ Before it was interface with 1 method
• Type parameter for typed arrays

[Pat]

Cool! Does the wasm target suffer from the same performance issue that flutter does on Safari?
https://bugs.webkit.org/show_bug.cgi?id=267291
Or does it work completely differently?