No preview found in a minified and shrinked build (Proguard) about showkase

[vinaygaba]

Sounds reasonable! I'll take a look at share the keep rules you might need!

[vinaygaba]

Hey! I had played around with the proguard configuration a bit and went down a rabbit hole for minimizing the footprint of this library. I was also experimenting with using debugImplementation and updating some of the documentation to reflect with some new guidance for use cases where Showkase is only used in debug mode. As far as release builds go, I haven't profiled release build yet and suspect that it's probably going to be the rule that you have in your previous comment itself. Once more people can confirm it and I also spend some time experimenting with it, I can potentially ship this library with some release proguard rules.

[vinaygaba]

It is ok in debug but ko in release

Could you elaborate on this a bit more. Under what circumstances do you want to run this on a release build? We envisioned Showkase to be an tool that was meant primarily for internal and debug purposes. It sounds like you plan to host the app on the Play Store? Is that what you are trying to do?

[VincentJouanne]

Under what circumstances do you want to run this on a release build?

Having Showkase in a staging build would allow stakeholders (designers, POs ...) to easily have a look at the Design System: they might be able to spot mistakes if any.

[VincentJouanne]

Awesome, thank you very much for the value provided 🖖

[StylianosGakis]

Is there any update on this?
It seems like this fails on the minified version as it tries to find "${packageName}.ShowkaseModuleCodegen" but it's not named that?
So asking proguard to not strip @Preview composables isn't enough, that class also needs to be retained? I am super unfamiliar with playing with proguard so I couldn't find a way to fix it myself, do you have any ideas on how to solve this otherwise?

[StylianosGakis]

Okay, just adding
-keep class **.ShowkaseModuleCodegen { }
to my proguard file seems to render them just fine. Can you @VincentJouanne try it out too and confirm?
I have no idea what other kind of consequences this might have, nor do I know if there is a more optimal proguard configuration that will keep just the necessary stuff, if what I wrote above keeps too much.
So for our use case, having the staging build simply add another proguard file compared to the release build that has this one proguard command should suffice. Maybe something to put on the library documentation after it's confirmed (or improved)? I be happy to help with that if you'd like me to!

[vinaygaba]

@VincentJouanne Did you try with the rule that @StylianosGakis suggested?

[VincentJouanne]

Hey guys, thanks a lot for your answers, I did not had time to test it again, I am closing it for now and if I encounter the problem again I will re-open it :)

Thanks for your time 🖖

[vinaygaba]

Want to summarize the solution for future reference -

You essentially need to add a proguard keep rule to make it with in release/alternate builds. The exact keep rule depends on your setup. For example, if your ShowkaseRootModule implementation looks like this -

package my.lovely.package

@ShowkaseRoot
class MyRootModule: ShowkaseRootModule

Then your proguard rule will need to be

-keep class **.MyRootModuleCodegen { }

We are essentially trying to retain the final XCodegen class that Showkase generates. The name of this generated class is of the format (_name_of_ShowkaseRootModule_implementation_)Codegen.

Hope this makes sense!