Hi everyone, I have a question about dependency pr...

# multiplatform

[박상혁]

Hi everyone, I have a question about dependency propagation in Kotlin Multiplatform.

I have two modules: A and B.

• Module A adds the Room library with implementation("androidx.roomroom runtime...") in commonMain.
• Module B depends on A with implementation(project(":A")).
My expectation:
Since A uses implementation, Room should not be exposed to B. Therefore, B should not be able to reference Room classes unless A declares them with api or B adds Room explicitly.

But what I see in practice:
In commonMain, B can still use Room classes without adding the Room dependency. It looks like the dependency is leaking from A even though it’s declared as implementation.

What’s interesting is that this only happens with commonMain dependencies.
When the dependency is added in androidMain, it works as expected: B cannot see Room unless it declares it itself.

Questions:

• Is this behavior expected for commonMain dependencies?
• Could this be an IDE/classpath leak rather than a stable Gradle contract?
• What is the recommended way to avoid this and ensure B cannot accidentally depend on Room?

[Excellence kawej]

Are they both modules (A and B) in the shared module???

If so, it's normal because all dependencies declared in commonMain can be referenced in any module within the shared module.

[박상혁]

@Excellence kawej

Ah, I see — it was because they are inside the shared module!
Thanks a lot for the clarificationkodee loving

[Ernestas]

hey, I have the same issue, what do you mean by "inside the shared module"? I have a CMP project where the composeApp depends on a designsystem module, which has a material3 dependency, that I want to hide from the composeApp module, but it's still visible:

# settings.gradle.kts
include(":composeApp")
include(":core:designsystem")
<...>

# :core:designsystem:build.gradle.kts
kotlin {
    sourceSets {
        commonMain.dependencies {
            implementation(compose.material3)
        }
    }
}
<...>

Did you find a solution for this?

[박상혁]

@Ernestas

I wasn’t able to “fix” it either — I just came to understand that this is a characteristic of how KMP works.

In a single KMP/shared module, the commonMain source set is shared by all code inside that module.

So if you add a dependency (like material3) to commonMain of one sub-module, it will be visible to any other code in that same shared module.

[Ernestas]

Then this pretty much defeats the purpose of modularising 😄

[박상혁]

I agree with you to some extent.🙏

But even if libraries are shared across commonMain, I don’t think modularisation is completely meaningless — it still makes sense in terms of separating logic and responsibilities.

If you happen to find a solution or workaround for hiding dependencies in this setup, I’d really appreciate it if you could share it as well!