airbnb / Showkase

🔦 Showkase is an annotation-processor based Android library that helps you organize, discover, search and visualize Jetpack Compose UI elements
https://medium.com/airbnb-engineering/introducing-showkase-a-library-to-organize-discover-and-visualize-your-jetpack-compose-elements-d5c34ef01095
Apache License 2.0
2.11k stars 107 forks source link

add support to other build types than only debug and release #274

Open kibotu opened 1 year ago

kibotu commented 1 year ago

Currently only debug and release build types are supported

imagine having a setup with build types


android {

    buildTypes {

        alpha {
            initWith(buildTypes.debug)
        }

        release {
        }

        beta {
            initWith(buildTypes.release)
        }
    }

    dependencies {
        alphaImplementation "com.airbnb.android:showkase:1.0.0-beta14"
        kaptAlpha "com.airbnb.android:showkase-processor:1.0.0-beta14"
    }
}

then the dependencies won't be available in alpha builds because the way it is published to maven central

https://repo1.maven.org/maven2/com/airbnb/android/showkase/1.0.0-beta14/

compared to e.g. leakcanary

https://repo1.maven.org/maven2/com/squareup/leakcanary/leakcanary-android/2.9.1/

the problem lies with the file naming

where instead of having one artifact, the showkase library has 2: one for debug and one for release, which is not a bad idea if you want automatic switching with just adding implementation instead of having to add debugImplementation and releaseImplementation

however I'm not aware of a way to have those files added for alpha/beta/release or any other non default build type now


for this to work we would have to have two different artifacts, e.g. one for

    com.airbnb.android:showkase:1.0.0-beta14 
    com.airbnb.android:showkase-no-op:1.0.0-beta14 // e.g. for release 
kibotu commented 1 year ago

ok turns out there is a workaround

android {

    buildTypes {

        alpha {
            matchingFallbacks = ['debug']
        }
    }
}
popovanton0 commented 1 year ago

I also encountered this problem, spent a whole day on it, and even wrote a Medium article about solving it.

TLDR; As it turns out, if you have a project like this:

graph LR
  B(base-ui) --> D("design-system<br>(with showkase)")
  A(app) --> A1(feature-module) --> B
  A1 --> D

you need (not entirely sure why) to specify matchingFallbacks in all build.gradle files. I did this using a root file that applies to all modules the project.

Unfortunately, I haven’t realized that need in time and wrote almost a Gradle plugin to modify dependency metadata.

Why the library has multiple versions (debug and release)? Is it necessary? If not, it will be mush easier for developers if the library had only one version, like the aforementioned LeakCanary.

vinaygaba commented 1 year ago

Thanks, I do see the problem and I don't think it's intended to be like this. I think having a single artifact makes sense to me. I can fix this in the next release.

vinaygaba commented 1 year ago

@popovanton0 also, thank you for the write up and documenting a way to unblock people until the fix is merged

vinaygaba commented 1 year ago

Published a PR to fix this - https://github.com/airbnb/Showkase/pull/291 Not 100% sure I have the right fix so if either of you have thoughts, please chime in on the PR @kibotu @popovanton0