Feature request: for multiplatform deps, only include target platform

[ZacSweers]

If a kotlin multiplatform lib is depended on and has, say, org.jetbrains.compose:runtime as a common dependency, it gets included in an android dependency guard classpath even though there is no android platform exposed for that dep.

[handstandsam]

In this situation, isn't the case that org.jetbrains.compose:runtime is included in the final JAR/APK? My understanding is that common (I'm assuming commonMain) dependency ends up in that final binary.

My general thought on dependency guard was to gain insight on everything that you are shipping to customers. If I understand correctly, that's here as well.

1. Am I understanding this correctly?
2. If I am, what behavior are you looking for exactly? Just things that are specified as an androidMain dependency (as an example)?

[ZacSweers]

I'll double check but I don't believe it is, otherwise we'd have duplicate class issues with androidx's compose runtime

[ZacSweers]

And yes I'd expect only things from Android main effectively

[handstandsam]

🤔 - Okay, that seems like a valid usage option of this. How does :dependencies render for this? I'm assuming it'd contain both the common and android dependencies.

I'm seeing how the feature you are describing could be useful to a team to just see what is there for androidMain dependencies.

How would we compute this?

dependencyGuard {
  configuration("androidRuntimeClasspath") {
    excludeConfiguration("commonRuntimeClasspath", "jvmRuntimeClasspath")
  }
}

I would then think we'd do an intersection where you'd take everything in android and remove anything you found upstream?

Something like that?

[handstandsam]

☝️ I included a list of configurations that could be depended on. In the example above, you would probably only need the jvm configuration to exclude, but with HMPP (https://kotlinlang.org/docs/multiplatform-hierarchy.html) you might be depending on multiple parent configs.

The intersection result is I think what you'd be looking for here?

[ZacSweers]

I looked a little more closely at it and I think this is actually "correct" by the letter of the gradle law. There is an android compose-jb artifact, but it's just a shim pointing at the real androidx compose dep

+--- org.jetbrains.compose.runtime:runtime:1.2.0
|    \--- androidx.compose.runtime:runtime:1.2.1 -> 1.3.0-rc01 (*)