The Problem
When using wiretap-ktor-noop in a Kotlin Multiplatform project to replace the real library in Prod builds, the compilation fails if the WiretapKtorHttpPlugin is configured with a block (e.g., setting logRetention or enabled), or if helper functions like enableWiretapLauncher() are used in common code.
The noop artifact seems to strip out all configuration classes (like WiretapConfig, LogRetention) and helper functions, leaving only the bare WiretapKtorHttpPlugin object.
Context & Use Case
In our KMP project, we switch dependencies based on the build variant directly in the build.gradle.kts of our shared modules:
// build.gradle.kts
sourceSets {
commonMain.dependencies {
when (buildVariant) {
BuildVariant.Prod -> implementation("dev.skymansandy:wiretap-ktor-noop:1.0.0-RC11")
else -> implementation("dev.skymansandy:wiretap-ktor:1.0.0-RC11")
}
}
}
Because the Kotlin compiler processes the commonMain source set, it tries to compile the configuration block regardless of the variant:
// HttpClientProvider.kt
install(WiretapKtorHttpPlugin) {
enabled = isDebug
logRetention = LogRetention.Days(days = 7) // <-- Unresolved reference в Prod
}
The same issue occurs with the launcher helpers in platform-specific source sets (e.g., androidMain or iosMain) when they are compiled against the noop artifact:
// WiretapPlatformInitializer.android.kt
actual fun initWiretap(isDebug: Boolean) {
if (isDebug) {
enableWiretapLauncher() // <-- Unresolved reference in Prod
}
}
Current Workaround
To fix this, we are forced to create separate Gradle Source Sets (e.g., devMain and prodMain) and use expect/actual functions just to hide the configuration block and launcher calls from the compiler when building for Prod. This adds unnecessary boilerplate to the project structure.
Proposed Solution
The noop artifact should include empty/stub implementations of the configuration classes and helper functions, so that the code compiles seamlessly without requiring structural workarounds in the consuming project.
Specifically, the noop artifact should include:
WiretapConfig class with stub properties (enabled, logRetention, etc.).
Domain models used in configuration, like LogRetention.
Empty implementations of helper functions like enableWiretapLauncher(), startWiretap(), WiretapViewController, and ShakeDetector.
This would allow developers to write the configuration once in commonMain and seamlessly swap the artifact in build.gradle.kts for release builds.
The Problem
When using wiretap-ktor-noop in a Kotlin Multiplatform project to replace the real library in Prod builds, the compilation fails if the WiretapKtorHttpPlugin is configured with a block (e.g., setting logRetention or enabled), or if helper functions like enableWiretapLauncher() are used in common code.
The noop artifact seems to strip out all configuration classes (like WiretapConfig, LogRetention) and helper functions, leaving only the bare WiretapKtorHttpPlugin object.
Context & Use Case
In our KMP project, we switch dependencies based on the build variant directly in the build.gradle.kts of our shared modules:
Because the Kotlin compiler processes the commonMain source set, it tries to compile the configuration block regardless of the variant:
The same issue occurs with the launcher helpers in platform-specific source sets (e.g., androidMain or iosMain) when they are compiled against the noop artifact:
// WiretapPlatformInitializer.android.kt
actual fun initWiretap(isDebug: Boolean) {
if (isDebug) {
enableWiretapLauncher() // <-- Unresolved reference in Prod
}
}
Current Workaround
To fix this, we are forced to create separate Gradle Source Sets (e.g., devMain and prodMain) and use expect/actual functions just to hide the configuration block and launcher calls from the compiler when building for Prod. This adds unnecessary boilerplate to the project structure.
Proposed Solution
The noop artifact should include empty/stub implementations of the configuration classes and helper functions, so that the code compiles seamlessly without requiring structural workarounds in the consuming project.
Specifically, the noop artifact should include:
WiretapConfig class with stub properties (enabled, logRetention, etc.).
Domain models used in configuration, like LogRetention.
Empty implementations of helper functions like enableWiretapLauncher(), startWiretap(), WiretapViewController, and ShakeDetector.
This would allow developers to write the configuration once in commonMain and seamlessly swap the artifact in build.gradle.kts for release builds.