Should all KMP libraries target all available Kotl...
# library-development
a
Should all KMP libraries target all available Kotlin platforms? For example, a KMP library for mobile apps (Android/iOS). Is it ok to have only Android/iOS* platform targets? Or do you expect to have other targets available but just a message saying the library doesn't support it?
j
If the library doesn't support it, it shouldn't declare the targets IMO. The build tool on the consumer side should deal with variant issues in a nice way
👍 2
2
j
I think ideally JVM should also be supported
a
@John O'Reilly you mean Android/iOS and JVM
👍 1
m
If the library does not reference any Android APIs, it can declare just
jvm
. Android consumers will use the
{pub-name}-jvm
publication in the absence of a
{pub-name}-android
publication. An example of this is the kotlin standard library. It does not have a
-android
publication. Any Android APIs used in the
stdlib
are via reflection. See HERE
a
it's more about covering wasm/js or not. Assuming that a KMP project covering many targets won't compile
j
I'm not sure I understand what you're asking for. If you're asking about whether you should add a target to your library even if you don't support it (just for the sake of compilation but fail at runtime), I would say the answer is no. If you're asking whether you should support a specific target like Wasm/js, it all depends on the tradeoff for you. As a library author I usually declare at least all the targets that my dependencies support (if I don't have special needs to support it in my own code). If you do need to implement `actual`s in your own code, then it's a question of whether it's worth it to you. But that I'm afraid cannot be answered generally
💯 1
m
100% what Joffrey said.
I often find myself wanting to support all platforms, because sometimes discovering the shape of the API exposed from
commonMain
can be different depending on if you're supporting a certain target. E.g. async only because of JS support, with blocking code available from
nonJsMain
1
a
Thanks @Joffrey yep, this was my thinking too