The hash changes everytime the classpath of those accessors changes

Sometimes IntelliJ is adding these imports when copying around things within such scripts, but they are just non-sense.

You showed that you use the string-y API to access the verison catalog. But could it be that you are also using my hack-around for using the static accessors for version catalogs in precompiled script plugins? Because I believe that such inserted imports might be a side-effect of using that hack-around.

You only get static accessors generated for things that are added by plugins unconditionally that you add within the same script in a

plugins { ... }

block.

You are using the accessor that is generated for something else and if the classpath of that "else" changes the accessor package changes

One way to solve this by properly using type-safe accessors is, to apply the necessary plugin in the

plugins { ... }

block of that script, as the pure presence of the accessor is already a guarantee, that the configuration you try to use there is present at runtime.

By using such imports you are voiding the type-safety and could as well not use type-safe accessors at all

Which would be the other possible solution, for example by replacing

implementation(platform(it))

by

"implementation"(platform(it))

Or by adding before a

val implementation by configurations

, that would also work but also not have the "it exists" compile-time guarantee, but fail at runtime if it does not.

So summarized, if you ever use such imports anywhere, you are definitely doing something wrong and should change it. 🙂

But actually,

kotlin("android")

is fine.

I just tried and it adds both,

implementation

and

debugImplementation

🙂

Does it also not build from commandline?

Unfortunately, as far as I know there is no common base plugin that does this work that you could use, and as you use that plugin in the other two convention plugins you can apply neither or you get an error when you build the respective other convention plugin that uses it. So the "correct" solution for your case is probably indeed "3", with reacting to the Android plugins. Otherwise - i.e. currently - your plugin depends on ordering and fails if you apply it before applying one of the Android plugins and that is again bad practice. Should be something like this:

package de.test.configuration

val libs: VersionCatalog = versionCatalogs.named("libs")

listOf(
    "com.android.application",
    "com.android.library"
).forEach {
    pluginManager.withPlugin(it) {
        val implementation by configurations
        val debugImplementation by configurations

        dependencies {
            libs.findLibrary("compose-bom").ifPresent { implementation(platform(it)) }
            libs.findLibrary("core-ktx").ifPresent { implementation(it) }
            libs.findLibrary("coroutines-android").ifPresent { implementation(it) }
            libs.findBundle("compose").ifPresent { implementation(it) }
            libs.findLibrary("compose-ui-tooling-core").ifPresent { debugImplementation(it) }
            libs.findLibrary("compose-ui-test-manifest").ifPresent { debugImplementation(it) }
        }
    }
}

Well, you don't make it worse, but you keep the bad-practice state

You helped me a lot