debugApi instead of implementation why?

[mobilekosmos]

debugApi(libs.androidx.compose.ui.tooling) in the ui module

Any specific reassons why api instead of implementation? I though a few years ago it was that saying you should change all apis to implementation for build speed or something like that

[denebchorny]

I wonder the same.

I have been using this project as part of studying and learning. I have been combining it with other approaches to improve my code.

I found that the DeesignSystem module uses all the compose libraries as API. Likewise, in features, you use API in general.

Doesn't this impact compilation time?
What is the intention of exposing the internal libraries if they are exposed again as API in features?

My questions are not intended to criticize but to understand and learn.

[SimonMarquis]

Hi @mobilekosmos and @denebchorny,

I guess this androidx.compose.ui:ui-tooling dependency has been initially added as an api configuration to be able to easily expose it transitively to all the module's consumers.

That being said, a more "correct" way of doing that should have been to simply add the debugImplementation dependency in the Compose convention plugins, here:

nowinandroid/build-logic/convention/src/main/kotlin/com/google/samples/apps/nowinandroid/AndroidCompose.kt

Lines 40 to 44 in aea26aa

	dependencies {
	val bom = libs.findLibrary("androidx-compose-bom").get()
	add("implementation", platform(bom))
	add("androidTestImplementation", platform(bom))
	}

Here is the corresponding PR:

• Move androidx.compose.ui:ui-tooling dependency to convention plugin #1182

The slight downside of this solution is that all Compose modules will now have these 2 dependencies, even if they are not used. Although, most of the time if Compose is used in a module, it probably will need to declare @Previews at some point.

---

Regarding build speed and compilation time, in this instance, this has no real impact.

Where api can negatively impact build performances, is when exposing an "internal/implementation detail" dependency that would frequently change, invalidating all consumers. api should be used to expose dependencies that are part of the public API (e.g. method signature).

[denebchorny]

Thanks for your answer.