Hi, all. What is the best practice for organizing ...
# multiplatform
a
Hi, all. What is the best practice for organizing the project structure? My project contains Android, iOS, server, web. For example, I'd would like to have separate git repositories for network entities which will be shared between all backends(server) and backend business logic(mobile, web) code.
g
This is not project structure, but rather monorepo vs multiple repositories
Do you have any problem related to MPP? extract what you want to own repository and publish it as binary dependency or use submodule or composite builds. But again, it’s usual dilemma what to choose, not related to MPP directly
m
Publishing a MPP library is a topic though. Is there a best practice on where to publish .frameworks or js binaries ? Maven repos feel awkward for iOS/js.
g
Publishing a MPP library is a topic though
It’s pretty easy now
You just should apply maven-publish plugin specify maven repo to pubblication
Maven repos feel awkward for iOS/js.
It’s the best way for dependencies that used by Kotlin project, of course it’s not the best choice if you want to use this library from JS code or as Pod for iOS project, but if you already have mpp project, just publish to maven, it works out of the box
m
Yep, that's the thing. I'm planning to consume a .framework hosted on mavenCentral from a MacOS app using Carthage. That might or might not be easy but having a few github template samples for multi-repo would help I guess
g
For example this is whole config to configure publishing to bintray (as you can see most of it just gettin auth data for publishing) https://github.com/gildor/knel/blob/master/build.gradle.kts#L44-L60
m
That's the simplest maven publishing script I have seen a long time 🙂
Once I have the MacOS setup done, I'll try to make a sample project somewhere.
g
because it supported by Kotlin MPP plugin, you just have to specify target repo
But your use case is a bit different, you have to publish binary framework, and I just don’t know how Carthage works in this case. There is some experimental gradle plugin for pod publishing, but I never tried to use it
publishing dependencies using Gradle metadata is just native for Kotlin and can be consumed by any Kotlin platform
m
Yep, it's the "consuming artifacts" part that could use some more samples. Most of the github templates I found are monorepos
g
Are you talking about publishing or consuming frameworks?
m
Both actually. Like end-to-end android + iOS + server samples. Publishing seems pretty simple from the link you gave. I have also seen samples on how to consume artifacts from a monorepo (without publishing them in that case). The part that's missing a bit IMO is a multirepo setup with Android + iOS + server (+ MacOS in my case but there might not be as many users for MacOS)
Or maybe using monorepo is just way easier (because no publishing and no versioning) and this is why everybody's doing it 🙂
a
I don't like monorepo for multiplatform because it will be a project with different development methods. I want to have separate repositories for ios, mobile, web. I have no experience with this idea.
d
TBH life has become much easier after going Mono-Repo for Client/Server Applications as you can develop, test, deploy and version the Client and Server together.
m
The only thing that's holding me back is that the MacOS repo already exists, together with README, issues, etc...
d
Though using Git Submodules you could get the best of both worlds - separate repo's locked together by revision, effectively using the top-level repo as a join table.
@mbonnin Include it your wider project repo as a submodule?
m
Yep, might try that
I don't have very fond memories of managing version dependencies through submodules but it might be the best compromise
a
Thank you! Let's try the git submodules. I think about them, but google say about bad ux in submodules.
d
I've had my own 'experiences' with submodules as well; but I think like some other naysayers at the time, I was projecting unreasonable expectations on the feature.
It can be unwieldy; but used for the right reason, and perhaps with a couple of helper scripts, they can help not hinder.
👍 2
a
Cool thanks.