Skip to content

Does Showkase generate code too early in the build lifecycle? #402

Open
@oheyadam

Description

@oheyadam

I’m rolling out an extension onto our convention plugins to selectively opt-into Showkase. the API surface looks like this

myExtension {
  optInto {
    showkase(true)
  }
}

The value set here is evaluated in our convention plugin and is used to selectively add the Showkase dependencies to modules that opted in

class ComposeConventionPlugin : Plugin<Project> {

    override fun apply(target: Project): Unit = target.run {
        val handler = myExtension().optInHandler
        handler.applyTo(this)
    }
}

// part of the handler class, which in turn is part of my registered extension
internal fun applyTo(project: Project) {
  // This must happen in afterEvaluate to ensure the extension was configured
  project.afterEvaluate {
    if (enableShowkase.getOrElse(false)) {
         pluginManager.apply(libs.plugins.ksp.get().pluginId)
         extensions.configure<KspExtension> {
           arg("skipPrivatePreviews", "true")
         }
         dependencies {
           "implementation"(libs.showkase.annotation)
           "debugImplementation"(libs.showkase)
           "kspDebug"(libs.showkase.processor)
         }
    }
  }
}

We must do this in afterEvaluate because if you do it any earlier, Gradle wouldn’t have configured the extension yet. However, this seems to be too late for the ShowkaseProcessor class.

This processor seems to kick in quite early in the lifecycle and doesn't wait for all projects in the graph to be configured. Is there a way for me to tell the processor to kick into gear at a later point in time when my code is ready, or is this just how KSP processors work?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions