Closed ZacSweers closed 1 year ago
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)?
I'll double check but I don't believe it is, otherwise we'd have duplicate class issues with androidx's compose runtime
And yes I'd expect only things from Android main effectively
🤔 - 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?
☝️ 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?
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 (*)
If a kotlin multiplatform lib is depended on and has, say,
org.jetbrains.compose:runtime
as acommon
dependency, it gets included in an android dependency guard classpath even though there is no android platform exposed for that dep.