Hey, guys. I have an KMM module with many serializable classes generating code for JVM, iOS and JS. ...

# serialization

[Bruno Medeiros]

Hey, guys. I have an KMM module with many serializable classes generating code for JVM, iOS and JS. I just realized today that my JS bundle (IR) is huge and the main cause is the $serializer synthetic property that is created for each class/companion. If I remove all my @Serializable, my module reduce its size by 80%. JVM an iOS are fine, but I can't pay that price in JS.

Question is:
Is there a way to disable kotlinx-serialization $serializer generation just in the JS backend? If I could disable it just in JS, I could still use the kotlinx-serialization serializer for all backends and I'd roll my own for JS, but I would still be able to use my data classes in JS.

[turansky]

It can be realized via custom actual @Serializable for example

[turansky]

typealias everywhere, but custom annotation class (without serialization magic) in JS

[turansky]

In IR possibly you can use custom compiler plugin to disable serialization for JS :)

[Bruno Medeiros]

I have 100+ classes in commonMain, it'd very painful to transform all of them in actual/expect, and that also goes against code reuse, which is the main selling point of this whole thing.

[Bruno Medeiros]

In IR possibly you can use custom compiler plugin to disable serialization for JS 🙂

this seems interesting! any hints on good material about a custom compiler plugin. @turansky?

[turansky]

You need actual for @Serializable annotation only (1 annotation class)

[Bruno Medeiros]

ohhh, I see!! that is actually an amazing idea, I'll try that @turansky. Many thanks!!

[turansky]

About compiler plugin - you will need class visit only, like here

[turansky]

Actual looks better, because IDEA will not suppose .serializer() in JS without additional IDEA plugin

[Bruno Medeiros]

FYI @turansky your idea worked, annotation type aliases are working fine! the only drawback is that annotations like @SerialName also have to be aliased in case you need them. Other than that, almost perfect solution!

[turansky]

How many kilobytes saved?

[Bruno Medeiros]

@turansky the total size of my library now is 178KB down from 986KB, that was the result of a few different actions to optimise the bundle.
Removing the kotlinx-serialization @Serializable reduced the size of the module that contains all serializable classes from 587KB to 112KB. additional reduction on that module was achieved by using standard classes instead of data classes, this specific module is now "just" 86KB. It cost me 2 days to roll out my own serializer, thought, and it's quite hacky and not generic at all, so I guess I appreciate more the work put into kotlinx-serialization now hehe

[turansky]

Do you use IR or legacy compiller?

[Bruno Medeiros]

IR

[turansky]

Do you use lazy property compiler flag?

[Bruno Medeiros]

yep

[Bruno Medeiros]

I'm following that YT issue for the ktor bundle size for quite a while now, the one you post progress about. (My original version of this internal library was using Ktor client on JS, btw, but that is another thing I had to remove to reduce bundle size). I tried all things mentioned there

[turansky]

Do you have NPM dependencies, included inside?

[Bruno Medeiros]

No, not at the moment, just using Js browser native APIs

[turansky]

@Bruno Medeiros
DCE in Legacy non-optimal, but works
DCE in IR doesn’t work in my projects

As result IR bundle size = Lecacy bundle size without DCE (all inside)
Possibly with fixed IR DCE you will have other results

[Bruno Medeiros]

interesting, thanks for pointing that out :) I'll definitely follow this YT, it looks like I can have much better results when this is fixed.

[turansky]

@Bruno Medeiros FYI