Hey all, question about project structure for Comp...

# compose-desktop

[sigmadelta]

Hey all, question about project structure for Compose Desktop + Ktor (JVM).

Considering having 2 separate JVM modules inside of a Kotlin Multiplatform project doesn’t seem to be supported right now, I figured to have Compose desktop be the main JVM target for the Multiplatform project, and add a separate module inside of the project under the default id("application") plugin.

When doing this however, I somehow can’t seem to get a reference to the commonMain module inside of the Multiplatform project. Is this scenario supported or should I also consider adding another separate common module to be shared between the 2?

[sigmadelta]

FYI - I managed to resolve it using an independent common module to act as a shared repo between the separate backend module and the Kotlin Multiplatform module.

But for future reference it could be interesting to expose the commonMain module, or ideally even just allow multiple instances of a type inside the Multiplatform setup 😉 .

[Dima Avdeev]

It's a good solution to have separate common module with shared code between server and client.

[burnoo]

I would suggest moving code from the root project (./src) to the dedicated submodule (e.g. ./desktopApp/src). Having code in a root project is great for single-module apps, but for multi-modules ones it’s common to keep all code in submodules.
Examples (from compose-jb): single module (root) project, multi-module project

Creating shared module (:common or :shared) sounds like a good idea, you can use it in :backend and :desktopApp modules.

[sigmadelta]

Thanks for the input both 👍

In essence, the separate module approach is indeed what I went for now, with the exception @burnoo that I probably will keep the front-end clients inside of a multi-platform setup as I otherwise lose the capability to use a few useful capabilities like `actual`/`expect` .

I’ve always used the multi-module setup for Android projects and such, but I’d really like to leverage the power of KMM when possible.

So for now I’m probably settling for this:

/src : Multi-platform setup consisting purely of code specific to front-end clients (viewModels, Compose, client HTTP handling & persistence, etc…)
`:common`: Domain models & core business logic
`:backend`: Services & data layer