Is it possible to disable Kotlinx.Serialization for a single source set?

# serialization

[faogustavo]

Is it possible to disable Kotlinx.Serialization for a single source set?

[faogustavo]

With compose we can use the following snippet to disable on JS:

composeCompiler {
    targetKotlinPlatforms.set(targetKotlinPlatforms.get() - KotlinPlatformType.js)
}

[faogustavo]

is there anything similar for serialization?

[ephemient]

nope, see isApplicable in https://github.com/JetBrains/kotlin/blob/master/libraries/tools/kotlin-compose-compiler/src/common/kotlin/org/jetbrains/kotlin/compose/compiler/gradle/ComposeCompilerSubplugin.kt vs https://github.com/JetBrains/kotlin/blob/master/libraries/tools/kotlin-serialization/src/common/kotlin/org/jetbrains/kotlinx/serialization/gradle/SerializationSubplugin.kt

[ephemient]

you could hack it by replacing the plugin with your own

SerializationSubplugin.kt.cpp

[ephemient]

I'm curious why that's needed though

[faogustavo]

We just don't use Kotlinx.Serialization on JS because it bloats the bundle size. For JS we manually implement serialization so we can have more control over it.

I'm reconsidering this alternative, but the bundle size (after webpack, minify, etc) goes from 719k to 880k by just adding serialization

[ephemient]

that comes from the dependency and not the plugin though, which should already be under your control

[faogustavo]

The dependency adds around 30k. The rest of the size is when I'm using encode/decode methods (if I don't use DCE probably kill those branches)

[faogustavo]

Other change that I noticed that bloat our bundle is how we call the methods (I'm testing in case we want to drop our manual solution).

If we use

ApiJson.decodeFromString<T>(value)

instead of

ApiJson.decodeFromString(serializer, value)

the size impact is quite relevant (~80k)

[Bruno Medeiros]

You can create your own @Serializable annotation with an expect and type alias it to the real one on the source sets (I'm assuming platforms) you want the real serialization stuff to happen while creating a custom fake @Serializable annotation on the source sets you don't want it

[Bruno Medeiros]

cc @faogustavo I hope this helps, I did the exact same thing in the past to avoid having kotlinx-serialization at all in my JS artifact

[Bruno Medeiros]

someone in this very same channel gave me that idea, but I don't know who anymore

[faogustavo]

Using expect/actual on the annotation is not allowed in the K2 compiler 😕 https://youtrack.jetbrains.com/issue/KT-68852/K2-Serialization-Back-end-fails-to-compile-serializable-class-with-expect-actual-annotation

[faogustavo]

We have this solution, and I'm investigating possibilities to fix this and finally use K2. Making the classes expect/actual is a path, but it's a lot of work. I'm not sure about it yet