Hi Everyone, we develop a multiplatform SDK where ...

# javascript

[Márton Matusek]

Hi Everyone,
we develop a multiplatform SDK where we are using kotlin-browser. We are testing it in a multiplatform app and we get the following error when launching the webMain target:

Uncaught IrLinkageError: Function 'addEventListener' can not be called: No function found for symbol 'web.events/addEventListener|[e-mail](web.events.EventType<0:0>;kotlin.Function1<0:0,kotlin.Unit>;web.events.AddEventListenerOptions?){0§<web.events.Event>}[0]'

The SDK is using kotlin-browser 2026.3.12 whilst the app is using version 2026.3.3 so the issue lies in the change in the signature of the function in the error. I would like to request your advice on resolving such issues. I have multiple ones that work but none of them seem to be ideal:
• downgrade kotlin-browser in the client of the SDK - this forces our SDK consumers to a specific version
• use kotlin-browser less / not use it - less risk
Any advice is much appreciated!

[Robert Jaros]

kotlin-wrappers project changes rapidly and often introduces braking changes between releases - you need to be ready for that if you want to use it

[Márton Matusek]

yes, I noticed that, but that makes it hard to use for libraries because the consumers will have problems like the one above. Also, I don't see breaking changes being communicated in the release notes. Do you know where those can be tracked?

[Márton Matusek]

@turansky sorry for pulling you in, can you maybe advise us on this?

[turansky]

Breaking changes we usually describe here - github.com/JetBrains/kotlin-wrappers/blob/…/CHANGELOG.md

[Márton Matusek]

ah, thanks! sorry about that! on the same note: do you see a better option than the SDK consumers having to downgrade?

[Márton Matusek]

also, the change that causes the error does not seem to be in the changelog

[turansky]

Right now Kotlin compiler is very strict for external types.
If it won't be so strict - we will avoid such problems.

[turansky]

> also, the change that causes the error does not seem to be in the changelog
It wasn't expected, because it was internal method change 😞
Sorry 🙏

[turansky]

do you see a better option than the SDK consumers having to downgrade?

With current Kotlin compiler limitations single really safe option - aligned versions between library and app.

[Márton Matusek]

Makes sense, thank you very much! And no worries about the break. Last question: Kotlin compiler version is expected to be less strict? The app needs to use that version at least, right?

[Edoardo Luppi]

To clarify, are you using github.com/kotlin/kotlinx-browser or github.com/JetBrains/kotlin-wrappers/…/kotlin-browser

[Márton Matusek]

kotlin-wrappers

[Edoardo Luppi]

My decision, at the time, was to use our own external types. Generally speaking, you'll never use all of the browser APIs, but a restricted subset. Once the Kotlin compiler begins to offer better backward and forward compatibility, I'll switch back to proper wrappers.

[Márton Matusek]

Yeah, that also makes sense, I feel like we are a bit too invested at this point, but it could be done

[Edoardo Luppi]

It is also a matter of what your public API looks like.
1. Does your SDK re-export those external types, or not?
2. If yes, how many?
3. Do your SDK consumers use kotlin-wrappers? Or kotlinx-browser? Or should they use your own types?
Those are the driving questions.

Additionally, there are instances where JS external types are better encapsulated inside Kotlin types.

[Márton Matusek]

1. No and there was no usage of that type in the host app (but I might misunderstand the question)
2. -
3. we tried the SDK in a KMP app that also uses kotlin-wrappers, hence the error above. The error occured in an internal usage of the function. We are not exposing types on our public API that are not our own.

[Edoardo Luppi]

we tried the SDK in a KMP app that also uses kotlin-wrappers, hence the error above

plus

We are not exposing types on our public API

translates to: you should have your own types for future-proofness.

[Edoardo Luppi]

If you can't predict what your consumer environments look like, go with the safer long term approach.

[Márton Matusek]

thanks a lot, we will consider this for sure

[Edoardo Luppi]

No problem. I'm not saying the mentioned projects are bad, just that you don't want to fight with issues that don't even add any value to the business. Your own types will also make it possible to optimize their usages depending on the situation, as you have complete freedom.

[turansky]

In Kotlin Wrappers we don't expect breaking changes in nearest future. 😉
Only stable companion blocks/extensions and rich errors - possible reasons of breaking changes.

[Márton Matusek]

nice, thank you!

[turansky]

Migration to companion blocks will break custom declarations too