allow to reformat gradle files

[Christoph Sturm]

it would be great if build.gradle.kts and settings.gradle.kts would also be reformatted and checked.

[Mateusz Kwieciński]

Hey @christophsturm 👋 The plugin does support kts files as well (both linting and formatting), it just doesn't configure the tasks. That's because people have various setups, and we can't really guess which kts files belong to the project, which should be taken into account, and when. There is no API in Gradle that would allow us to iterate over build script files, or at least I don't know any.

If you want, you can configure your own, project-specific tasks using custom tasks section in readme

tasks.register<LintTask>("lintBuildscripts") {
    group = "verification"
    source(file("settings.gradle.kts")) // list all build script files here
}

or alternatively, you may want to try with auto-discover them all (but it will also scan files that do not belong to the project)

tasks.register<LintTask>("lintBuildscripts") {
    group = "verification"
    source(layout.projectDirectory.asFileTree.matching { include("**.kts") })
}

(in addition, you may want to add the newly registered lintBuildscripts task to run always when you run lintKotlin (or check) using something like tasks.named("lintKotlin") { dependsOn("lintBuildscripts") } 👀 )

I'm closing the issue as it is a duplicate of #231

[Christoph Sturm]

great, thanks!

[Christoph Sturm]

btw, the gradle-ktlint plugin (https://github.com/JLLeitschuh/ktlint-gradle) lints and formats build files, so maybe there is a way to find them

[Mateusz Kwieciński]

Yeah, they do include all kts files under the project directory source, and my problem here is: those files don't necessarily have to belong to the project, and in some extreme conditions may lead to broken up-to-date checks + cache relocability issues, I think 🤔 i.e. if someone's project nests modules :foo and :foo:bar and they both have the plugin applied.
Anyway, I try to refrain from making assumptions on people's project setup, so it's unlikely we'll introduce such behavior. We may consider improving the documentation at some point, to cover most common cases like excluding generated files or running ktlint against kts files, or even provide some common troubleshooting, but that's still on a TODO list :)

[Jeremy Mailen]

I guess all build scripts have the extra appendage *.gradle.kts so it could be that a standard task wouldn't need to make too many assumptions.

[Tyler Hodgkins]

Hey, we're applying Kotlinter to our existing project. Our team would definitely appreciate the option to generate tasks for gradle scripts. We're using your suggestion above of custom tasks at the moment but it would be much cleaner if the plugin would support them!

[Tyler Hodgkins]

Perhaps a reasonable middle ground would be to provide a configuration that would allow a plugin consumer to specify additional files they want to include. Tasks could be generated (or their behavior modified) from that configuration, allowing the consumer build files to stay lean (and not have to worry about maintaining task orchestration) but not requiring the plugin to be opinionated about included files.