This message was deleted.

you can't. like

plugins

,

pluginManagement

is special and is executed in a first pass outside of the context of the rest of the build script

so the official solution to this plugin is:

plugins {
    alias(libs.plugins.ktlint)
}

but I think IDE support (at least in Android Studio) here is lacking

it's an IntelliJ IDEA/Kotlin plugin issue: https://youtrack.jetbrains.com/issue/KTIJ-19370

If it were a

pluginManagement { ... }

block it were right, that it is handled separately first. I think when accessing it like

pluginManagement....

then it is done during normal settings script evaluation. But nevertheless it is of course still hen-and-egg problem, as the version catalog is not defined in such an "evaluated before" block but in

dependencyResolutionManagement

and thus during normal settings script evaluation and thus the accessors can not yet be available during settings script evaluation. The reason for this is, that a settings plugin can define a version catalog to be used in the project. So yes, the

alias(libs.plugins ...

is the idiomatic way and yes, the IntelliJ Kotlin plugin still lacks of proper support for it, while it still works fine of course as far as Gradle is concerned. And in the issue ephemient linked, you can find a small work-around plugin that just suppresses these red highlightings if you really care that much about it.

oh that's a good point,

pluginManagement.*

won't be extracted, only

pluginManagement { * }

. but it still won't work for the reasons Björn mentions.

Ultimately, I decided on this workaround (in

buildSrc/build.gradle.kts

):

dependencies {
    /**
     * Workaround for <https://gradle-community.slack.com/archives/CAHSN3LDN/p1651098827826449>
     */
    @Suppress("NAME_SHADOWING")
    fun DependencyHandlerScope.implementationGradlePlugin(id: String, version: Provider<String>) {
        implementation(version.map { version -> "$id:$id.gradle.plugin:$version" })
    }
    implementationGradlePlugin("de.undercouch.download", libs.versions.downloadGradlePlugin)
    implementationGradlePlugin("org.jlleitschuh.gradle.ktlint", libs.versions.ktlintGradlePlugin)
}

where

libs.versions.ktlintGradlePlugin

refers to the version in the version catalog

that has a different behavior of putting those plugins into the root project classpath. I just use

plugins { alias }

and ignore the IDE error, it makes no difference.

does the IDE still pickup the classes correctly?

yes, it relies on the Gradle tooling API to get information about classpaths and such, and that works fine

TIL how to suppress the IntelliJ error:

plugins {
    @Suppress("DSL_SCOPE_VIOLATION")
    alias(libs.plugins.m.versions)
}

Yes, or you just ignore it, or install the little work-around plugin mentioned in the linked YouTrack issue 🙂