Kotlin Multiplatform Support

[tamimattafi]

Hello!
Thank you for this great library!
Are there any plans to support Kotlin Multiplatform? For example, using Faker in commonMain

[serpro69]

Hi @tamimattafi ,
Yes, I'd very much like to support multiplatform. There's also #43 which is similar I guess (though the request is specific for JS, I don't see that the implementation would be very different to support all platforms, not just JS)

I've taken some steps towards this as well, particularly #159 , which should make it possible to get rid of jackson and replace it with e.g. kotlinx-serialization.

The biggest problem to-date is reflection, as some core functionality still depends on it. There's an issue to fix this also #23 , but I haven't had time to look into it.

I also don't have a lot of experience with KMP generally, so refactoring e.g. build logic could also prove to be a challenge.

That said, I do want to support it, just don't know when I'll be able to do so on my own.
Any contributions towards this are very welcome though!

[tamimattafi]

@serpro69 Thank you for your reply!
I will study the codebase to see if I will be able to make some contributions. However, it's better to do that after your upcoming major release

[serpro69]

I'm not planning to release the major version in the next month or two I think, so that is still at least a couple months away .
Adding KMP support in 2.0 would also be a good time to do so IMO, as it will likely entail some breaking changes as well.
So if you want to wait until 2.0 is out just for the sake of "waiting" - there's no need for that ;) But in any case, let's see how far this issue gets by the time 2.0 is ready and we'll plan from there.

If you need any help with understanding the code - don't hesitate to ask.

[tamimattafi]

@serpro69 Thank you, let's keep each other updated on this issue

[dalewking]

As a plan of attack the first step would be to switch from the Kottin JVM gradle plugin to the Kotlin Multiplatform one using a JVM target. Initially each subproject would have 4 src directories jvmMain, jvmTest, commonMain, and commonTest. Your existing code would move to the JVM ones with nothing initially in the common ones. You want to get that working to build the library first.

Next would migrating code to common source sets. This is where you will have to address JVM specific libraries.

Once you can get the bulk of your code migrated then you can think about adding additional targets

[serpro69]

Thanks for the comment @dalewking ! I completely agree, this would be a very good and natural first step towards adding multi-platform support - replacing the build logic to multiplatform and compiling to jvm targets.

[tamimattafi]

@dalewking I agree, this is the very first step for every multiplatform migration and a very good advantage for us.
@serpro69 Do you have a Telegram or other contact where we can have quick Q/A about the project? I will try to implement this first step by migrating to the plugin, but I might need some quick answers since I might have limited time this week

[serpro69]

Telegram no, I don't have. I do have keybase, but I can't promise to respond quick enough there as I don't use it that much... Matrix could be another possibility, but again, I can't say I'm online all the time. Discord could also be an option (same username as in github), if that works better, and I'll probably reply there faster than in the former two.
As a suggestion, maybe we could use discussions instead? I've just enabled them for this repo. That way we could keep all the relevant info in the repo as well. And I'll probably reply in github faster than other places, since it's one of the few places where I still have notifications enabled 😁

[tamimattafi]

@serpro69 GitHub discussions seems like a good option, I will enable notifications too to try and respond as quick as possible

[serpro69]

Awesome @tamimattafi ! Made the thread for it here - #235 .

[tamimattafi]

@serpro69 Great, thank you, I will post my questions there