Curious if anyone has gotten to a similar point as...

# compose

[Colton Idle]

Curious if anyone has gotten to a similar point as me. I currently have a single module android app without compose. In the meantime my team was thinking that we can create a new repository where we create all of our composables and unit test all of them in a library of UI components essentially.

We see a couple of paths forward

1. Separate repo for our app and separate repo for our composables
2. Ditch the separate repo, and instead have an app module and a ui-composables module
3. Don't have separate repos or modules and just do everything in a single app
Although I feel like the typical pros and cons make sense here of separate repos, vs separate modules, etc, but I'm curious if anyone else has extreme warnings against a certain method.

The reason we want to go the separate repo route is because enabling Compose doesn't currently support using reflection in your app and so we can't start building composables side by side our app module for the time being.

[Bryan Herbst]

For context, we already have a large number of modules, so that part of the discussion is far in the past.

Our approach for Compose has been to conditionally include the compose modules in settings.gradle.kts, backed by a boolean Gradle property. We also have a separate Gradle property for building with AGP 4.2 instead of 4.1, so you need both set to do any Compose work in our codebase.

The biggest downside is that Compose is not enabled by default- theoretically this could open the door to unknowingly breaking our Compose module, but since none of our production modules depend on Compose that hasn’t been a problem yet.

Most of our engineers are still working in AS 4.1 without any Compose though, so this keeps them happily working without any disruption.