Ability to optionally provide serialization for my library types

[rnett]

What is your use-case and why do you need this feature?

I have a library that provides a bunch of data types. I don't want to include Kotlinx serialization by default because it's rather heavy compared to the rest of my library.

However, I'd still like to be able to define serializers for my types in a separate project/module, ideally in a way where they would be used by default.

This is exactly the problem that kotlinx.collections.immutable has with their types. The closest workaround I'm aware of would be to have the serializers project define a SerializersModule consumers could use. Which is not great.

Describe the solution you'd like

I don't have a solution in mind. It's a very similar problem to #507 and #1931, and a solution for the first would likely solve the issue. But this is a distinct enough use-case (especially since I control both the data type library and the serializers library) it seemed prudent to make a dedicated issue for it.

[sandwwraith]

I think kotlinx-datetime had a problem like this. @dkhalanskyjb do you remember the solution?

IIRC if you're on JVM alone, you can use compileOnly dependency to specify @Serializable(MySerializer::class) on your types. MySerializer can be located in compileOnly dependency as well. If these dependencies are not present at runtime (= no one enabled your serializers), then this annotation will do nothing.

[dkhalanskyjb]

do you remember the solution?

Yes. It was to mark kotlinx.serialization as a compile-only dependency and then write code as usual. This approach is not without its downsides:

• You have to exclude kotlinx.serialization from ProGuard checks. Otherwise, Android builds will fail, claiming that there are some missing classes. Here is the set of rules we ended up with: https://github.com/Kotlin/kotlinx-datetime/blob/master/core/jvm/resources/META-INF/proguard/datetime.pro It does not look very neat, but on the bright side, we couldn't think of any actual errors that this config could potentially hide: if kotlinx.serialization is actually used but isn't on the classpath, this set of rules will not stop the build from correctly failing.
• compileOnly only works as advertised on the JVM. I don't know what happens for JS and Wasm, but for Native, you get this and have to declare kotlinx.serialization as a runtime dependency anyway:

Dependencies:
    - org.jetbrains.kotlinx:kotlinx-serialization-core:1.6.2 (source sets: androidNativeArm32Main, androidNativeArm64Main, androidNativeX64Main, androidNativeX86Main, iosArm64Main, iosSimulatorArm64Main, iosX64Main, linuxArm32HfpMain, linuxArm64Main, linuxX64Main, macosArm64Main, macosX64Main, mingwX64Main, tvosArm64Main, tvosSimulatorArm64Main, tvosX64Main, wasmWasiMain, watchosArm32Main, watchosArm64Main, watchosDeviceArm64Main, watchosSimulatorArm64Main, watchosX64Main)

Using compileOnly dependencies in these targets is not currently supported, because compileOnly dependencies must be present during the compilation of projects that depend on this project.

• We had to reimplement some serializers manually even though they would've been handled by the kotlinx.serialization plugin, just because the plugin was also adding some code to the serializable class itself: https://github.com/Kotlin/kotlinx-datetime/blob/7114d4aa0d35735d8fc8d242888e99409ac30889/core/common/src/serializers/DateTimeUnitSerializers.kt I don't know if the serialization plugin has changed since then. You can try using compileOnly kotlinx.serialization, try working with your classes from some client project normally without depending on kotlinx.serialization, and if nothing fails with ClassNotFoundException, you're good, no need for such workarounds.